Het grote IPv6 topic

Waarschijnlijk z'n MAC-adres niet (meer)

quote:

Sendy schreef op zaterdag 26 november 2011 @ 21:13:
Maar nu krijg ik deze packets:
console:

21:35:36.858380 IP6 fe80::290:ccff:fef4:9cb4 > fe80::216:3eff:fe7e:acf0: ICMP6, neighbor solicitation, who has fe80::216:3eff:fe7e:acf0, length 32
21:35:36.858584 IP6 fe80::216:3eff:fe7e:acf0 > fe80::290:ccff:fef4:9cb4: ICMP6, neighbor advertisement, tgt is fe80::216:3eff:fe7e:acf0, length 24

Dit is een neighbor solicitation aan een link-localadres, voor hetzelfde link-localadres. Je weet zijn adres toch al?

Strict gezien wel want 't staat in het link-localadres, maar die aanname wordt niet gemaakt.

Als je volgende keer dat je tcpdumpt de -e flag geeft, zul je waarschijnlijk zien dat het destination MAC-adres een multicastadres is. Of, als dat niet zo is, gaat 't hier waarschijnlijk om de Neighbour Unreachability Detection. Ja, IPv6 detecteert nogal wat

Bij normaal verkeer kan de reachability-tabel geupdate worden als er verkeer ontvangen wordt, maar verkeer van een gateway heeft zelden het adres van die gateway als afzender.

CyBeR wijzigde dit bericht 26-11-2011 23:56 (9%)

Oh, ik dacht dat het macadres niet in de neighbor adv stond, dat dat adres gewoon uit het link-localadres gehaald wordt? (en dat dus afleveren van pakketjes allemaal op IP-niveau plaatsvind, i.p.v. met een ethernetconstructie zoals ARP in IPv4)

Met -e switch (goed idee):
console:

21:44:28.330447 00:16:3e:7e:ac:f0 (oui Unknown) > 00:90:cc:f4:9c:b4 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::216:3eff:fe7e:acf0 > fe80::290:ccff:fef4:9cb4: ICMP6, neighbor solicitation, who has fe80::290:ccff:fef4:9cb4, length 32

Met ip -6 neigh show zie ik de entry:
console:

fe80::290:ccff:fef4:9cb4 dev eth0 lladdr 00:90:cc:f4:9c:b4 router STALE

Er is dus een tabel met link-local naar mac-adres. Met de vraag in het pakketje zou je deze tabel van het "STALE" kunnen ontdoen... Ik ben matig overtuigd van het nut van het pakketje.

Sendy wijzigde dit bericht 27-11-2011 22:34 (56%)

Weet iemand hier hoe het nu zit met de irc van tweakers over ipv6? Ik heb een HE.net tunnel nu en ipv6 werkt. Als ik naar irc.tweakers.net ga komt die nog op ipv4 uit en de oude osiris.ipv6 werkt niet meer.

quote:

jimmy87 schreef op zondag 18 december 2011 @ 22:08:
Weet iemand hier hoe het nu zit met de irc van tweakers over ipv6? Ik heb een HE.net tunnel nu en ipv6 werkt. Als ik naar irc.tweakers.net ga komt die nog op ipv4 uit en de oude osiris.ipv6 werkt niet meer.

Dns record voor irc is v4 en v6
code:

tom$ host irc.tweakers.net
irc.tweakers.net is an alias for arethusa.tweakers.net.
arethusa.tweakers.net has address 213.239.154.12
arethusa.tweakers.net has IPv6 address 2001:990:0:1386:12::1

Hmm stom dat mirc hem dan niet pakt. Ik heb irc enabled bij HE.net dus dan zou het moeten werken. Maar als ik wil connecten omet mirc werkt het niet. Connection timeout.

mIRC doet toch geen IPv6?

quote:

CyBeR schreef op maandag 19 december 2011 @ 00:29:
mIRC doet toch geen IPv6?

Dat is jaren zo geweest maar:

http://www.mirc.com/whatsnew.txt

...
30/07/2010 - mIRC v7.1
...
IPv6 support
...

Dus als mIRC recent genoeg is doet die ipv6.

Ah, ok. Niks gezegd

Voor mensen die wachten op cisco anyconnect client met volledige ipv6 support :

quote:

I received confirmation that indeed the IPv6 feature, along with complete split-tunneling for IPv6, and correct handling of the exculsion, will be available in the Anyconnect version 3.1, expected for summer 2012.

Correspondingly there is no plan to fix this issue in the current versions, this is considered part of the new features.

Ik heb thuis een IPV6 tunnel liggen van sixxs.net. Ik gebruik de software AYIYA. Nu heb ik dus 2 adapters, 1 LAN, en 1 tunnel adapter.

Ping -6 ipv6.google.com werkt
tracert -6 ipv6.google.com werkt
Browsen naar het http://[2a00:1450:8005::68] lukt

Maar als ik wil surfen naar http://ipv6.google.com werkt dit niet. (server not found) Dus ik vermoed dat het een DNS fout is. Ik gebruik de opendns servers.

Als ik http://www.test-ipv6.com/ laat testen krijg ik de melding:
code:

IPv6 verbindingen werken maar verbindingen op basis van DNS namen gebruiken geen IPv6. Om een of andere reden voert uw browser of OS geen IPv6 DNS 'AAAA' opzoekingen uit.

Iemand een idee wat ik vergeten ben aan te passen? Het probleem is met elke browser.

Welk OS, welke router, en gebeurt het ook als je geen OpenDNS gebruikt maar google's public DNS (8.8.8.8, 8.8.4.4).

CyBeR wijzigde dit bericht 28-12-2011 19:33 (69%)

--edit---

Oplossing gevonden, blijkbaar moet je bij windows 7 elke fysieke adapter ook een ipv6 adres meegeven. In mijn geval dus een vast aangezien mijn router dit niet ondersteund

wouterDE wijzigde dit bericht 28-12-2011 19:52 (77%)

Sommige routers doen geintjes met DNS zodat shit 'beter werkt'.

Wat gebeurt er als je zelf een nslookup met type AAAA doet?

/meldt

Heb nu door de aanschaf van een Cisco 1811 eindelijk beschaafde IPv6 support. Ik had een 851W welke dit helemaal niet kon.

Router kwam met een 12.4(15) IOS geinstalleerd welke de router tijdelijk liet vastlopen bij een simpele nmap poortscan van de Sixxs tunnel endpoint. Hij draait nu 15.1 en alles lijkt nu redelijk te functioneren. Windows 7 bak erachter krijgt netjes een autoconfiguration adres en kan IPv6 websites oproepen.

Verder een apart ipv6 domeintje aangemaakt, ipv6.phoropter.nl en een al bestaand domein een AAAA record gegeven zodat ie ook naar ipv6 resolved.

Audiostreams in mijn signature zouden dus ook via ipv6 moeten werken

Krijg ipv6.phoropter.nl niet open van buiten af, staat webserver etc goed geconfigureerd?

quote:

wopper schreef op dinsdag 03 januari 2012 @ 07:30:
Krijg ipv6.phoropter.nl niet open van buiten af, staat webserver etc goed geconfigureerd?

Je Die server laat zich niet pingen en geeft geen antwoord op poort 80 of poort 443. Firewall nakijken?

Edit: niet goed gelezen

FiscBiker wijzigde dit bericht 03-01-2012 14:52 (8%)

Zou nu allemaal moeten werken, het een en ander met access lists lopen rommelen. Ik heb op basis van http://remcobressers.nl/2...co-877-cpe-device-simple/ een in en uitgaande access list gemaakt welke op basis van uitgaand verkeer terugkomend verkeer toelaten.

Zat nog lekker te klooien in de access list, /128 is een enkel IPv6 ip, niet /0, dat is het hele bereik aan adressen

Website werkt volgens http://ipv6-test.com/validate.php . Poorten 80, 8000 en 443 staan open naar mijn server. Heb ook al een luisteraar op mijn Icecast streams gehad.

Klopt het werkt nu je krijgt nu een 403 forbidden dus qua routering werkt het nu nog de webserver inrichten ;-)

Website is al jaren ingericht, echter alles wat ik niet expliciet toegang geef is 403

Zijn er bepaalde situaties waaronder tracerouting niet goed werkt? Ik heb een simpele setup die er ongeveer zo uitziet: client -(native)-> server -(tunnel)> broker . Tracerouting naar buiten gaat niet (althans, ik krijg alleen de router en eindpoint te zien. Maar de andere kant op gaat het probleemloos

Alles linux

Op 6 juni gaat het gebeuren:

http://www.worldipv6launch.org/

Eigenlijk is het nog grappig ook.

IPv6 had op 6-6-2006 het default protocol moeten worden. We hebben 6 jaar vertraging

Maar wat een goed nieuws, dit klinkt veelbelovend, er zitten genoeg grote jongens bij om echt een grote stap te maken. Ik ben misschien nog wel het meest onder de indruk van akamai. Ik hoop dat er nog een paar video-websites mee gaan doen. Ik denk dat Youtube het wel zal doen en ik hoop dat Netflix ook mee doet.

quote:

CAPSLOCK2000 schreef op vrijdag 20 januari 2012 @ 00:33:
Eigenlijk is het nog grappig ook.

IPv6 had op 6-6-2006 het default protocol moeten worden. We hebben 6 jaar vertraging

Maar wat een goed nieuws, dit klinkt veelbelovend, er zitten genoeg grote jongens bij om echt een grote stap te maken. Ik ben misschien nog wel het meest onder de indruk van akamai. Ik hoop dat er nog een paar video-websites mee gaan doen. Ik denk dat Youtube het wel zal doen en ik hoop dat Netflix ook mee doet.

Youtube is bij mij al maanden via IPv6, maar misschien is dat omdat ik via surfnet internet heb. Het lijkt me in ieder geval vreemd als ze niet mee zouden doen.

Volgens mijn verkeersstatistieken van m'n thuisverbinding bestaat het totaal verkeer voor 8% (laatste week) uit ipv6.

Zal voornamelijk youtube idd zijn en wat torrentzooi.

Youtube heeft geen AAAA- records (ook niet op Google's DNS server 8.8.4.4), dus het lijkt me sterk dat je nu wel op IPv6 zit.

Youtube gebruikt al heel lang IPv6 in productie, maar alleen voor hun videoservers; niet voor de website zelf.

Voorbeeld:

$ host o-o.preferred.ams04s07.v12.lscache1.c.youtube.com
o-o.preferred.ams04s07.v12.lscache1.c.youtube.com has address 74.125.100.140
o-o.preferred.ams04s07.v12.lscache1.c.youtube.com has IPv6 address 2a00:1450:400e:a::c

CyBeR wijzigde dit bericht 20-01-2012 23:38 (54%)

quote:

Jaap-Jan schreef op vrijdag 20 januari 2012 @ 23:34:
Youtube heeft geen AAAA- records (ook niet op Google's DNS server 8.8.4.4), dus het lijkt me sterk dat je nu wel op IPv6 zit.

Op de nameserver van xs4all wel
code:

@xs8:~$ host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.79.93
youtube-ui.l.google.com has address 74.125.79.136
youtube-ui.l.google.com has address 74.125.79.190
youtube-ui.l.google.com has address 74.125.79.91
youtube-ui.l.google.com has IPv6 address 2a00:1450:8005::5d

quote:

Keiichi schreef op vrijdag 20 januari 2012 @ 23:40:
[...]


Op de nameserver van xs4all wel
code:

@xs8:~$ host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.79.93
youtube-ui.l.google.com has address 74.125.79.136
youtube-ui.l.google.com has address 74.125.79.190
youtube-ui.l.google.com has address 74.125.79.91
youtube-ui.l.google.com has IPv6 address 2a00:1450:8005::5d

XS4ALL doet dan ook mee aan Google IPv6 whitelist. Maar Youtube's videoservers krijgen altijd een AAAA record.

Welke namen hebben die videoservers dan? Want ook ytimg.com (wat volgens mij het adres is van de serverpool) heeft bij mij geen AAAA- record.

Jaap-Jan wijzigde dit bericht 20-01-2012 23:47 (20%)

't is niet alsof er een in m'n post staat...

Sorry voor deze slowchat, maar .

quote:

TNW schreef op maandag 02 januari 2012 @ 16:24:
/meldt

Heb nu door de aanschaf van een Cisco 1811 eindelijk beschaafde IPv6 support. Ik had een 851W welke dit helemaal niet kon.

Router kwam met een 12.4(15) IOS geinstalleerd welke de router tijdelijk liet vastlopen bij een simpele nmap poortscan van de Sixxs tunnel endpoint. Hij draait nu 15.1 en alles lijkt nu redelijk te functioneren. Windows 7 bak erachter krijgt netjes een autoconfiguration adres en kan IPv6 websites oproepen.

Verder een apart ipv6 domeintje aangemaakt, ipv6.phoropter.nl en een al bestaand domein een AAAA record gegeven zodat ie ook naar ipv6 resolved.

Audiostreams in mijn signature zouden dus ook via ipv6 moeten werken

Ik heb een 1801w en alhoewel dit waarschijnlijk niet met die router te maken heeft, toch nog een aantal bugs in Windows wat betreft IPv6. Soms verliest Windows zijn default IPv6 gateway zonder reden (ik gebruik SLAAC met other-config-flag voor de DNS servers) en als ik inbel via PPTP dan verliest de verbinding stipt na 20 minuten zijn IPv6 gateway (op die PPTP verbinding).

Als je zelf ook begint te experimenteren met VPN's, PPTP+IPv6 & Cisco's IPv6 CEF is broken, met CEF aan op IPv6 niveau dan routert hij helemaal geen IPv6 pakketjes. Met CEF uit werkt het wel.

nieuws: Ziggo levert nog dit jaar ipv6-verbindingen

Het zal eens tijd worden

nu alle andere providers nog

Nu nog IPv6 ondersteuning in IPFire, dan kan ik eindelijk weer van mijn HE-tunnel gebruik maken.

Raven wijzigde dit bericht 02-02-2012 10:16 (34%)

quote:

Keiichi schreef op donderdag 02 februari 2012 @ 10:11:
nieuws: Ziggo levert nog dit jaar ipv6-verbindingen

Het zal eens tijd worden

nu alle andere providers nog

Op zich geen (goed/echt) nieuws, al lange tijd gaf Ziggo midden 2012 aan als doel voor ondersteuning van IPv6, het nieuws is dat het kennelijk wat later gaat worden.

quote:

RT @ayourtch: So far, there's been 6052 mac addresses on #cleur network, 1470 with only IPv4, 4238 with both v4 and v6, and 344 with only v6.

Laat ons zeggen dat je ipv6 dual stack wel populair kan hebben op sommige netwerken ;-)

Zal ziggo een /56, /48 of /64 subnet gaan uitdelen? Ik hoop toch echt ten minste een /56 zodat we zelf ons netwerk verder kunnen subnetten in meerdere /64s met op elk subnet SLAAC.

quote:

Magnetra schreef op donderdag 02 februari 2012 @ 19:00:
Zal ziggo een /56, /48 of /64 subnet gaan uitdelen? Ik hoop toch echt ten minste een /56 zodat we zelf ons netwerk verder kunnen subnetten in meerdere /64s met op elk subnet SLAAC.

Een /64 lijkt me niet het meest logisch. Je wil altijd wel een situatie hebben dat je router ook daadwerkelijk kan routeren en firewallen.

Op een colocatie van mij heb ik ook native IPv6, die bestaat uit een routing subnet. Hierin zit dan de gateway van de provider en het adres van mijn router. Richting dit IP adres van m'n router is een /56 of /48 geroutered.

Ik gok erop (ik weet niet hoe het bij xs4all native zit) dat het zo'n constructie zal zijn. Als ik ga gokken zal het niet groter dan /56 zijn.

Xs4all doet gewoon /48''s. Deden ze bij tunnels eerder ook, echter werd dat op een gegeven moment /56. Wellicht dat ze met native ook nog een keer die kant op gaan.

Voor het gemak zijn alle subnets (Behalve degene door lir's uitgegeven) veelvouden van 8. (blokje van 2 hex-chars). Heeft dit ook een router-technische rede?

Op een FreeBSD router ben ik namelijk een /64 block aan het verdelen in /126 blokjes. Rede dat ik hiermee aan het spelen ben, is dat ik het eigenlijk maar raar vind dat bv voor een tunnel er een gehele /64 gebruikt word alleen voor de endpoints.

Het is natuurlijk niet zo dat we snel IPv6 adressen tekort gaan komen, maar ik kan me voorstellen dat als je op hele grote schaal gaat werken dat je toch ergens tegen limieten aan kan komen en weer een nieuw subnet moet gaan aanvragen (/48 -> /56 is slehts een opdeling van 256 subnets)

sinds 24 januari worden er IPv6 prefixes van ziggo geannounced: 2001:41f0::/32, 2001:b88::/33, 2001:1c00::/23 . Wat zou 'later' dit jaar zijn. Ik vermoed dat ze al een eind op weg zijn.

quote:

henet (Hurricane Electric @ Twitter)
Heard this one already? "Maybe we should take advantage of Apple's popularity. Instead of IPv6, we could all start writing iPV6."

Misschien wordt IPv6/iPv6 dan wat sneller ingevoerd (Of Apple stapt naar de rechter....)

Raven wijzigde dit bericht 03-02-2012 09:43 (7%)

Er was op ciscolive vorige week een sessie over ipv6 deployment bij comcast, spijtig genoeg niet kunnen volgen, maar ik zal eens kijken of de sessie opgenomen is. Slides moeten in ieder geval beschikbaar zijn.

Iemand idee hoe je osx (lion) zover kan krijgen om ook z'n ipv6 adressen te registreren bij de dns server ?

(op windows moet dit door DisableReverseAddressRegistrations registry entry aan te maken met waarde 0 (default is 1))

Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

Ik hoor hier iedereen over subnets bij IPv6 e.d., maar ik heb altijd begrepen dat IPv6 aan vaste "subnets" van /64 heeft. In radvd kun je ook geen range >/64 opgeven om te advertisen.

Volgens mij mag je subnetten tot in de kleinste bits, maar autoconfiguration (waarvoor radvd nodig is) kan niet met een kleiner subnet dan /64

quote:

Keiichi schreef op woensdag 08 februari 2012 @ 11:01:
Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

Ben het net tegengekomen in mijn ccie boek het 7e bit is het U/L bit van het Mac adres. De reden dat het gedaan wordt wordt ook niet behandeld. Ik kan mijn ipv6 boek er nog even bijpakken.

quote:

The flip in step 2 has a reason. Ethernet devices usually come with a pre-configured MAC address, which is globally unique - this bit happens to be 0 if the MAC is globally assigned. This flip ensures that autoconfigured host IDs always use a large number as host ID, so that the administrator can use small numbers for manually configured hosts without risking a random collision with a MAC address.

Beetje hypothetisch geval want als je al iets statisch toewijst zal je vaker enkel de laatste 2 of 4 bytes aanpassen en de rest ervoor 0 dus altijd lager doordat die FFFE van autoconfig het al redelijk random maakt.

TrailBlazer wijzigde dit bericht 08-02-2012 21:16 (39%)

quote:

Sendy schreef op woensdag 08 februari 2012 @ 21:06:
Volgens mij mag je subnetten tot in de kleinste bits, maar autoconfiguration (waarvoor radvd nodig is) kan niet met een kleiner subnet dan /64

Klopt daarom kan je in radvd nooit kleiner dan /64 want stateloze autoconfig gaat dan de mist in. Op een PtP kan je wel een /126 gebruiken. /127 schijnt problemen te geven om een of andere reden ik vindt het sowieso onhandig om te doen.

quote:

Osiris schreef op woensdag 08 februari 2012 @ 20:59:
Ik hoor hier iedereen over subnets bij IPv6 e.d., maar ik heb altijd begrepen dat IPv6 aan vaste "subnets" van /64 heeft. In radvd kun je ook geen range >/64 opgeven om te advertisen.

Wat je met je subnets doet moet je helemaal en volledig zelf weten. Maar Stateless-autoconfig werkt alleen met /64 subnets.

quote:

Keiichi schreef op woensdag 08 februari 2012 @ 11:01:
Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

quote: http://tools.ietf.org/html/rfc5342#section-2.2.1

The Local/Global bit was inverted to make it easier for network
operators to type in local-scope identifiers. Thus, such Modified
EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are
local. Without the modification, they would have to be
02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local.

CyBeR wijzigde dit bericht 08-02-2012 21:24 (36%)

Dat heeft mijn inziens niks met elkaar te maken. Je zou ook zonder die Flip een geldig adres krijgen.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:22:
Dat heeft mijn inziens niks met elkaar te maken. Je zou ook zonder die Flip een geldig adres krijgen.

Geldig is 't sowieso, maar 't gaat om semantiek.

Anyway, ik heb mijn post geupdate met de werkelijke reden uit de RFC; eerder had ik 't ergens anders van.

Dat zou dus beteken dat ik geen ipv6 adres
02-00-00-00-00-00-00-02 zou kunnen configureren omdat dat ipv6 adres bij autoconfig zou horen.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:38:
Dat zou dus beteken dat ik geen ipv6 adres
02-00-00-00-00-00-00-02 zou kunnen configureren omdat dat ipv6 adres bij autoconfig zou horen.

Strict gezien correct.

<< Even het logo van kame.net wat verkleind voor dit forum. En natuurlijk alleen te zien indien de client verbindt met IPv6.

Ehm, ik zie gewoon een plaatje, zonder IPv6 (helaas). Of hoort het een animatie te zijn indien IPv6 werkt?

Hij zwemt weg

quote:

Raven schreef op donderdag 09 februari 2012 @ 16:38:
Ehm, ik zie gewoon een plaatje, zonder IPv6 (helaas). Of hoort het een animatie te zijn indien IPv6 werkt?

Dan werkt het precies zoals het hoort.

Verbindt je met IPv4: statisch plaatje.
Verbindt je met IPv6: bewegend plaatje.

Zo was het ook op http://www.kame.net/

quote:

Keiichi schreef op donderdag 09 februari 2012 @ 16:40:
Hij zwemt weg

Ik heb alleen een of andere lelijkerd met een nikon strap om z'n hoofd.

quote:

Jaap-Jan schreef op donderdag 09 februari 2012 @ 16:41:

Althans, dat probeert ie.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:09:
[...]

Klopt daarom kan je in radvd nooit kleiner dan /64 want stateloze autoconfig gaat dan de mist in. Op een PtP kan je wel een /126 gebruiken. /127 schijnt problemen te geven om een of andere reden ik vindt het sowieso onhandig om te doen.

Bij /127 heb je alleen een netwerk en 'broadcast' adres. Het lijkt me dan vrij logisch dat het problematisch is.

Keiichi wijzigde dit bericht 09-02-2012 16:46 (61%)

quote:

CyBeR schreef op donderdag 09 februari 2012 @ 16:42:
Ik heb alleen een of andere lelijkerd met een nikon strap om z'n hoofd.

Check. Dan heb je webicons uitgeschakeld. En bedankt voor het compliment.

Jaap-Jan wijzigde dit bericht 09-02-2012 16:45 (7%)

quote:

Jaap-Jan schreef op donderdag 09 februari 2012 @ 16:41:
[...]

Dan werkt het precies zoals het hoort.

Verbindt je met IPv4: statisch plaatje.
Verbindt je met IPv6: bewegend plaatje.

Zo was het ook op http://www.kame.net/

Ah okee
Hopelijk komt er eens een keer IPv6 ondersteuning in IPFire...

quote:

Keiichi schreef op donderdag 09 februari 2012 @ 16:43:
[...]
Bij /127 heb je alleen een netwerk en 'broadcast' adres. Het lijkt me dan vrij logisch dat het problematisch is.

Met IPv4 heb je dat probleem ook met /31's op p2p interfaces. Echter hebben ze daar wel een RFC over geschreven: http://www.ietf.org/rfc/rfc3021.txt

Tweakers.net op 6 juni over IPv6 bereikbaar?
Bron: reviews: Tweakers.net-serverbeheer: Project Phoenix

Goed zoeken waar het staat

quote:

Magnetra schreef op zondag 12 februari 2012 @ 01:28:
Tweakers.net op 6 juni over IPv6 bereikbaar?
Bron: reviews: Tweakers.net-serverbeheer: Project Phoenix

Goed zoeken waar het staat

Gevonden!

Ik ben benieuwd! Het zou wel eens tijd worden

Ik heb een makkelijk manier gevonden om in het modem van ziggo te komen. Zo'n ubee modem reageert netjes op IPv6 packets. pingetje naar ff02::1. Reply van het modem. Daarna aan de hand van het LL adres even via de browser verbinden.

Werkt alleen als je in hetzelfde segment van het netwerk als het modem zit. (Met een router ertussen gaat het niet werken)

Is dat iets wat met IPv4 niet kan dan?

Ik geloof dat als je er geen router tussen zet (en dus in principe een publiek v4 adres krijgt) je in een ander subnet zit dan het modem (standaard 192.168.1.100, oid). Dus met v4 kan het wel, maar dan moet je handmatig even in hetzelfde subnet gaan zitten, voor zover ik weet

quote:

CyBeR schreef op maandag 13 februari 2012 @ 13:49:
Is dat iets wat met IPv4 niet kan dan?

Jawel, maar het is een hel om dat adres te achterhalen.

quote:

Keiichi schreef op maandag 13 februari 2012 @ 13:38:
Ik heb een makkelijk manier gevonden om in het modem van ziggo te komen. Zo'n ubee modem reageert netjes op IPv6 packets. pingetje naar ff02::1. Reply van het modem. Daarna aan de hand van het LL adres even via de browser verbinden.

Werkt alleen als je in hetzelfde segment van het netwerk als het modem zit. (Met een router ertussen gaat het niet werken)

Je bedoelt de non-wifi non-router modem (EVM320B of zo)?

Zou wel moeten werken als je router goed instelt met IPv6 route naar je modem.

Overigens doen alle DOCSIS 3.0 apparaten standaard IPv6.

stduke wijzigde dit bericht 28-03-2012 13:36 (0%)
Reden: s/router/non-router/

Okay IPv6 guru's, ik heb een kleine toko met eigen servers die afhankelijk is van internet en dus heb ik twee internetverbindingen. Eentje valt uit. Wat nu, even snel OSPF of BGP implementeren?

Echt, IPv6 is gewoon KAK. Er is niet nagedacht over de implementatie in kleine omgevingen. Ik snap niet hoe mensen kunnen blijven roepen dat het de redding van netwerken is. Geef me mijn NAT en mijn private unrouted address spaces terug!

deadlock2k wijzigde dit bericht 01-04-2012 02:12 (10%)

'Even snel'? Nee, dat had je vantevoren moeten doen. Duh.

quote:

deadlock2k schreef op zondag 01 april 2012 @ 02:09:
Echt, IPv6 is gewoon KAK. Er is niet nagedacht over de implementatie in kleine omgevingen. Ik snap niet hoe mensen kunnen blijven roepen dat het de redding van netwerken is. Geef me mijn NAT en mijn private unrouted address spaces terug!

Dit is wel de mooiste en helaas ook meest trieste uitspraak die ik in tijden gehoord heb.. Dus omdat jíj incompetent bent, is IPv6 "kak"? Laat me niet lachen

quote:

Osiris schreef op zondag 01 april 2012 @ 08:01:
[...]

Dit is wel de mooiste en helaas ook meest trieste uitspraak die ik in tijden gehoord heb.. Dus omdat jíj incompetent bent, is IPv6 "kak"? Laat me niet lachen

Toko van vijf man, waarvan ze een absolute afhankelijkheid hebben van internet en ze doen niets technisch maar hebben wel een server op lokatie die ook extern beschikbaar is. Hoe ga je dat oplossen? Er zijn heel erg veel van dit soort bedrijven. Dit heeft alles te maken met incompetentie van de bedenkers van het protocol en niets met die van de beheerders. Als je genoeg geld neerlegt dan krijgt iedereen wat hij wil maar er moet een eenvoudige oplossing komen.

NAT66 is nodig en wel z.s.m.

deadlock2k wijzigde dit bericht 01-04-2012 12:46 (22%)

Wat is het probleem dat IPv6 in dit geval oplevert (voor mij, de leek)? En ik dacht dat o.a BSDs/pf ensinds een tijdje geleden ook netfilter NAT66 doen?

begintmeta wijzigde dit bericht 01-04-2012 13:00 (37%)

Ik zie 't probleem ook niet en al helemaal niet hoe NAT66 het op zou lossen?

Hoe zou 't met IPv4 zijn dan?

Osiris wijzigde dit bericht 01-04-2012 13:18 (17%)

quote:

deadlock2k schreef op zondag 01 april 2012 @ 12:43:
[...]

Toko van vijf man, waarvan ze een absolute afhankelijkheid hebben van internet en ze doen niets technisch maar hebben wel een server op lokatie die ook extern beschikbaar is. Hoe ga je dat oplossen?

Vraag 't eens aan je ISP.

quote:

deadlock2k schreef op zondag 01 april 2012 @ 12:43:
[...]

Toko van vijf man, waarvan ze een absolute afhankelijkheid hebben van internet en ze doen niets technisch maar hebben wel een server op lokatie die ook extern beschikbaar is. Hoe ga je dat oplossen? Er zijn heel erg veel van dit soort bedrijven. Dit heeft alles te maken met incompetentie van de bedenkers van het protocol en niets met die van de beheerders. Als je genoeg geld neerlegt dan krijgt iedereen wat hij wil maar er moet een eenvoudige oplossing komen.

NAT66 is nodig en wel z.s.m.

Serieus, de mensen die IPv6 bedacht hebben beschikken over iets meer kennis dan de gemiddelde sysadmin.

NAT is NOT done en dat willen we ook _NIET_ terug hebben. NAT maakt meer kapot dan je lief is.

Eigenlijk wil jij dus gewoon non-routable IPv6 adressen. Hoewel het wordt afgeraden bestaat het wel degelijk.

Echter, maak gewoon gebruik van bijv RA's in je lokale serverpark, blokkeer alle inbound connections op je router/firewall en het spulletje draait gewoon prima.

Ik heb inmiddels IPv6 geïmplementeerd bij een grote ISP (enkele duizenden servers), heb daar toch geen enkel moment behoefte aan NAT66 gehad. (NAT666 anyone?)

quote:

deadlock2k schreef op zondag 01 april 2012 @ 12:43:
[...]
NAT66 is nodig en wel z.s.m.

NAT zuigt.

Je legt maar een VPN aan dan kan je ook overal bij. Zónder re-addressing.

Ik denk dat er helaas overal wel een implementatie van NAT voor IPv6 gemaakt word. Als je IPv4 NAT hebt is dat qua kernelcode vrij makkelijk om te zetten naar IPv6.

quote:

webfreakz.nl schreef op zondag 01 april 2012 @ 13:21:
[...]


NAT zuigt.

Je legt maar een VPN aan dan kan je ook overal bij. Zónder re-addressing.

NAT zuigt helemaal niet. NAT is fantastisch. De reden waarom jij vindt dat NAT zuigt is omdat jij het als netwerkbeheerder bekijkt. Voor eindgebruikers is NAT geweldig. En dat kan het onder IPv6 ook zijn.

Hoezo je legt maar een VPN aan? Van waar naar waar?

quote:

Osiris schreef op zondag 01 april 2012 @ 13:17:
Ik zie 't probleem ook niet en al helemaal niet hoe NAT66 het op zou lossen?

Hoe zou 't met IPv4 zijn dan?

Als normaal bedrijf heb je geen geld om een IP-block te kopen en tegen twee internetproviders te zeggen dat ze het op die en die manier moeten routeren. Private address spaces zijn nodig om ervoor te zorgen dat er intern niets verandert. Als je van ISP A naar ISP B een failover doet dan veranderen alle IP-adressen in je interne netwerk. Interne apparatuur als printers en servers worden dus onbereikbaar tenzij je een netwerkbeheerder in huis hebt met verstand van zaken.

deadlock2k wijzigde dit bericht 01-04-2012 22:18 (42%)

quote:

deadlock2k schreef op zondag 01 april 2012 @ 22:15:
[...]
Voor eindgebruikers is NAT geweldig.

Supergeweldig inderdaad dat 99 van de 100 IM filetransfers niet werken omdat er NAT tussenzit. Om maar een simpel voorbeeld te noemen.

quote:

CyBeR schreef op zondag 01 april 2012 @ 22:17:
[...]


Supergeweldig inderdaad dat 99 van de 100 IM filetransfers niet werken omdat er NAT tussenzit. Om maar een simpel voorbeeld te noemen.

Is dat niet iets wat in 2005 zo'n beetje opgelost is? Ik heb UPNP al een jaartje uitstaan in mijn router en het is bij mij nog nooit misgegaan, of is MS RRAS uit W2K3SP2 toch nog ergens goed in?

quote:

deadlock2k schreef op zondag 01 april 2012 @ 22:20:
[...]

Is dat niet iets wat in 2005 zo'n beetje opgelost is? Ik heb UPNP al een jaartje uitstaan in mijn router en het is bij mij nog nooit misgegaan, of is MS RRAS uit W2K3SP2 toch nog ergens goed in?

Nee, dat is nog steeds kut. En UPNP is een workaround, geen oplossing.

quote:

deadlock2k schreef op zondag 01 april 2012 @ 22:15:
[...]

NAT zuigt helemaal niet. NAT is fantastisch. De reden waarom jij vindt dat NAT zuigt is omdat jij het als netwerkbeheerder bekijkt. Voor eindgebruikers is NAT geweldig. En dat kan het onder IPv6 ook zijn.

Geweldig? Je moet eens weten wat er voor o.a. SIP voor rare fratsen uitgehaald worden om het te laten werken door NAT gateways heen.

quote:

Als normaal bedrijf heb je geen geld om een IP-block te kopen en tegen twee internetproviders te zeggen dat ze het op die en die manier moeten routeren. Private address spaces zijn nodig om ervoor te zorgen dat er intern niets verandert. Als je van ISP A naar ISP B een failover doet dan veranderen alle IP-adressen in je interne netwerk. Interne apparatuur als printers en servers worden dus onbereikbaar tenzij je een netwerkbeheerder in huis hebt met verstand van zaken.

Hier is IPv6 met Multi Homing voor. Of SHIM6. Dat het nog niet beschikbaar is of zelfs qua implementatie rammelt dat is een andere zaak. Hiervoor moet je de betrokken fabrikanten een schop geven. Maar de specificaties zijn er.

quote:

deadlock2k schreef op zondag 01 april 2012 @ 22:15:
Als normaal bedrijf heb je geen geld om een IP-block te kopen en tegen twee internetproviders te zeggen dat ze het op die en die manier moeten routeren. Private address spaces zijn nodig om ervoor te zorgen dat er intern niets verandert. Als je van ISP A naar ISP B een failover doet dan veranderen alle IP-adressen in je interne netwerk. Interne apparatuur als printers en servers worden dus onbereikbaar tenzij je een netwerkbeheerder in huis hebt met verstand van zaken.

Wat is nou precies je probleem? Staat de server op het kantoor of op een andere locatie? En hoe is het netwerk in de IPv4-situatie geregeld? Ik neem aan dat je in de IPv4-situatie ook bij beide internetproviders een verschillend IPv4-adres kreeg, dus dat verandert ook niet bij IPv6.
In IPv6 bestaan er ook gewoon private address spaces, namelijk de site-local en link-local adressen. Die kan je net zo toewijzen als je nu met IPv4 doet (statisch of DHCP) en ook nog eens met auto-configuration.

Je kunt je gal spuwen over IPv6 en smeken dat je gebeden gehoord worden en dat het toch niet ingevoerd gaat worden. Je kunt je ook verdiepen in de materie... Vraag oudere systeembeheerders eens hoe zij het oplosten, voordat eind jaren '90 NAT werd geïntroduceerd als workaround voor het dreigend IP-adressen tekort. Het internet is nooit ontworpen om met NAT te werken, het is een workaround. En alles wat bedacht wordt om programmatuur werkend te krijgen met NAT is ook een workaround. En al die workarounds maken het systeem niet bepaald eenvoudig en stabiel, en zeker niet goedkoper door de tijd die er in gestoken moet worden.

Er zijn hier genoeg mensen die een oplossing voor jouw situatie kunnen verzinnen. Kom eens met een schema hoe jouw configuratie eruit ziet, dan verzinnen wij een oplossing

Ik vermoed dat hij zo afgeeft op IPV6 omdat hij nu dus met het probleem zit dat, als zijn routertje failover doet naar de andere internetverbinding, de IPV6 prefix ook verandert (en die van z'n lokale netwerk dus ook).

Echter, dat blijft een non-argument. Er zijn zoals Morcik zegt met IPV6 genoeg manieren te bedenken om te zorgen dat dit niet gebeurt. Ook met IPV6 kan je gewoon routeren van en naar private address spaces en dus zorgen dat de router, die tussen je lokale netwerk en de internetverbinding(en) zit ervoor zorgt dat je interne address space niet verandert.

Dat klinkt een beetje als NAT eymey

quote:

Eärendil schreef op zondag 01 april 2012 @ 23:52:
namelijk de site-local en link-local adressen

Site-local adressen zijn deprecated, maar er is wel een alternatief in de vorm van unique-local-unicast.

quote:

Osiris schreef op maandag 02 april 2012 @ 09:25:
Dat klinkt een beetje als NAT eymey

Klinkt als dual-addressen, met interne adressen die niet veranderen en gewone adressen voor de internetconnectiviteit.

Precies.

Anders heeft deadlock2k zeker wel een puntje.... in kleinere SOHO's die multi-homed werken (2 WAN Verbindingen die elkaar kunnen overnemen) MOET je gewoon kunnen werken met een lokaal gedeelte waarvan de IP adressen niet veranderen als de prefix van je actieve WAN verbinding verandert.

Hoewel dat ook op zich potentieel niet zo heel erg hoeft te zijn, want 1 lokaal netwerk apparaat kan natuurlijk prima twee globaal routeerbare IPv6 adressen hebben en een derde (lokaal) adres voor de lokale adressering binnen het LAN. Maar kan me voorstellen dat mensen dat niet prettig vinden.

Maar zijn er geen common practices / usecases / voorbeelden hiervoor te vinden?.....

quote:

eymey schreef op maandag 02 april 2012 @ 09:04:
Ik vermoed dat hij zo afgeeft op IPV6 omdat hij nu dus met het probleem zit dat, als zijn routertje failover doet naar de andere internetverbinding, de IPV6 prefix ook verandert (en die van z'n lokale netwerk dus ook).

Zou het met IPv6 niet makkelijker worden om van ripe als niet-ISP om een /64 block te krijgen die je nog door providers moet laten routeren? Je kunt dan je /64 laten advertisen door 2 verschillend AS-netwerken zodat je zelfs nog aan loadbalancing doet

Alleen heb ik geen flauw idee wat voor een impact dit op het hele routingsysteem gaat hebben, ik heb een flauw vermoeden als dit op grote schaal toegepast word dat er gigantische routingtabellen ontstaan.

quote:

Keiichi schreef op donderdag 05 april 2012 @ 14:52:
[...]


Zou het met IPv6 niet makkelijker worden om van ripe als niet-ISP om een /64 block te krijgen die je nog door providers moet laten routeren? Je kunt dan je /64 laten advertisen door 2 verschillend AS-netwerken zodat je zelfs nog aan loadbalancing doet

Dat is niet zo'n probleem inderdaad. Krijg je wel een /48 voor overigens.

Meeste huis tuin en keuken routers gaan alleen geen bgp praten.

quote:

DDX schreef op donderdag 05 april 2012 @ 15:23:
Meeste huis tuin en keuken routers gaan alleen geen bgp praten.

Huis tuin en keuken gebruikers hoeven geen subnet die altijd hetzelfde is.

quote:

Keiichi schreef op donderdag 05 april 2012 @ 14:52:
[...]


Zou het met IPv6 niet makkelijker worden om van ripe als niet-ISP om een /64 block te krijgen die je nog door providers moet laten routeren? Je kunt dan je /64 laten advertisen door 2 verschillend AS-netwerken zodat je zelfs nog aan loadbalancing doet

Alleen heb ik geen flauw idee wat voor een impact dit op het hele routingsysteem gaat hebben, ik heb een flauw vermoeden als dit op grote schaal toegepast word dat er gigantische routingtabellen ontstaan.

Probleem is inderdaad je route tabel heel erg groot wordt wat je niet wil hebben.
Daarom zal een /48 ook het minimale zijn wat announced moet worden door een ISP. Bij IPv4 is dat nu een /24 subnet.

Afgelopen jaar is er bij mijn werkgever ook overgegaan van meerdere IPv4 en IPv6 blokken naar een /24 IPv4 Provider independent en een /48 IPv6 Provider independent.

Het enige wat ik op kan merken is, hadden we het maar eerder gedaan. De failover is transparent en zonder issues. Het is erg fijn.

Je kan tegenwoordig zonder al te veel kosten al een PI space krijgen, en zelfs met de RIPE adres crunch is het als nieuwe klant geen probleem om een /24 te krijgen.

Voor IPv6 thuisgebruikers en power users, gebruik maar NPt als je wil.

Vooralsnog is het idee met NPt om 1 globale prefix als de "standaard" in te stellen, en dan de backup internet lijn via NPt het internet op te krijgen zodat er alleen in een failover situatie issues zijn met SIP en dergelijke. Of andere onvoorziene adres (niet poort) vertalingen.

Overigens, ze hebben er iets voor uitgevonden om je server terug te vinden. Dat heet DNS. Installeer een DynDNS client op je server welke met enige regelmaat het IPv6 adres bijwerkt, het adres is globaal, en de DNS weet waar ie is.

Zaken doen kost geld, wen er maar aan :-)

quote:

DDX schreef op donderdag 05 april 2012 @ 15:23:
Meeste huis tuin en keuken routers gaan alleen geen bgp praten.

Huist-tuin-en-keukengebruikers hebben dat dan ook niet nodig.

LISP?