Het grote IPv6 topic

[Olaf van der Spek]

LauPro schreef op dinsdag 14 juni 2011 @ 22:18:
Ga je dus op een Linux machine meer dan 1000 IPv6 IP's aanspreken, dan is er een issue.

Wat is de limiet op de router? 1k klinkt wel erg laag.
Is het trouwens niet zo dat tresh3 aangeeft wanneer de GC draait? Het geeft niet de max size aan volgens mij.

[ Voor 38% gewijzigd door Olaf van der Spek op 15-06-2011 00:31 ]

[LauPro]

In je LAN/broadcast domain idd.

[CyBeR]

LauPro schreef op dinsdag 14 juni 2011 @ 21:47:
[...]
Dat van die 256 is wat mij geleerd is destijds bij CCNA en het is zeker mogelijk om meer hosts in een broadcast domain te stoppen maar de vraag is of het wenselijk is, gezien het vele traffic dat het gaat genereren: dhcp, samba etc. Een multicast blijft een multicast.

Ja, maar Cisco heeft verzuimd je te leren waaróm ze meer dan ~256 niet aanraden. Dat is namelijk omdat een host die een broadcast packet ontvangt, die móet processen. Het kan tenslotte een ARP zijn, en als dat zo is kan het een ARP zijn die om jouw IP-adres vraagt. En zelfs al is dat niet zo moet je checken of er iets draait wat naar die broadcasts tracht te luisteren (om maar een vooorbeeld te noemen, een dhcpd.) Vroeger waren de pc's en routers (belangrijke, kom ik zo op) nog niet zo krachtig, dus slokte dat een relatief grote hoeveelheid CPU tijd op, en had het dus een merkbare invloed op je computer. Sommige routers (Cisco's met name, vanwege de opzet van het OS) hadden dat probleem ook. Dat ging zover dat die routers feitelijk gewoon omvielen omdat de control plane zo druk bezig was met broadcasts processen, dat andere processen zoals BGP geen of niet genoeg tijd kregen. Dag routing tabel, dag connectivity. Bij AMS-IX (een /23 op hun ISP vlan) draait men nog altijd een perl script om dit probleem zoveel mogelijk te voorkomen omdat de platforms die dat probleem hebben daar nog altijd voorkomen.

Fast forward naar vandaag: dit probleem bestaat bijna niet meer op moderne hardware. Ik heb dit ook daadwerkelijk getest, overigens; alleen bepaalde Cisco's hebben er nog altijd moeite mee. De rest is ofwel snel genoeg om een belachelijke hoeveelheid broadcast te checken (ik heb er een volledige gigabit/sec tegenaan gegooid, puur aan ARP verkeer) ofwel doet ARP in hardware (intel kaarten bijvoorbeeld doen dit.)

IPv6 lost het probleem nog anders op: ND werkt met multicast, waarbij het multicastadres afhankelijk is van het IP-adres dat je probeert te verbinden met een MAC-adres. Ethernetkaarten kunnen filteren op bepaalde MAC-adressen en de rest gewoon blokkeren, zodat ook dat geen probleem veroorzaakt als er veel tevoorschijn komt. (Ik meen dat sommige nieuwere kaarten overigens ook ND overnemen van je OS.)

Dat ze achter hetzelfde mac adres zitten maakt voor de implementatie niet uit, het zal gewoon een entry kosten.

Nee, dat maakt wel uit, afhankelijk van op welke laag je kijkt. Jij gooit dat nogal door elkaar op dit moment. Tenzij je zeer vreemde fratsen aan het uithalen bent (is af te raden) hebben alle aliased IP's op een enkele (V)NIC hetzelfde MAC-adres. Op laag 2 (ethernet) is er dus niets aan de hand, al bindde je een volledige /48 op je nic.

En ja het is zeker denkbaar dat je als hoster elke site een eigen IPv6 nummer geeft, dat maakt het eea alleen maar eenvoudig. Heb je duizenden domeinen onder je beheer, verspreid over een cluster van webservers, dan krijg je dus automatisch een probleem met deze limiet. Niet alleen de tables van de switches gaan vollopen, ook de tables van de OS'en. Ik ben nog op zoek wat nu precies de limiet van de ARP table in Linux is, maar laat dit 8k zijn dan is het dus maximaal 8000 hosts per server. Nu is eigenlijk alleen de communicatie tussen gateway en host belangrijk maar toch. Als je bijvoorbeeld kijkt naar virtualisatie en je hebt een bak met 32 cores en 320 GB ram, dan is het zeker denkbaar dat je 8000 hosts kan hebben (met shell servers oid).

Tsja, ik weet niet of het handig is om het op die manier te doen. Dat wil zeggen, op die schaal. Ik heb het niet geprobeerd en weet van niemand die 't doet.

Als je het doet, zou ik een andere truuk uithalen. Namelijk een subnet routeren naar de betreffende machine, en al je IP's daaruit betrekken. Bijvoorbeeld, in je router geef je aan '2001:1234:1::/115 via 2001:1234::1'. Je ND verkeer ben je nu kwijt, maar toch gaan er 8192 IP's richting die doos. Zit je nog wel aan een potentieel maximum aan wat linux je laat binden.

Dat 'eruit knikkeren' is nogal een performance issue want op dat moment is er dus geen lookup mogelijk op dat ip, gevolg is dat verdere communicatie niet kan plaatsvinden.

Nee hoor. Communicatie is prima mogelijk. Op het moment dat jij namelijk een IP probeert te bereiken (in jouw subnet) en je hebt daar geen MAC van in je cache, dan stuur je een ARP (of Neighbour Solicitation in v6) en prop je het antwoord in je cache. Was je cache vol? Dan neem je de oudste entry en die delete je. Communicatie stopt niet. Als je het vaak genoeg moet doen wordt 't vanzelf een performance probleem, dat is waar.

Je hebt gelijk dat men filtert op de kaart zelf, maar ook daar speelt dit probleem omdat deze kaart ook een cache moet hebben.

Neuh. Die kaart moet alleen weten welke IP-adressen 'ie voor moet antwoorden. Ik kan me voorstellen dat dat aantal gelimiteerd is op iets ver onder de 8k overigens. Bij IPv6 is 't een kwestie van selectie op welke multicast-adressen níet genegeerd moeten worden.

Tijdens WTH in 2005 heb ik een demo gezien waarbij men switches kon laten 'crashen' door met een laptop of 2-3 random mac addressen af te gaan. Vervolgens was er dus nog nauweiljks verkeer mogelijk op die switch omdat de ARP table vol was en er dus niets meer viel te switchen, De meeste switches hebben FIFO echter een ARP table overrun is altijd een probleem imo.

Je hebt dan de combinatie van een goedkope switch met een volle CAM-tabel gevonden. Het is de bedoeling dat een switch met een volle CAM tabel alle resterende frames broadcast ('flooden', in het juiste lingo). Natuurlijk houdt niet elke el-cheapo hardwareboer zich aan dat soort ideeën.

[LauPro]

CyBeR schreef op woensdag 15 juni 2011 @ 00:59:
Ja, maar Cisco heeft verzuimd je te leren waaróm ze meer dan ~256 niet aanraden. Dat is namelijk omdat een host die een broadcast packet ontvangt, die móet processen.

Dank voor het opfrissen echter dat zeg ik toch ook : Hoe meer hosts in je broadcast domain hoe meer 'sluipverkeer'.

IPv6 lost het probleem nog anders op: ND werkt met multicast, waarbij het multicastadres afhankelijk is van het IP-adres dat je probeert te verbinden met een MAC-adres. Ethernetkaarten kunnen filteren op bepaalde MAC-adressen en de rest gewoon blokkeren, zodat ook dat geen probleem veroorzaakt als er veel tevoorschijn komt. (Ik meen dat sommige nieuwere kaarten overigens ook ND overnemen van je OS.)

Ik begrijp het principe van multicasts maar er zijn altijd nog protocollen die broadcasts zullen blijven doen. DHCP zal met IPv6 vrijwel uitsterven (alleen voor diskless e.d.) echter een protocol als Samba is gewoon gebouwd met broadcasts, die gaan niet opeens multicasts gebruiken omdat de structuur anders is. Hetzelfde met de VLC broadcastfunctie. Natuurlijk kan je dergelijke protocollen weren uit je broadcast domain echter vergt dat ook weer speciale apparatuur en kennis.

Nee, dat maakt wel uit, afhankelijk van op welke laag je kijkt. Jij gooit dat nogal door elkaar op dit moment. Tenzij je zeer vreemde fratsen aan het uithalen bent (is af te raden) hebben alle aliased IP's op een enkele (V)NIC hetzelfde MAC-adres. Op laag 2 (ethernet) is er dus niets aan de hand, al bindde je een volledige /48 op je nic.

Wat ik inderdaad door elkaar gooide was ARP en de CAM table - of misschien beter gezegd, daar waar ik switch zei bedoelde ik router.

Als je het doet, zou ik een andere truuk uithalen. Namelijk een subnet routeren naar de betreffende machine, en al je IP's daaruit betrekken. Bijvoorbeeld, in je router geef je aan '2001:1234:1::/115 via 2001:1234::1'. Je ND verkeer ben je nu kwijt, maar toch gaan er 8192 IP's richting die doos. Zit je nog wel aan een potentieel maximum aan wat linux je laat binden.

Dat zou inderdaad een oplossing kunnen zijn, het klinkt mij echter nog wel als een workaround. Als men een efficient lookup systeem heeft dan zou makkelijk een vol /112 (65535 hosts) direct toegankelijk moeten zijn.

Als je het vaak genoeg moet doen wordt 't vanzelf een performance probleem, dat is waar.

Dat was dus mijn punt, als je limit 1000 is en je hebt 2000 hosts actief dan zie ik vrij snel een performance issue ontstaan van TCP/IP transmissies met packet drops. Het is misschien een leuke testcase.

Neuh. Die kaart moet alleen weten welke IP-adressen 'ie voor moet antwoorden. Ik kan me voorstellen dat dat aantal gelimiteerd is op iets ver onder de 8k overigens. Bij IPv6 is 't een kwestie van selectie op welke multicast-adressen níet genegeerd moeten worden.

Nogmaals, een IPv6 broadcast blijft een broadcast.

Je hebt dan de combinatie van een goedkope switch met een volle CAM-tabel gevonden. Het is de bedoeling dat een switch met een volle CAM tabel alle resterende frames broadcast ('flooden', in het juiste lingo). Natuurlijk houdt niet elke el-cheapo hardwareboer zich aan dat soort ideeën.

Ook dat broadcasten zal natuurlijk teneinde de switch onderuit halen. Iig wat ik aan wil geven: stel je hebt virtuele machines met elke een eigen virtuele nic en je hangt die gebridged aan een externe switch/router dan heb je al een vergelijkbare situatie . In dat geval dus ook maar die router virtualiseren of een goede vlan-setup maken.

[CyBeR]

LauPro schreef op woensdag 15 juni 2011 @ 01:27:
[...]
Dank voor het opfrissen echter dat zeg ik toch ook : Hoe meer hosts in je broadcast domain hoe meer 'sluipverkeer'.

Is ook zo. Maar dat wat het punt niet. Het punt is of dat 'sluipverkeer' een probleem is.

Ik begrijp het principe van multicasts maar er zijn altijd nog protocollen die broadcasts zullen blijven doen. DHCP zal met IPv6 vrijwel uitsterven (alleen voor diskless e.d.) echter een protocol als Samba is gewoon gebouwd met broadcasts, die gaan niet opeens multicasts gebruiken omdat de structuur anders is. Hetzelfde met de VLC broadcastfunctie. Natuurlijk kan je dergelijke protocollen weren uit je broadcast domain echter vergt dat ook weer speciale apparatuur en kennis.

Het idee is wel dat broadcasting oprot. Dat is namelijk kansloos en nergens voor nodig. Ook VLC, Samba, etc. zijn niet verplicht broadcast te gebruiken; multicast is daar veel en veel beter voor. Zelfs al doet je lokale netwerk niets anders met multicasten dan het simpelweg broadcasten.

Dat zou inderdaad een oplossing kunnen zijn, het klinkt mij echter nog wel als een workaround. Als men een efficient lookup systeem heeft dan zou makkelijk een vol /112 (65535 hosts) direct toegankelijk moeten zijn.

Tsja, je hebt nogal een edge case te pakken. Ga er maar niet van uit dat daar rekening mee gehouden wordt.

Dat was dus mijn punt, als je limit 1000 is en je hebt 2000 hosts actief dan zie ik vrij snel een performance issue ontstaan van TCP/IP transmissies met packet drops. Het is misschien een leuke testcase.

Als ze alle 2000 daadwerkelijk actief zijn heb je inderdaad een probleem. Dat heb ik niet ontkend, ik zei alleen dat je niet 100% onbereikbaar zult worden. En feitelijk hoeft alleen je router maar overweg te kunnen met al je adressen. Hoevaak heb jij twee dozen die via 8000 ip-adressen met elkaar lullen?

Nogmaals, een IPv6 broadcast blijft een broadcast.

Niet helemaal. Een IPv6 'broadcast' is eigenlijk gewoon een multicast waarvan aangenomen wordt dat iedereen er naar luistert. Edoch is dat op geen enkele wijze verplicht omdat je communicatiemogelijkheden er niet van af hangen.

Ook dat broadcasten zal natuurlijk teneinde de switch onderuit halen.

Neuh. Maar ook hier geldt: je performance zakt wel in. Je maakt, voor die packets die niet meer in de CAM tabel passen, in essentie een hub van je switch.

Overigens: die limiet van 8k geldt voor kleinere switches tot een max van een poort of 48. De grotere modellen zijn voorzien van beduidend meer CAM geheugen, vaak 64000 of zelfs meer.

Dit verhaaltje is trouwens al een paar jaar bekend en limiteert zich niet tot IPv6.

Iig wat ik aan wil geven: stel je hebt virtuele machines met elke een eigen virtuele nic en je hangt die gebridged aan een externe switch/router dan heb je al een vergelijkbare situatie . In dat geval dus ook maar die router virtualiseren of een goede vlan-setup maken.

Feitelijk is er geen verschil tussen VM's met een eigen vnic en fysieke machines met elk een eigen nic. Je moet alleen je infra opschalen om rekening te houden met de limieten van de hardware. Bijvoorbeeld, je switches inkopen op CAM-grootte en niet goedkoop proberen te doen. Je router idem; net zoals je geen ARM doosje met 128MB geheugen en Quagga een full table moet laten routen, moet je geen router kopen die maar een paar honderd ARP/ND entries aankan als je van plan bent duizenden adressen te gebruiken (workaround beschikbaar of niet).

[Eärendil]

Sendy schreef op zaterdag 11 juni 2011 @ 22:22:
Heeft de wan-interface van je router (in zo'n router-firewall-switch-accesspointkastje) een ipadres uit je geassignde prefix nodig?

Ik heb een VDSL verbinding die ik niet naar een Fritzbox leidt, maar via een DrayTek Vigor 2750 naar een Planex MZK-W04NU met OpenWRT. Ik heb een apart Wifi en Lan netwerk. Met dhcp6c krijgen mijn loopback, lan, en wifi interface een adres onder mijn prefix (in drie verschillende netwerken in de 16-bits die ik kan kiezen). radvd geeft het Wifi en Lan netwerk prefixen. Dat werkt allemaal.

Ik vind het raar dat ik een prefix assign aan mijn loopback-interface. Dit stond al in de default/voorbeeld configuratie van wide-dhcp6 (client). De default configuratie heeft geen definitie voor de prefix van het wan-interface.

Ik denk dat de spullenboel werkt omdat mijn router nu via link-localadressen communiceert met de buitenwereld. Dat lijkt me prima, want mijn router hoeft niet per sé via internet benaderd te worden. Maar het lijkt er nu wel op dat mijn loopback-interface via het internet benaderd kan worden?

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          inet6 addr: 2001:yyyy:xxxx:0:200:ff:fe00:0/64 Scope:Global

pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:83.163.xxx.yy  P-t-P:194.109.5.203  Mask:255.255.255.255
          inet6 addr: fe80::a8ac:3776:1633:6596/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

wlan0     Link encap:Ethernet  HWaddr 00:90:CC:F4:9C:B4
          inet addr:172.31.108.1  Bcast:172.31.108.255  Mask:255.255.255.0
          inet6 addr: 2001:yyyy:xxxx:2:290:ccff:fef4:9cb4/64 Scope:Global
          inet6 addr: fe80::290:ccff:fef4:9cb4/64 Scope:Link

Hoe werkt die DCHPv6 configuratie? Draai je zelf een DHCPv6 server, of is dat de DHCPv6 server van je provider? Hoe koppel je een adres dat binnenkomt via DHCPv6 over je wan interface aan een andere interface?

Het lijkt me niet echt nuttig om een publiek ip-adres toe te kennen aan je Local Loopback interface. Behalve die loopback interface kan je server ook benaderd worden over de globale IPv6 adressen van je lan en wlan interfaces.

[databeestje]

Eärendil schreef op woensdag 15 juni 2011 @ 12:04:
[...]


Hoe werkt die DCHPv6 configuratie? Draai je zelf een DHCPv6 server, of is dat de DHCPv6 server van je provider? Hoe koppel je een adres dat binnenkomt via DHCPv6 over je wan interface aan een andere interface?

Het lijkt me niet echt nuttig om een publiek ip-adres toe te kennen aan je Local Loopback interface. Behalve die loopback interface kan je server ook benaderd worden over de globale IPv6 adressen van je lan en wlan interfaces.

De WIDE dhcp6c client verzorgt automatisch de configuratie van de aangewezen interfaces met een correcte prefix. Je kan in de configuratie meestal ook nog sturen welk id van de aangeboden netwerken je aan een interface wil koppelen.

Daarna wordt er automatisch een RA daemon op de lan interface aangemikt en daardoor de router kenbaar gemaakt. Meestal wordt er dan ook nog een DHCPv6 Server gestart zodat de lan nodes ook DNS en NTP servers mee krijgen.

Wat betreft het kunnen bereiken van de lan zijde, het is juist routering. Dat is de bedoeling. Afhankelijk van jouw kastje zijn er wel of geen firewall rules voor het inkomende verkeer.

Sommige van de doosjes hebben een knop in de UI om al het verkeer door te laten. Of juist te blokkeren. Er is nog geen consensus.

[Sendy]

Eärendil schreef op woensdag 15 juni 2011 @ 12:04:
[...]

Hoe werkt die DCHPv6 configuratie? Draai je zelf een DHCPv6 server, of is dat de DHCPv6 server van je provider? Hoe koppel je een adres dat binnenkomt via DHCPv6 over je wan interface aan een andere interface?

Het lijkt me niet echt nuttig om een publiek ip-adres toe te kennen aan je Local Loopback interface. Behalve die loopback interface kan je server ook benaderd worden over de globale IPv6 adressen van je lan en wlan interfaces.

Dat laatste realiseer ik me. Maar ik weet niet echt of een firewall dat kan voorkomen. Dus dat ik met firewall die routing voorkomt toch het IPv6-adres van de lan-kant kan bereiken.

Op het moment doet DHCPv6 eigenlijk niets. (Het is dus een IPv6 DHCP client op mijn router.) Ik heb nu de router vaste IPs gegeven, en radvd deelt een prefix uit afgeleid uit die vaste IPs.

De router heeft nu dus een publiek IPv6-adres op de wan-, lan- en wifi-interfaces. Het publieke IPv6-adres van de loopback-interface heb ik verwijderd. Alles werkt nog, en ziet er goed uit, dus ik ben happy. (Maar nog wel wat vertwijfeld over die default configuratie van wide-dhcpv6.)

[ Voor 4% gewijzigd door Sendy op 15-06-2011 14:48 ]

[alm]

LauPro schreef op woensdag 15 juni 2011 @ 01:27:
Dat zou inderdaad een oplossing kunnen zijn, het klinkt mij echter nog wel als een workaround. Als men een efficient lookup systeem heeft dan zou makkelijk een vol /112 (65535 hosts) direct toegankelijk moeten zijn.

Uhh, het is bij IPv6 toch zo dat de minimale grootte van een IP-segment een /64 is? Anders zou automatische adressering niet werken (SLAAC). Met een /112 zou je dan alleen maar handmatig ip's kunnen toewijzen lijkt me omdat het kleiner is dan wat aan MAC-adressen mogelijk is (48 bits, maar daar komt nog wat bij voor automatische toekenning en dan kom je op 64 bits uit).
Dus als een /64 het minimum is voor een gewoon LAN, dan moet dat toch zeker geen probleem vormen.

[Verwijderd]

Goeiemiddag,

Ik doe momenteel een proef over ipv6 ,maar ik versta iets niet zo goed over unique local adressen
Die unique adressen zijn niet routeerbaar over het internet alleen maar intern zoals die link-local adressen,enz.. .
Wil dit zeggen dat het "overbodige" NAT hier terug aan te pas komt?
Wat ik hiermee bedoel is dat unique local adressen het equivalent zijn van de private adressen bij IPv4 ,dus die zouden ook een publiek adres nodig hebben om het internet te bereiken.

Dank U,

[CyBeR]

alm schreef op zondag 19 juni 2011 @ 10:50:
[...]


Uhh, het is bij IPv6 toch zo dat de minimale grootte van een IP-segment een /64 is? Anders zou automatische adressering niet werken (SLAAC). Met een /112 zou je dan alleen maar handmatig ip's kunnen toewijzen lijkt me omdat het kleiner is dan wat aan MAC-adressen mogelijk is (48 bits, maar daar komt nog wat bij voor automatische toekenning en dan kom je op 64 bits uit).
Dus als een /64 het minimum is voor een gewoon LAN, dan moet dat toch zeker geen probleem vormen.

Voor Stateless address autoconfiguration moet je subnet exact een /64 zijn. Maar als je SLAAC niet gebruikt maakt 't geen donder uit natuurlijk. Ik gebruik in m'n colo een /48 subnet, maar je kunt net zo lief een /126 gebruiken als dat handiger voor je is.

Verwijderd schreef op zondag 19 juni 2011 @ 17:53:
Goeiemiddag,

Ik doe momenteel een proef over ipv6 ,maar ik versta iets niet zo goed over unique local adressen
Die unique adressen zijn niet routeerbaar over het internet alleen maar intern zoals die link-local adressen,enz.. .
Wil dit zeggen dat het "overbodige" NAT hier terug aan te pas komt?
Wat ik hiermee bedoel is dat unique local adressen het equivalent zijn van de private adressen bij IPv4 ,dus die zouden ook een publiek adres nodig hebben om het internet te bereiken.

Dank U,

Nee, ULA's zijn bedoeld voor netwerken die niet bedoeld zijn om aan het internet te hangen. Bijvoorbeeld sensor netwerken en experimenten.

[ Voor 30% gewijzigd door CyBeR op 19-06-2011 18:00 ]

[Roetzen]

IPv6, Wij zijn er klaar voor!

www.vlist.org

[xares]

Nog meer mensen die een IPv6 tunnel gebruiken op hun DD-WRT router?
Ik krijg het niet helemaal aan de gang.

root@DD-WRT:~# ip -6 route
2001:470:xxx4:3b6::/64 via :: dev he-ipv6 metric 256 expires -5011sec mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:xxx5:3b6::/64 dev br0 metric 256 expires -4973sec mtu 1500 advmss 1440 hoplimit 4294967295
default dev he-ipv6 metric 1024 expires -4320sec mtu 1480 advmss 1420 hoplimit 4294967295
unreachable default dev lo proto none metric -1 error -128 hoplimit 255

IP-adres laptop: 2001:470:xxx5:3b6::5 GW: 2001:470:xxx5:3b6::1

Vanaf mijn laptop kan ik:

2001:470:xxx5:3b6::1 (gateway) kan ik pingen
2001:470:xxx4:3b6::2 (client ip) kan ik pingen

2001:470:xxx4:3b6::1 (server ip Tunnelbroker) kan ik _niet_ pingen
ipv6.google.com kan ik ook niet pingen

Ik denk dat het in de routing niet goed zit. Misschien dat iemand het ziet?

Ik ga nog even verder knutselen:)

[nasdude]

@Xares

heb je:
http://www.dd-wrt.com/wik...ne_Electric_Tunnel_Broker gevolgd?

en dan vooral dit stukje:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

# make sure to accept proto-41
iptables -I INPUT 2 -p ipv6 -i vlan1 -j ACCEPT

#make sure to not NAT proto-41
iptables -t nat -A POSTROUTING --proto ! 41 -o eth0 -j MASQUERADE

wel ff de juiste interfaces gebruiken he

[ Voor 5% gewijzigd door nasdude op 26-06-2011 12:51 ]

[xares]

Ik heb het al:)

Omdat mijn DD WRT router achter nog een andere router staat moet je ipv je public IP je WAN ip gebruiken.

Zoiets: ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 192.168.1.111 ttl 255

Nu alleen nog Radvd werkend krijgen. Hij geeft alleen een FE80 adres aan m'n laptop. Config komt van de DD WRT wiki.

[Whizzer]

Iemand een idee waarom van SixXS de nlede01 al een tijdje down is en dat ook nog steeds blijft? SixXS maakt de melding dat ze weten dat ie down is en dat daar geen contact met zo over gezocht hoeft te worden... "Het probleem zal vanzelf in de tijd worden opgelost..."

Is ook meteen mijn grootste frustratie bij SixXS. Kwalitatief doen ze het best goed, maar communicatief... Is je eigen tunnel down, dan krijg je daar meteen "strafpunten" voor en na 5 dagen disablen ze hem omdat ze van je verwachten er goed en serieus mee om te gaan.. Echter andersom moet ik maar zien of en wanneer het weer op komt (om nog maar te zwijgen of we te horen krijg waardoor de storing is ontstaan)..

[CyBeR]

Whizzer schreef op zondag 26 juni 2011 @ 21:08:
Iemand een idee waarom van SixXS de nlede01 al een tijdje down is en dat ook nog steeds blijft? SixXS maakt de melding dat ze weten dat ie down is en dat daar geen contact met zo over gezocht hoeft te worden... "Het probleem zal vanzelf in de tijd worden opgelost..."

Haha, zo ongeveer terwijl jij dat postte kwam 'ie precies weer online

Interessant is dat ik nog geen mailtje heb gehad over dat m'n tunnel down was. Mischien heeft mijn klacht vorige keer toch geholpen

edit: bah hij's weer dood

[ Voor 15% gewijzigd door CyBeR op 26-06-2011 21:22 ]

[_Arno_]

CyBeR schreef op zondag 26 juni 2011 @ 21:13:
[...]


edit: bah hij's weer dood

Bij mij staat hij weer op 'enabled', houd het hele weekend de site al in de gaten... duurde wel erg lang voordat die weer online was....

[CyBeR]

_Arno_ schreef op zondag 26 juni 2011 @ 21:27:
[...]


Bij mij staat hij weer op 'enabled', houd het hele weekend de site al in de gaten... duurde wel erg lang voordat die weer online was....

Ze zijn er nog even mee aan 't kutten denk ik. Hij 's nu net weer online gekomen.

[_Arno_]

CyBeR schreef op zondag 26 juni 2011 @ 21:31:
[...]


Ze zijn er nog even mee aan 't kutten denk ik. Hij 's nu net weer online gekomen.

mmh, zou dat het verklaren dat ik 't niet aan de praat krijg....

heb mijn Vigor 2130Vn voorzien van de laatste firmware, hier zit een AICCU client in, hier heb ik (volgens mij) de juiste gegevens in gevoerd.... als ik het goed heb begrepen heb ik ook een subnet nodig, deze dus aangevraagd en geconfigureerd via RADVD

mijn laptop krijgt van RADVD een IPv6 adres, ik kan het IPv6 adres van mijn router pingen en kan ook mijn kant van de AYIYA tunnel pingen, maar ik kan niet de andere kant van de tunnel pingen....

iemand enig idee waar dit in kan zitten?

edit:
in de syslog van de 2130Vn kom ik dit tegen: syslog: Succesfully retrieved tunnel information for T57869

lijkt mij dus dat de tunnel wel opgebouwd word....?

edit 2: de tunnel en RADVD doen het inmiddels, het had blijkbaar te maken met de storing bij BIT....

[ Voor 15% gewijzigd door _Arno_ op 28-06-2011 09:02 ]

[xares]

Hoe ziet je RadVD config eruit?
Krijg die van mij niet werkend met m'n /48

[Snow_King]

CyBeR schreef op zondag 26 juni 2011 @ 21:31:
[...]


Ze zijn er nog even mee aan 't kutten denk ik. Hij 's nu net weer online gekomen.

Bij mij is ie weer down? Ik baalde er ook al flink van... Heel vervelend om je IPv6 weer uit te moeten zetten, anders heb je van die mega timeouts overal.

[CyBeR]

Snow_King schreef op maandag 27 juni 2011 @ 11:32:
[...]
Bij mij is ie weer down? Ik baalde er ook al flink van... Heel vervelend om je IPv6 weer uit te moeten zetten, anders heb je van die mega timeouts overal.

Yep, hier ook. Zelf geen last van timeouts overigens. OSX doet iets goed wat dat betreft tegenwoordig.

[Zsub]

Er zat in de 10.6.8 schijnbaar een IPv6 gerelateerde fix, geen idee wat die was, though.

[CyBeR]

Schijnbaar heeft frim er naar gekeken. Dit is wat Lion (10.7) doet, dunno vwb 10.6.8:

11:53 <frim> CyBeRino: ja, moet je maar eens een tcpdump doen
11:53 <CyBeRino> frim: stel dat ik daar geen tijd voor heb?
11:53 <frim> CyBeRino: hij maakt parallel tcp connetions over 4 en 6
11:53 <frim> CyBeRino: en reset dan de connectie die het traagst is

[_Arno_]

xares schreef op maandag 27 juni 2011 @ 10:23:
Hoe ziet je RadVD config eruit?
Krijg die van mij niet werkend met m'n /48

Ik heb gewoon de gegevens ingevuld in de web interface van mijn router. Als IPv6 adres heb ik het eerste IP adres uit mijn subnet opgegeven. Vervolgens heb ik RADVD ge-enabled en het werkte.

Wat ik overigens wel vreemd vind is dat ik in mijn 2130Vn alleen maar een /64 adres kan opgeven, maar volgens mij kan dit geen probleem zijn gezien deze binnen het /48 subnet valt die ik van Sixxs heb gekregen. Of zie ik dit verkeerd?

[Roetzen]

CyBeR schreef op zondag 26 juni 2011 @ 21:31:
[...]
Ze zijn er nog even mee aan 't kutten denk ik. Hij 's nu net weer online gekomen.

Zeiden ze. Maar er waren de nodige mensen (waaronder ik) die rapporteerden dat het toch niet werkte. Pas later in de middag vandaag werkte ineens alles weer.

[rant]
En Zijne Arrogantie Jeroen Massar maar weer zitten te katten als ik in het forum meldt dat er mogelijk een probleem is. Moet maar een ticket maken zegt ie dan. Goed, iemand is me voor, maar ik vul het nog aan met (naar mijns inziens) relevante informatie. En die wordt dan vervolgens weg gehaald. Sja ik weet dat het allemaal vrijwilligerswerk is, maar ik heb het nu wel even gehad met die arrogante club. Als er weer eens iets is, ga ik dus echt niet meer moeite doen om relevante gegevens te verzamelen die mogelijk kunnen helpen het probleem op te lossen. Ze zoeken het voortaan zelf maar uit. [/rant]

Mijn he.net tunneltje loopt overigens als een zonnetje.

[Snow_King]

Eens, ik kan dat bij SixXS ook allemaal érg slecht hebben. Hier werkt mijn tunnel inmiddels weer, maar de SixXS website heeft ook een tijdje UP aangegeven terwijl de tunnel toch aardig DOWN was.

Hopelijk komt er snel native IPv6 hierzo (ZeelandNet), maar dat zal wel niet...

[Paul Guijt]

Tsjonge, dat stelde echt niets voor.

Had bij Xs4All in het Service Center al een IPv6 nummer aangevraagd. Heb het nieuwe Fritz 7340 geïnstalleerd (migratie van mijn WLAN was het meeste werk). En passant even firmware geüpdate.

Heb net in Fritz IPv6 aangezet, uiteraard zonder handleiding te lezen. Hop, IPv6 connected. Kijk bij mijn Win 7 adapter, zie dat die ook IPv6 met internet laat babbelen.

Kind kan dus de was doen. Jammer dat ik geen kind heb. Nu het grote IPv6 Internet op ;-)

[Roetzen]

Paul Guijt schreef op maandag 27 juni 2011 @ 19:10:
Nu het grote IPv6 Internet op ;-)

Vooralsnog valt het met dat grote IPv6 Inetrnet een beetje tegen. Ik heb nu bijna een jaar IPv6 toegang, maar ik kan niet echt zeggen dat er een nieuwe wereld voor mij is open gegaan. Technisch was het een leuke uitdaging om het allemaal aan de praat te krijgen, maar daar is het dan ook bij gebleven. Er is nog niets waarvan ik zeg: "gôh,dat had ik veel eerder moeten hebben".

Er is nog maar weing content beschikbaar via IPv6 en dat wat beschikbaar is, werkt soms minder dan via IPv4. Sowieso is de snelheid een stuk lager. In het beste geval haal ik via IPv6 maar 40% van de snelheid via IPv4 en soms is het maar 20% . Nu zit ik daar niet echt mee, ik ben niet zo'n snelheidsmaniak, maar het valt toch wel op en ik vraag me eigenlijk af waardoor het komt. Hebben degenen die native IPv6 hebben het ook? Ik zit voorlopig - net als de meeste Nederlanders denk ik -nog wel even vast aan een tunnel. Mijn provider - Ziggo - maakt niet zichtbaar haast met IPv6.

Ik heb deze twee IPv6 speedtetst gevonden: http://ipv6-test.com/speedtest/ en http://ipv6-speedtest.net/

Uiteraard heeft een tunnel wat overhead. Maar 60% voor een static 6in4 tunnel? Aan het tunneleindpunt kan het toch ook niet liggen. Mijn SixXs tunnel start bij Bit in Ede en mijn h.net tunnel in Amsterdam. Beide maar één glasvezeltje van AMS-IX vandaan...

[elsinga]

Mijn 6to4 autoconfig'd tunneltje doet maar 10% langzamer...

[Zsub]

elsinga schreef op dinsdag 28 juni 2011 @ 12:09:
Mijn 6to4 autoconfig'd tunneltje doet maar 10% langzamer...

Dan heb je verschrikkelijk veel mazzel. 6to4 is over het algemeen drama tot en met.

Ik ben op kantoor aan het voorbereiden om wat v6 dingen te implementeren. Zou graag willen dat VPN clients ook een v6 uit de /48 van kantoor krijgen en nog wat kleine dingetjes. Wordt nog een heel gevecht, yay mac servers

[elsinga]

Ik heb zeker mazzel, zeker omdat dit vanaf een Ziggo aansluiting is. Ziggo doet nog niks aan ipv6, mijn 6to4 komt daardoor uit bij Sara (meen ik).

[Roetzen]

Welke test heb je gebruikt om tot die 10% conclusie te komen?

[Eärendil]

Bij http://ipv6-test.com/speedtest/ is mijn ipv6 4% langzamer dan ipv4.
Ik heb 25 Mbit/s glasvezel van Concepts ICT en een 6in4-tunnel van Sixxs, met de Concepts ICT PoP

[elsinga]

Roetzen schreef op dinsdag 28 juni 2011 @ 18:16:
Welke test heb je gebruikt om tot die 10% conclusie te komen?

http://ipv6-test.com/speedtest/ , maar het lijkt erg tijdsafhankelijk, nu zit ik op 60% minder... En twee minuten later dit:

[_Arno_]

doe ik iets niet goed?

of heeft dit met mijn POP te maken?

heb een Ziggo 120Mbit lijn (test is via wlan), heb een AYIYA tunnel van Sixxs, POP is van BIT....

[Roetzen]

Ik schijn iets te missen. Ik zie dat plaatje helemaal niet. De Ipv4 test faalt 9 van de 10 keer en ik zie de resultaten alleen in tekst, niet als png.

Vreemd.

Win XP professional, IE8.
WRT54GL met dd-wrt
SixXs AYIYA tunnel.
Ziggo.

[_Arno_]

Roetzen schreef op dinsdag 28 juni 2011 @ 21:44:
Ik schijn iets te missen. Ik zie dat plaatje helemaal niet. De Ipv4 test faalt 9 van de 10 keer en ik zie de resultaten alleen in tekst, niet als png.

Vreemd.

Win XP professional, IE8.
WRT54GL met dd-wrt
SixXs AYIYA tunnel.
Ziggo.

bij mij deedt die het ook niet in IE, met Firefox ging het wel goed

[Verwijderd]

Als speedtest is die site niet heel betrouwbaar

[Roetzen]

_Arno_ schreef op dinsdag 28 juni 2011 @ 21:46:
bij mij deedt die het ook niet in IE, met Firefox ging het wel goed

Hmmm... Dat is toch wel een minpuntje...

Anyway, dit is wat ik kirjg:

code:

IPv4
 Ziggo-cm
83.82.233.201
9.79 Mbit/s
1.22 Mbytes/s
IPv6
 Bit
2001:7b8:2ff:3a9::2
2.12 Mbit/s
272 Kbytes/s

[CyBeR]

Wat je hier meet is de snelheid van je tunnelbroker 's tunnelserver.

[_Arno_]

CyBeR schreef op woensdag 29 juni 2011 @ 03:24:
Wat je hier meet is de snelheid van je tunnelbroker 's tunnelserver.

ja dat begrijp ik het blijkt dus dat de verschillende tunnelbrokers behoorlijk verschillen qua bandbreedte

[xares]

Bij meer mensen hun Tunnelbroker IPV6-tunnel offline?
Sinds vanmiddag werkt het niet meer.

[Verwijderd]

xares schreef op woensdag 29 juni 2011 @ 21:43:
Bij meer mensen hun Tunnelbroker IPV6-tunnel offline?
Sinds vanmiddag werkt het niet meer.

Dacht dat het aan mij lag (had namelijk ook mijn router een update gegeven ). Via AMS geen verbinding.

[Keiichi]

xares schreef op woensdag 29 juni 2011 @ 21:43:
Bij meer mensen hun Tunnelbroker IPV6-tunnel offline?
Sinds vanmiddag werkt het niet meer.

Het lijkt er op dat mijn he.net tunnelbroker tunnel ook niet werkt.

[xares]

Ik merkte het omdat een aantal sites die ik dagelijks (naja elk half uur) bezoek traag waren.
Hij probeerd eerst via IPv6 en dan pas via IPv4, duurt dus ff.

[Keiichi]

Op de site staat dat de AMS server down is.

Ik moet ipv6 compleet uitschakelen, omdat ik anders amper kan internetten meer

[ijdod]

Via HE was het al een dag instabiel qua snelheid... maar dat leek vanmiddag weer gefixed. twee tellen nadat ik dat getest had viel eea helemaal uit... maar ik heb dus een uur zitten knoeien met mijn desktop omdat IPv6 raar deed (want op de server/router werkte het). Duh.

(Dit is vaak ook het punt dat je uiteindelijk toch de helldesk belt, en gevraagd wordt of je eea al gereboot hebt )

[ Voor 5% gewijzigd door ijdod op 29-06-2011 22:24 ]

[anboni]

Native IPv6 via XS4all:



Ik denk dat de server waar tegenaan getest wordt geen al te beste performance biedt, news downloads (over IPv4) halen gewoon de volle snelheid (20mbit)

[Roetzen]

Keiichi schreef op woensdag 29 juni 2011 @ 22:14:
Op de site staat dat de AMS server down is.

Volgens de site is ie zojuist weer on-line gekomen, maar mijn tunnel doet het nog niet...

[boonie]

"Gehoord" op IRC: AMS is nog plat. Verkeer gaat nu over parijs. Nikhef heeft blijkbaar alleen support tijdens kantooruren.

[Verwijderd]

boonie schreef op donderdag 30 juni 2011 @ 08:10:
"Gehoord" op IRC: AMS is nog plat. Verkeer gaat nu over parijs. Nikhef heeft blijkbaar alleen support tijdens kantooruren.

Tracert laat idd een Parijs zien. Maar belangrijkste is toch dat het werkt

[Keiichi]

Verwijderd schreef op donderdag 30 juni 2011 @ 08:15:
[...]

Tracert laat idd een Parijs zien. Maar belangrijkste is toch dat het werkt

Ze doen het dan wel beter dan sixxs in zo'n geval maar over hun is al genoeg discussierd volgens mij.

[Whizzer]

Roetzen schreef op maandag 27 juni 2011 @ 17:49:
[rant]
En Zijne Arrogantie Jeroen Massar maar weer zitten te katten als ik in het forum meldt dat er mogelijk een probleem is. Moet maar een ticket maken zegt ie dan. Goed, iemand is me voor, maar ik vul het nog aan met (naar mijns inziens) relevante informatie. En die wordt dan vervolgens weg gehaald. Sja ik weet dat het allemaal vrijwilligerswerk is, maar ik heb het nu wel even gehad met die arrogante club. Als er weer eens iets is, ga ik dus echt niet meer moeite doen om relevante gegevens te verzamelen die mogelijk kunnen helpen het probleem op te lossen. Ze zoeken het voortaan zelf maar uit. [/rant]

Mijn he.net tunneltje loopt overigens als een zonnetje.

Yep.. Dat soort dingen zorgen ervoor dat ik hier maar de vragen stel i.p.v. bij SixXS. Welke vraag je ook stelt, het lijkt wel of dat het teveel moeite voor ze kost om er aktie op te ondernemen, of ieder ander dan Jeroen en Pim nog te dom zijn om zelfstandig naar de wc te gaan...

Maargoed, hij werkt weer, toch wel handig... Ik had de bedoeling al ondervangen met policy based routing aangezien er op dezelfde doos ook een HE tunnel zit..

[Skinkie]

Whizzer schreef op vrijdag 01 juli 2011 @ 17:49:
Yep.. Dat soort dingen zorgen ervoor dat ik hier maar de vragen stel i.p.v. bij SixXS. Welke vraag je ook stelt, het lijkt wel of dat het teveel moeite voor ze kost om er aktie op te ondernemen, of ieder ander dan Jeroen en Pim nog te dom zijn om zelfstandig naar de wc te gaan...

Inderdaad. Vervolgens kregen ze een policy dat je e-mail adres moest werken, maar je e-mail adres veranderen moest je voor mailen. (Wordt gewoon 3 maanden niet op gereageerd.) En resulteerde er in dat al je tunnels werden uitgezet. Een nieuw account aanmaken zorgde voor een volledige ban, omdat je maar 1 account per persoon mag hebben.

Maargoed, hij werkt weer, toch wel handig... Ik had de bedoeling al ondervangen met policy based routing aangezien er op dezelfde doos ook een HE tunnel zit..

Ben naar HE gegaan daarna. Maar ook daar heb ik 'problemen' gevonden, al willen die daar wel meedenken.

[AndriesLouw]

Zojuist even heel snel met behulp van een speciale Tomato firmware en SixXS de IPv6 capaciteit van mijn WRT54GL getest:



Het subnet routen gaat goed, alleen de DNS servers doorgeven aan clients gaat wat minder, zo lijkt. Ook duurt het best lang voordat een Windows 7 client doorheeft dat de router IPv6 adressen beschikbaar stelt.

Overhead in latency is hier ongeveer 4/5 ms, dat valt reuze mee voor een tunnel, maar ik zou graag zien dat Ziggo gewoon zelf IPv6 verzorgen ging..

[ Voor 3% gewijzigd door AndriesLouw op 03-07-2011 23:29 . Reden: Nieuwe speedtest gedaan ]

[Sorki]

Geen snelheidswonder maar snelheidsverschil goed mee

[Raven]

'Videovergaderen wordt slachtoffer IPv4-tekort'

Videoconferencing zal één van de eerste applicaties zijn die concreet hinder gaat ondervinden van het IPv4-tekort. Dat voorspelt ip-onderzoeker Iljitsch van Beijnum. 'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio en videogesprekken niet tot stand kunnen komen.'

'Stel dat een ISP geen IPv4-adressen heeft, maar wel nieuwe klanten krijgt', legt Van Beijnum uit, 'dan gaat hij die klanten via NAT444 samen achter één IPv4-adres plaatsen.' Hoe intensiever providers gebruik zullen maken van NAT, hoe trager p2p-applicaties zullen worden, voorspelt Van Beijnum.

Videoconferencing-applicaties zullen daar het eerst hinder van ondervinden, aldus de onderzoeker: 'Bij p2p-applicaties die relatief weinig dataverkeer gebruiken, zoals bijvoorbeeld instant messaging en VoIP, is het mogelijk het verkeer via een server te laten lopen, maar vanwege de grotere bandbreedte van video is dat in dit geval een minder bruikbare oplossing.'
P2p-applicaties krijgen het zwaar

'NAT in het algemeen dwingt internetverkeer af dat verloopt volgens een client-serverarchitectuur', zegt Van Beijnum. En die architectuur vloekt met programma's die ip-pakketten versturen via een peer-to-peer (p2p)-netwerk. Zo'n p2p-netwerk is gedecentraliseerd: het kent geen vaste werkstations en servers zoals in het client-servermodel, maar enkel gelijkwaardige aansluitingen ('peers' ). Ze functioneren allemaal zowel als client en als server voor de andere aansluitingen in het netwerk.

'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio- en videogesprekken niet tot stand kunnen komen', legt Van Beijnum uit. De internetonderzoeker weet dit ook uit eigen ervaring: 'Thuis heb ik twee BitTorrent-machines staan. De één staat achter een NAT-box, de ander niet. Met die laatste laptop, die een eigen ip-adres heeft, kan ik vier tot tien keer sneller bestanden downloaden.'

Iljitsch van Beijnum
Iljitsch van Beijnum is onderzoeker aan de Madrileense UC3M-universiteit en het overheidsonderzoeksinstituut IMDEA Networks. Hij ontwikkelt daar onder meer nieuwe ip-technologie, voor het gefragmenteerd en daardoor efficiënter versturen van ip-pakketten over verschillende paden tegelijk. In zijn huidige functie droeg hij bij aan de ontwikkeling van NAT64. Dat is een mechanisme om IPv6-clients te laten verbinden met IPv4-servers. Hij schrijft met regelmaat artikelen over netwerkarchitectuur en internettechnologie op online medium Ars Technica. Hij is lid van de Nederlandse TaskForce IPv6.

Van Beijnum publiceerde in 2005 een handboek over het gebruik van IPv6: 'Running IPv6'. In 2002 schreef hij een BGP-handleiding: 'Building Reliable Networks With the Border Gateway Protocol'. In 2005 rondde hij een informatica-opleiding af aan de Haagse Hoogeschool. Van Beijnum was stagiair bij XS4All in 1995, werkte bij bART van 1995 tot 1997 en begon in 1997 met vier anderen voor zichzelf als Pine Internet, tegenwoordig Pine Digital Security. Tussen 2000 en 2007 was hij zelfstandig consultant.

[Raven]

'IPv4-tekort vertraagt internet over twee jaar'

NAT is geen oplossing voor het IPv4-tekort. Dat zegt IP-onderzoeker Iljitsch van Beijnum. 'Problemen zullen waarschijnlijk niet meteen optreden, maar over twee, drie jaar kan de situatie opeens onhoudbaar blijken.' Volgens de IP-onderzoeker zal videoconferencing één van de eerste applicaties zijn die concreet hinder gaat ondervinden van het IPv4-tekort.

NAT is geen oplossing voor het IPv4-tekort, stelt Van Beijnum. 'Wanneer providers hun klanten via NAT444 samen achter één IPv4-adres plaatsen, zullen die klanten de beschikbare TCP/IP-poorten van één IPv4-adres met elkaar moeten delen.'

'Stel, een provider plaatst honderd klanten achter één adres. Dat betekent dat voor elk van die klanten gemiddeld 650 van de 65000 TCP/IP-poorten beschikbaar zijn.'

Het probleem daarmee is volgens Van Beijnum dat webdiensten steeds meer poorten tegelijk in beslag nemen. 'Eén gebruiker van Google Maps soupeert zo'n tweehonderd poorten tegelijk op. En bestandsdeel-programma BitTorrent gebruikt ook al snel vierhonderd poorten.'

Videoconferencing zal één van de eerste applicaties zijn die concreet hinder gaat ondervinden van het IPv4-tekort', aldus de IP-onderzoeker. 'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio en videogesprekken niet tot stand kunnen komen.'

Kikker in kookpot
'Eind 2011 heeft RIPE NCC in onze regio naar verwachting geen IPv4-adressen meer te verdelen', vertelt Van Beijnum. 'Providers zullen noodgedwongen vaker verschillende nieuwe gebruikers achter één IPv4-adres plaatsen via NAT444. Maar dat is niet oneindig lang vol te houden. Problemen zullen waarschijnlijk niet meteen optreden, maar over twee, drie jaar kan de situatie opeens onhoudbaar blijken. Je kunt het vergelijken met een kikker in een kookpot. Als je die meteen in het kokend water gooit, springt hij eruit. Maar als je hem in koud water zet, en dan langzaam opwarmt, komt hij nooit op het idee om uit de kookpot te springen.'

'Het probleem is dat de overgang naar IPv6 het IPv4-tekort niet op korte termijn oplost', aldus Van Beijum. 'Een provider kan niet zeggen: ik heb geen IPv4-adressen meer, dus krijgt u van mij een IPv6-adres. Want zo'n klant kan dan 99 procent van het internet niet bereiken. Dat accepteert hij niet. Daarom geeft een provider een klant liever een trage, gedeelde IPv4-verbinding met maar drie TCP/IP-poorten, dan een snelle IPv6-verbinding. Dat is het trieste van het hele verhaal.'

Iljitsch van Beijnum
Iljitsch van Beijnum is onderzoeker aan de Madrileense UC3M-universiteit en het overheidsonderzoeksinstituut IMDEA Networks. Hij ontwikkelt daar onder meer nieuwe IP-technologie, voor het gefragmenteerd en daardoor efficiënter versturen van IP-pakketten over verschillende paden tegelijk. In zijn huidige functie droeg hij bij aan de ontwikkeling van NAT64. Dat is een mechanisme om IPv6-clients te laten verbinden met IPv4-servers. Hij schrijft met regelmaat artikelen over netwerkarchitectuur en internettechnologie op online medium Ars Technica. Hij is lid van de Nederlandse TaskForce IPv6.

Van Beijnum publiceerde in 2005 een handboek over het gebruik van IPv6: 'Running IPv6'. In 2002 schreef hij een BGP-handleiding: 'Building Reliable Networks With the Border Gateway Protocol'. In 2005 rondde hij een informatica-opleiding af aan de Haagse Hoogeschool. Van Beijnum was stagiair bij XS4all in 1995, werkte bij bART van 1995 tot 1997 en begon in 1997 met vier anderen voor zichzelf als Pine Internet, tegenwoordig Pine Digital Security. Tussen 2000 en 2007 was hij zelfstandig consultant.

[Roetzen]

Vijf misverstanden over IPv6

IP-onderzoeker Iljitsch van Beijnum weerlegt vijf misverstanden die er volgens hem bestaan over IPv6. 'Met een NAT-box kun je eenvoudig een aantal clients tegelijk achter één IPv4-adres plaatsen. Dat lijkt aantrekkelijk, maar in de praktijk blijkt die ene aanpassing toch altijd een volgende uit te lokken, en een volgende. Dat resulteert uiteindelijk in zoveel aanpassingen dat de overgang naar IPv6 eenvoudiger is.'


Read more: http://www.computable.nl/...r-ipv6.html#ixzz1RsNrNlA6

[Osiris]

Niet geheel correct artikel als je 't mij vraagt. Dat verhaaltje over 'temporary addresses' gaat over IPv6 Privacy Extension (waardoor je dus bij SLAAC geen MAC-adres gebruikt), terwijl het stukje eronder zegt dat 'tijdelijke adressen' geen privacy-bescherming geeft (wat dus hetzelfde is als de bovenstaande 'temporart addresses' lijkt me?), omdat ze wél gebruik maken van MAC-adressen. Dat is dus enigszins in tegenspraak. In feite klopt 't wel wat ze bedóelen, maar wordt 't ongelukkig geschreven.

Ze hadden het beter andersom kunnen zeggen: "SLAAC is handig, want geen DHCP-server, maar privacy-beperking, maar gelukkig is er de Privacy Extension, die daar wel weer voor zorgt." Beetje jammer nu.

Mgoed, die Van Beijnum heeft ook eens een interviewtje gedaan hoor en opeens staat de media er vol mee..

[ Voor 23% gewijzigd door Osiris op 12-07-2011 16:38 ]

[Roetzen]

Osiris schreef op dinsdag 12 juli 2011 @ 16:36:
Niet geheel correct artikel als je 't mij vraagt. Dat verhaaltje over 'temporary addresses' gaat over IPv6 Privacy Extension (waardoor je dus bij SLAAC geen MAC-adres gebruikt), terwijl het stukje eronder zegt dat 'tijdelijke adressen' geen privacy-bescherming geeft (wat dus hetzelfde is als de bovenstaande 'temporart addresses' lijkt me?), omdat ze wél gebruik maken van MAC-adressen. Dat is dus enigszins in tegenspraak. In feite klopt 't wel wat ze bedóelen, maar wordt 't ongelukkig geschreven.

Dat was mij ook opgevallen

Mgoed, die Van Beijnum heeft ook eens een interviewtje gedaan hoor en opeens staat de media er vol mee..

ljitsch is niet de eerste de beste. Ik ken hem al wat langer dan vandaag, een jaartje of twintig, en ik weet dat als het over IPv6 gaat, hij weet waarover hij het heeft. Ik vermoed dat de interviewer het verkeerd heeft weergegeven. ljitsch maakt zo'n fout niet.

[Osiris]

Nee OK, dat geloof ik ook wel, maar d'r staat nu opeens in de diverse media tig keer van hetzelfde..

Overigens ben ik allang blij dat 'ie anti-NAT is

[Verwijderd]

Ok, sinds mijn laatste post van een paar weken terug heb ik een tweede range aangevraagd voor het interne netwerk hier.
Alles werkt nu wel naar behoren met het volgende resultaat:


En dat voor een test naar frankrijk over een 100 mbit lijn

[ Voor 9% gewijzigd door Verwijderd op 14-07-2011 10:52 ]

[CyBeR]

Roetzen schreef op donderdag 14 juli 2011 @ 01:34:
[...]


Dat was mij ook opgevallen


[...]

ljitsch is niet de eerste de beste. Ik ken hem al wat langer dan vandaag, een jaartje of twintig, en ik weet dat als het over IPv6 gaat, hij weet waarover hij het heeft. Ik vermoed dat de interviewer het verkeerd heeft weergegeven. ljitsch maakt zo'n fout niet.

Of jullie lezen het verkeerd. Er staat dat SLAAC-adressen het MAC-adres erin hebben, dat dat het privacyprobleem is en dat dat probleem opgelost wordt met temporary adressen. Dat klopt gewoon voor 100%.

[ Voor 5% gewijzigd door CyBeR op 14-07-2011 11:57 ]

[Osiris]

CyBeR schreef op donderdag 14 juli 2011 @ 11:56:
[...]


Of jullie lezen het verkeerd. Er staat dat SLAAC-adressen het MAC-adres erin hebben, dat dat het privacyprobleem is en dat dat probleem opgelost wordt met temporary adressen. Dat klopt gewoon voor 100%.

Jammer dat ik de tekst niet gequote heb (lui ), want ik gok dat ze het artikel ietswat aangepast hebben. Zoals het er nu staat is het inderdaad juist.

[webfreakz.nl]

Had iemand deze al gezien?

http://tools.ietf.org/html/rfc6296

[CyBeR]

Osiris schreef op donderdag 14 juli 2011 @ 12:04:
[...]

Jammer dat ik de tekst niet gequote heb (lui ), want ik gok dat ze het artikel ietswat aangepast hebben. Zoals het er nu staat is het inderdaad juist.

Ah, dat kan ook ja

[eymey]

Ik ben een aantal weken op vakantie geweest en heb alleen deze pagina in het topic bij-gelezen, maar begrijp ik goed dat er problemen lijken te zijn met de Amsterdam POP van SixXS ?

Ik kan al een dag of 2 nauwelijks op de website van KNMI.nl en nog wat andere sites. Ook sites als test-ipv6.com of .nl werken extreem traag. Het lijkt er dus op dat ik nauwelijks throughput heb via m'n IPV6 tunnel.

Nou heb ik begin van de week ook m'n Fritz!box van nieuwe (labor) firmware voorzien maar goed, de tunnel is er wel. Het andere endpoint bij sixxs reageert echter meer niet dan wel.

[ Voor 5% gewijzigd door eymey op 14-07-2011 22:45 ]

[Roetzen]

Ik weet niets over Amsterdam, maar het PoP in Ede ligt er sinds vanmiddag uit:

There are currently known problems with : nlede01. We are aware of this and one does not need to contact us nor report anything about this. The problems will be resolved in due time, please have patience. A separate PoP status page displays the status of the various PoPs. One can consult the Tickets for other outstanding issues.

[_Arno_]

Roetzen schreef op zaterdag 16 juli 2011 @ 21:04:
Ik weet niets over Amsterdam, maar het PoP in Ede ligt er sinds vanmiddag uit:


[...]

helaas nog steeds... paar weken geleden ook al een dag of 3

[Whizzer]

de nlede01 doet het sinds een klein uurtje weer als het goed is... Wederom dezelfde communicatie als altijd "ja, is bekend, komt vanzelf een keer goed". Misschien moet ik die tekst ook maar eens terugsturen als mijn tunnel toevallig een dagje plat is en ik daar bericht over krijg..

Hij is de laatste tijd wel vaker onstabiel en ook voor langere tijd..

[Roetzen]

Hij doet het nog steeds niet. Volgens de website is ie weer UP, maar ik kan nog steeds geen IPv6 verbinding maken via mijn SixXs tunnel.

Ik ga niet eens meer de moeite nemen het te rapporteren. Ik heb geen zin in weer een koude douche.

Gelukkig heb ik ook nog een he.net tunnel. Die draait als een zonnetje.

[Raven]

Waarom heb je er 2 dan? Heeft dat nut?
Behalve dan in zo'n situatie als dit waarbij de een niet werkt de ander gebruikt kan worden bedoel ik dan.

[ Voor 56% gewijzigd door Raven op 19-07-2011 13:44 ]

[Osiris]

Ik heb drie tunnels bij SixXS, juist om die reden dat ze vroggâh nog wel eens uitvielen

[Zsub]

Raven schreef op dinsdag 19 juli 2011 @ 13:44:
Waarom heb je er 2 dan? Heeft dat nut?
Behalve dan in zo'n situatie als dit waarbij de een niet werkt de ander gebruikt kan worden bedoel ik dan.

Loadbalancing over die drie tunnels? Serieus, trouwens, met alle mensen die hier posten dat hun tunnel niet hun volledige internetsnelheid aankan, ik zie wel hoe dat zou kunnen werken

[Whizzer]

Osiris schreef op dinsdag 19 juli 2011 @ 13:47:
Ik heb drie tunnels bij SixXS, juist om die reden dat ze vroggâh nog wel eens uitvielen

Jij ook al... (plus 2 bij HE)

Leer je in ieder geval ook hoe source routing of policy based routing gedaan moet worden op linux en Cisco.. ;-)

En hoezo "vroggâh"??

[Osiris]

Sinds m'n tunnel bij XS4ALL gebruik ik SixXS niet meer. Ze staan alleen ISK's te scoren

En inderdaad, source-based routing was toen opeens wel noodzakelijk. Heb nog een mailtje gekregen over 't feit dat ze transit-verkeer van andere IP-ranges over 't tunneltje niet tof vonden haha

[Raven]

Zsub schreef op dinsdag 19 juli 2011 @ 14:06:
[...]


Loadbalancing over die drie tunnels? Serieus, trouwens, met alle mensen die hier posten dat hun tunnel niet hun volledige internetsnelheid aankan, ik zie wel hoe dat zou kunnen werken

Ah okay. Geen idee of pfSense (gebruik ik icm HE) dat kan....
Maar ben op zoek naar een ander OS daar pfSense/FreeBSD geen ondersteuning bied voor "N".

[Roetzen]

Raven schreef op dinsdag 19 juli 2011 @ 13:44:
Waarom heb je er 2 dan? Heeft dat nut?
Behalve dan in zo'n situatie als dit waarbij de een niet werkt de ander gebruikt kan worden bedoel ik dan.

Ik ben begonnen met een AYIYA tunnel bij SixXs. Het plan was de machine waarop die eindigt als router voor het subnet te gebruiken, zodat andere machines in het LAN ook IPv6 zouden hebben. De machine waarop de tunnel eindigt zou toch 24/7 aan staan omdat daar ook mijn http server op zou gaan draaien.

Maar toen bleek dat Windows en AYIYA én een tunnel delen niet gaat. De procedure zoals bescheven in de FAQ van SIxXs werkt gewoon niet.Toen ik dat meldde kreeg ik van Jeroen doodleuk te horen dat dat bekend was en dat het staat onder de sectie "known problems". Sja...

Dus toen heb ik het over een andere boeg gegooid.

Ik heb een oude linksys van zolder gehaald en daar een versie van DD-WRT op geflashed die IPv6 ondersteunt. En ik heb bij he.net een tunnel aangevraagd. Niks geen gezeur met punten en zo. En dat werkt wel zoals het bedoeld is.

Ik heb die SixXs tunnel dus eigenlijk niet meer nodig. Maar ja, weggooien van een tunnel kost 25 punten plus nog 50 punten voor het bijbehorende subnet, dus houd ik hem maar.

Edit 17:15: Inmiddels werkt de SixXs tunnel weer.

[ Voor 15% gewijzigd door Roetzen op 19-07-2011 17:20 ]

[databeestje]

In pfSense IPv6 code boom zit NPT ondersteuning. Dit is IPv6 NAT waarmee je 1:1 netblokken "vertaald".

Op deze manier kan je dus meerder IPv6 tunnels of native tegelijk gebruiken. Op het werk heb ik dit ook getest met 3 verschillende IPv6 prefixes. Dit is vergelijkbaar met de multi wan zoals we dat kennen in IPv4 land met als groot verschil dat de IPv6 machine die erachter zit op alle 3 de netwerken ook daadwerkelijk bereikbaar is.

Inmiddels is mijn IPv6 code boom in de pfSense master boom teruggevouwen waardoor dit automatisch onderdeel wordt van versie 2.1.

[Zsub]

offtopic:
lols nederlandse termen... moest ff twee keer kijken voordat ik snapte wat er stond

[Verwijderd]

nvm...

[ Voor 99% gewijzigd door Verwijderd op 22-07-2011 06:25 ]

[DDX]

Vandaag m'n xp vm systeempje ook van ipv6 proberen te voorzien, ging prima.
Maar op de een of andere manier krijg ik de tunnel adapter niet uit/weg.

Geprobeerd zoals op m'n windows 7 systeem via registry DisabledComponents op 1 te zetten.
Maar geen effect.

netsh interface teredo set state disabled
netsh interface ipv6 6to4 set state disabled

geven beide ok, maar ook dan blijven de interfaces netjes aan.

Iemand nog een idee ?

code:

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 192.168.178.12
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IP Address. . . . . . . . . . . . : 2001:980:4efa:1:5054:ff:fec0:ac00
   IP Address. . . . . . . . . . . . : fe80::5054:ff:fec0:ac00%4
   Default Gateway . . . . . . . . . : 192.168.178.1
                                       fe80::224:feff:fefc:13b8%4

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : fe80::ffff:ffff:fffd%5
   Default Gateway . . . . . . . . . :

Tunnel adapter Automatic Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : fe80::5efe:192.168.178.12%2
   Default Gateway . . . . . . . . . :

code:

netsh interface ipv6 show interface
Querying active state...

Idx  Met   MTU    State         Name
---  ----  -----  ------------  -----
  6     2   1280  Disconnected  Teredo Tunneling Pseudo-Interface
  4     0   1492  Connected     Local Area Connection
  3     1   1280  Connected     6to4 Pseudo-Interface
  2     1   1280  Connected     Automatic Tunneling Pseudo-Interface
  1     0   1500  Connected     Loopback Pseudo-Interface

Iemand nog tips ?
Is trouwens windows xp 64bits sp2

[Raven]

Weet iemand of er ondertussen firewalls voor XP en 7 clients zijn die IPv6 volledig ondersteunen?
Kan er met Google niet veel over vinden, behalve dan over firewalls voor routers, maar daar zoek ik niet naar.

Smart Security zou mooi zijn, ken de antivirus van ESET al en de GUI daarvan bevalt goed, maar op de site van hun is hier niet wat over terug te vinden.

edit: Zag net een email van ESET in mijn inbox, Smart Security zou er volledige ondersteuning voor hebben. Je zou verwachten dat ze zoiets wel even vermelden ipv weg te stoppen in de manual waar dan eerst naar gezocht moet worden.

edit2: henet (Hurricane Electric @ Twitter)
9274 of the Alexa top 1 million sites have a direct #IPv6 address. We've been waiting a while to say this, but "it's over nine thousaaand!!"

DBZ fan zo te zien

[ Voor 39% gewijzigd door Raven op 27-07-2011 10:20 ]

[Roetzen]

Raven schreef op dinsdag 26 juli 2011 @ 15:25:
edit2: [small]henet (Hurricane Electric @ Twitter)
9274 of the Alexa top 1 million sites have a direct #IPv6 address. We've been waiting a while to say this, but "it's over nine thousaaand!!"

9274 op een millioen. Dat is minder dan één procent.

Niet echt indrukwekkend...

[Raven]

I know, maar die reactie aan het einde

[Raven]

Even kleine update met het zoeken naar een client side firewall die IPv6 ondersteund. Heb ESET Smart Security er op staan, die detecteert iig de gemaakte IPv6 connecties.

Maar waarom die onder het proces van ESET Smart Security komen te staan ipv de browser is mij een raadsel.

[DDX]

Sinds kort heeft google blacklist ipv whitelist voor aantal ipv6 'diensten'.
Aangezien het 2a00:1450::/32 netwerk vanuit hier niet te benaderen is (level3) duurt het hierdoor erg lang voordat google/youtube pagina's geopend worden.

Maar eens kijken of ik google kan benaderen om ons op de ipv6 blacklist te zetten.

[CyBeR]

Ik kan bij google niet vinden dat ze iets veranderd hebben...

[DDX]

http://www.gossamer-threa...343?do=post_view_threaded

[Roetzen]

In wake of World IPv6 Day, browsers resist IPv6 brokenness—but should they?
By Iljitsch van Beijnum | Published about 2 hours ago

IPv6 brokenness is on the decline, but browser and operating system makers are implementing additional workarounds for good measure. These make things easier for users, but they may come back to bite us.

Lees meer: http://arstechnica.com/te...nt-to-ipv6-brokenness.ars

[Keiichi]

Hoe kan ik Linux met ip6tables het beste ervoor zorgen dat een bepaald subnet (of adres) als niet-werkend word gezien.

Ik kom af en toe destinations tegen die over ipv6 niet reageren, maar wel een AAAA entry hebben.

Ik heb bv dit gedaan:

code:

ip6tables -A OUTPUT -j REJECT -d 2a00:d00:ff:235::/64 --reject-with port-unreach

Maar het resultaat was een storm van icmp packages op het moment dat ik een address in dat subnet ging pingen.

Simpelere regels zoals

code:

ip6tables -D OUTPUT -j REJECT

code:

ping: sendmsg: Operation not permitted

Gaan hier weer op mis. Operation moet altijd permitted zijn (Firefox beging aardig over z'n nek te gaan hiervan), maar bestemming moet gewoon direct als niet bereikbaar gestempeld worden.

[ Voor 26% gewijzigd door Keiichi op 18-08-2011 00:47 ]

[Osiris]

En wat is er mis met die storm van ICMP-packages? Dat wil je toch ook?

[Keiichi]

Osiris schreef op donderdag 18 augustus 2011 @ 00:46:
En wat is er mis met die storm van ICMP-packages? Dat wil je toch ook?

Eh nee. Ik heb het dan over 2000 errors per seconden die ik op ping terugkrijg, dat vind ik niet zo heel tof

[Osiris]

Keiichi schreef op donderdag 18 augustus 2011 @ 00:48:
[...]

Eh nee. Ik heb het dan over 2000 errors per seconden die ik op ping terugkrijg, dat vind ik niet zo heel tof

Vrij suf. Je zou één rejection per ping-ICMP verwachten...

[Keiichi]

Dat dacht ik ook.

Heb je misschien nog ideeen over hoe ik meer een bepaalde IPv6 subnet voor mij onbeschikbaar kan maken, zonder heel m'n IPv6 zooi uit te hoeven knallen?

[Keiichi]

http://blog.iusmentis.com...e-spooknota-ipv6register/

spooknota's voor ipv6 . Spooknota's sowieso

[databeestje]

In pfSense 2.1-DEVELOPMENT heb ik DHCP-PD support toegevoegd. Mensen die een aansluiting hebben van een provider die native ipv6 aanbiedt via ethernet of met PPPoE (DSL).

Ik zoek nog mensen voor terugkoppeling om te verifieren of het in de echte wereld ook werkt. Op mijn Cisco 1811 in de lab setup werkt DHCP6 in ieder geval wat me goede hoop geeft.

op http://files.pfsense.org/jimp/ipv6/