Het grote IPv6 topic

[Jaap-Jan]

Nakebod schreef op maandag 29 juli 2013 @ 13:10:
[...]

Vorig jaar pas? Langer toch nieuws: Google maakt YouTube via ipv6 bereikbaar
Wel lees ik net dat youtube.com zelf een geruimte tijd geen AAAA records had, maar het videoplatform wel.
Dus misschien niet jaren-jaren, maar wel meer dan 1

Google begon wel met IPv6, maar stapsgewijs. Eerst werden alleen AAAA- records aangeboden aan DNS servers die verbonden via IPv6. Op woensdag 8 juni 2011 (op de eerste World IPv6 Day) stelde Google even YouTube volledig beschikbaar en pas sinds vorig jaar, op 6 juni 2012 (tweede World IPv6 Day) biedt Google permanent YouTube aan via IPv6.

[CyBeR]

Youtube's videoservers zijn al langer via IPv6 (incl publieke AAAA records) beschikbaar; de website is een ander verhaal.

[Keiichi]

@Jaap-Jan : Werkt jou webserver wel goed. Ik zie geen 'dansende Kame'

code:

telnet -6 vdvn.net 80
Trying 2001:7b8:38b:0:e269:95ff:fe62:13a9...
telnet: Unable to connect to remote host: Connection refused

[Jaap-Jan]

Gefixt. De firewall van de router blokkeerde toegang tot de webserver. Bedankt om me er op te wijzen.

[Verwijderd]

https://www.arin.net/resources/request/ipv4_countdown.html

PHASE THREE (TWO /8 EQUIVALENTS REMAINING, BEGAN AUGUST 2013)

[More Information]

ARIN staff will examine processes used in Phase Two to ensure they are working and make any necessary modifications.
The hold period for returned, reclaimed, and revoked blocks will remain at three months.
Request reviews will remain the same as in Phase Two, and requests for larger address blocks require department director approval.
Upon approval, IPv4 recipients will have 60 days to complete payment and/or an RSA. On the 61st day, the address space will be released back to the available pool if payment and RSA are not completed.

Phase 3 van ipv4 countdown is begonnen bij ARIN ;o;

[CAPSLOCK2000]

Phase One began in February 2011 when ARIN received its last /8 from IANA.
Phase Two began in September 2012 when ARIN reached three remaining /8 equivalents.
Phase Three began in August 2013 when ARIN reached two remaining /8 equivalents.
Phase Four will begin when ARIN reaches one remaining /8 equivalent.

Ze hebben dus ongeveer een jaar gedaan over het twee na laatste blok. Het voorlaatste blok zal dus over een jaar ook wel op zijn.

[KennieNL]

Voor de IRC-ers... QuakeNet heeft nu ook een IPv6 trial https://www.quakenet.org/news/288-ipv6-public-trial

[CAPSLOCK2000]

Ik heb m'n bittorrentclient IPv6-only gemaakt, gewoon om te kijken wat er zou gebeuren. Het werkt veel beter dan ik verwachte. De meeste dingen die ik wil downloaden komen gewoon binnen. Vooraf was mijn inschatting dat ongeveer 1% van internet IPv6 heeft en ik dus bij torrents met meer dan 100 peers wel succes zou hebben. Toen IPv4 nog aan stond zag ik af en toe een IPv6 peer.

Die schatting blijkt veel te voorzichtig te zijn geweest. Vrijwel alles wat ik heb geprobeerd is gewoon binnen gekomen. Het duurt wel wat langer, maar het werkt. Ik zie veel meer IPv6-peers dan ik verwachtte. Wat opvalt is dat allergrootste deel van de peers Teredo gebruikt, op gevoel zeg ik 90%.

Na wat onderzoek denk ik te snappen waarom ik het zo verkeerd heb ingeschat. Torrentclients identificeren zichzelf met een uniek nummer, zo kan je iemand met meerdere IP-adressen herkennen. Mijn torrentclient lijkt Teredo-adressen te herkennen. Als een peer zowel IPv4 als (Teredo) IPv6 heeft dan geeft mijn client de voorkeur aan IPv4. Met het oog op snel downloaden is dat terecht maar het verbergt wel dat velen ook via IPv6 zijn te bereiken.

Nu ik IPv6-only draai zie ik opeens een heel stel Teredo-adressen. Teredo misschien is niet de mooiste vorm van IPv6, maar het werkt wel.

Ik gebruik Transmission en heb IPv4 uitgeschakeld met "bind-address-ipv4": "127.0.0.1".
Er lijkt een bug in Transmission te zitten waardoor er niet met trackers wordt gecommuniceerd. Gelukkig doet PXE het wel.

[Keiichi]

Teredo tunnel zijn te herkennen aan het adres. Alle adressen in de prefix 2001:0::/32 zijn teredo tunnels.

Verder te herkennen:

2002::/16 : 6to4 addresses

Andere speciale prefix die je niet in het wild hoort te zien:

2001:db8::/32 : documentation addresses
5f00::/8 : eerste 6bone netwerk
3ffe::/16 : tweede 6bone netwerk
2001:10::/28 : Overlay Routable Cryptographic Hash IDentifiers

Op verschillende RFC's kun je wel eea aan intressante informatie vinden ( De prefixes staan hier vermeld: http://tools.ietf.org/html/rfc5156 )

[webfreakz.nl]

Ik heb afgelopen zaterdag zitten knutselen met een IPv6-over-OpenVPN-tunnel naar m'n VPS voor mijn IPv6 connectiviteit. Het had nogal wat voeten in de aarde:

- OpenVPN moest ik zelf compilen omdat Ubuntu 10.04 geen packages heeft voor de benodige OpenVPN versie met IPv6 support (nog redelijk nieuw). Dat compilen was appeltje eitje, alleen krijg je geen mooie system daemon.
- Nu de tunnel op was bleek dat de server kant (PC thuis was client) het IPv6 adres aan zijn tap0 interface als een /128 instelde. Dus je moest nog een extra /128 instellen voor het IPv6 adres van de client.
- Toen moest ik nog een Neighbor Discovery Protocol proxy instellen omdat de router in het netwerk bij mijn VPS anders de return packets niet af kan leveren. Eerst had ik het via "ip -6 neigh add proxy $bla" gedaan maar dat bleek niet te werken. Toen een "neighbor discovery protocol proxy daemon" gevonden via Google die de hele VPN interface kon NDP-proxyen. Dat werkte prima, echter vond ik het maar een gare oplossing want het had geen init.d scripts en dergelijke. Toen de methode met "ip -6 ..." nog eens geprobeerd, deze wilde nu wel werken..
- Nu leek alles goed te gaan, maar Windows verkoos voor verkeer naar IPv6 capable websites (dual stack) daarna de IPv6 default-route die OpenVPN installeert níét boven de IPv4 default-route omdat de laatste een betere metric had. Dus moest ik weer handmatig de IPv6 default route instellen met een goede metric.

Het kan allemaal wel wat makkelijker zeg

Een grappige iets wat ik hierna merkte was dat ik nu prima IPv6 connectiviteit had volgens www.test-ipv6.com . Youtube en Google werkten ook prima. Toen ik echter mijn IPTables firewall op mijn VPS weer inschakelde kreeg ik bij Google errors en moest ik een CAPTCHA invullen om weer toegang te krijgen, maar dat kreeg ik niet na het correct invullen. Als ik de firewall weer uitzette, werkte het direct. De firewall had 3 hele simpele regels: 1) sta ál het ICMPv6 verkeer vanaf VPS-WAN toe naar VPN. 2) Sta bekende connecties toe naar de VPN 3) Vanuit de VPN mag alles naar internet. That's it , en Google ging stuk... nog totaal geen idee waarom.

[Maurits van Baerle]

CAPSLOCK2000 schreef op dinsdag 13 augustus 2013 @ 20:27:
[..]
Ik gebruik Transmission en heb IPv4 uitgeschakeld met "bind-address-ipv4": "127.0.0.1".
Er lijkt een bug in Transmission te zitten waardoor er niet met trackers wordt gecommuniceerd. Gelukkig doet PXE het wel.

Goed dat PEX het in ieder geval wel doet. Denk je dat het bug #1731 IPv6 does not work against dual-stacked trackers is? Dat lijkt al jaren een probleem te zijn...

[CAPSLOCK2000]

Ik dacht zelf meer aan https://trac.transmissionbt.com/ticket/4327 . Ik heb nog meer bugs in de tracker gezien die gelateerd lijken te zijn. Ik geloof dat ze een paar hacks hebben geprobeerd om Transmission beter te laten werken in een omgeving met slechte IPv6 connectiviteit. Er zijn allerlei bugs over dual-stack trackers waarbij allerlei hackerige oplossingen worden gesuggereerd. Ik heb het gevoel dat we van de regen in de drup komen met al die "verbeteringen". Als je IPv6 stuk is dan is het niet aan je torrentclient om dat op te gaan lossen.

[databeestje]

Let wel dat er inmiddels sprake is van het "Sunsetting" van Teredo door Microsoft zelf. Als je het een paar weken geleden geprobeerd had was er lang niet zoveel Teredo te zien, toen stonden de servers hiervoor "uit".

https://isc.sans.edu/diar...Server+%22Sunset%22/16153

Ik gebruik zelf OpenVPN in combinatie met pfSense, daar zit OpenVPN 2.3 in en kan dual-stack. Vondt ik zelf de makkelijkste methode, werkt zelfs dual stack met mijn Android 4.1 telefoon. Erg fijn. Ook Viscosity doet tegenwoordig probleemloos Dual Stack met Windows en op de Mac.

Ik gebruik thuis een HE.net tunnel, en verbind met OpenVPN daarheen. Een volledige /48 die ik op kan delen.

Nu maar hopen dat ISPs het begrijpen en een /56 uitdelen aan de gebruikers. Anders falen de providers gewoon opnieuw.

[CAPSLOCK2000]

Interessant, dat van die sunset voor teredo wist ik nog niet.
Maar ik heb dit experiment helaas nog niet eerder gedaan. Wel gebruik ik al jaren IPv6 en Bittorrent (niet noodzakelijk in combinatie). Ik meende dus wel enig gevoel te hebben van hoeveel IPv6-peers er "horen" te zijn zijn en hoveel daarvan Teredo zijn.
Ik kan natuurlijk niet uitsluiten dat ik toevallig op een interessant moment ben begonnen. Ik heb inmiddels besloten om m'n client op IPv6-only te laten staan tot ik echte problemen tegen kom. Het werkt goed genoeg voor m'n dagelijkse downloads.

[Maurits van Baerle]

Interessant, de AMS-IX heeft voor het eerst de 9,6 Gbps aangetikt. Bovendien met een fiks verschil van 6,8 Gbps tussen de piek in de avond en het dal midden in de nacht. Het lijkt dus sterk op consumentenverkeer.

AMS-IX: Total IPv6 Traffic - daily

[Snow_King]

Maurits van Baerle schreef op woensdag 21 augustus 2013 @ 23:32:
Interessant, de AMS-IX heeft voor het eerst de 9,6 Gbps aangetikt. Bovendien met een fiks verschil van 6,8 Gbps tussen de piek in de avond en het dal midden in de nacht. Het lijkt dus sterk op consumentenverkeer.

AMS-IX: Total IPv6 Traffic - daily

De grote vraag is dan: Bij wie komt het vandaan?

[Keiichi]

Snow_King schreef op donderdag 22 augustus 2013 @ 08:12:
[...]
De grote vraag is dan: Bij wie komt het vandaan?

o.a. Mij. Op mijn freebsdbakrouter heb ik met cacti trafficgrafieken per interface en hieruit komt dat ik met grote regelmaat gewoon ipv6 verkeer verstook. Ik gok vooral aan google, youtube, dumpert, ubuntu mirror en connecties via ssh met mijn servers in het DC (geen consumentenverkeer, maar wel overdag en niet geautomatiseerd)

[Maurits van Baerle]

Keiichi schreef op donderdag 22 augustus 2013 @ 08:53:
[...]


o.a. Mij. Op mijn freebsdbakrouter heb ik met cacti trafficgrafieken per interface en hieruit komt dat ik met grote regelmaat gewoon ipv6 verkeer verstook. Ik gok vooral aan google, youtube, dumpert, ubuntu mirror en connecties via ssh met mijn servers in het DC (geen consumentenverkeer, maar wel overdag en niet geautomatiseerd)

Het komt natuurlijk van een heleboel individuen, onder andere iedereen die van XS4ALL standaard dual-stack heeft gekregen zoals mijn vader die (zonder het door te hebben) z'n YouTube filmpjes over IPv6 binnenhaalt.

Wat Snow_King natuurlijk bedoelt is: welke consumenten provider is aan het experimenteren met verkeer over IPv6 sturen? Het begon een paar weken geleden toen er ineens een paar dagen lang een enorme piek was. En nu dus weer. Het lijkt op een ISP of telco die af en toe IPv6 opengooit. Hun klanten hebben het waarschijnlijk niet eens door.

Zowel Ziggo als UPC hebben aangegeven dit jaar IPv6 uit te gaan rollen. Misschien zijn zij het wel. Het zou ook één van de 4G netwerken zijn die nu worden uitgerold. LTE en IPv6 gaan vaak hand in hand.

[ Voor 9% gewijzigd door Maurits van Baerle op 22-08-2013 11:15 ]

[Keiichi]

Ik was bezig met het analyzeren van m'n apache logs en daar lijken heel veel verzoeken vanaf facebook servers tussen te zitten, deze useragent geeft ook deze help url vrij : https://www.facebook.com/externalhit_uatext.php


Kan ik trouwens ergens makkelijk een AS nummer bij een IPv6 adres zoeken? Dan zou ik per 'provider' kunnen kijken wat er allemaal actief is.

[ Voor 24% gewijzigd door Keiichi op 22-08-2013 13:45 ]

[webfreakz.nl]

whois $ip6-address

?

ronald@tartarus:~$ whois 2a02:26f0:18:1:9d00::c77 | grep origin
origin: AS20940

Sinds kort:

C:\Users\ronald>nslookup www.apple.com
Server: google-public-dns-b.google.com
Address: 2001:4860:4860::8844

Niet-bindend antwoord:
Naam: e3191.dscc.akamaiedge.net
Addresses: 2600:1402:e:282::c77
2600:1402:e:28b::c77
23.74.189.15
Aliases: www.apple.com
www.isg-apple.com.akadns.net
www.apple.com.edgekey.net


C:\Users\ronald>nslookup apple.com
Server: google-public-dns-b.google.com
Address: 2001:4860:4860::8844

Niet-bindend antwoord:
Naam: apple.com
Addresses: 17.178.96.59
17.172.224.47
17.149.160.49

[ Voor 17% gewijzigd door webfreakz.nl op 22-08-2013 14:50 ]

[Keiichi]

Ik heb ongeveer 1400 unieke ipv6 addressen, ik denk niet dat een whois server daar blij van wordt.

Heb overigens al iets gevonden denk ik, ik heb een bgpdump kunnen download en uitlezen. Ben nu wat scripts er over aan het loslaten

[Tomsworld]

Ondertussen zijn sinds gisteren alle root dnssen van .be zone ook dual stack.

http://www.iana.org/domains/root/db/be.html

En announced vanuit een nieuwe 32bit as nummer als anycast.

[Keiichi]

Ik heb een kleine top 20 gemaakt

code:

6939    47229    Hurricane Electric
237     25150    Merit Network Inc
3265    14698    Xs4all Internet BV
6621     8386    Hughes Network Systems
32934    6518    Facebook
15395    6374    Rackspace Ltd.
7922     6097    Comcast
16276    6078    OVH
1659     5362    Tiawan Academic Network (TANet) Information Center
39832    5016    Opera
22394    3958    Cellco Partnership DBA Verizon Wireless
12816    3516    Leibniz-Rechenzentrum
23910    2638    China Next Generation Internet CERNET2
12634    2279    Scarlet
12322    2216    Free SAS
3320     1913    Deutsche Telekom AG
16880    1293    TREND MICRO INCORPORATED
2852     1016    CESNET
8517     1014    National Academic Network and Information Center
24940     960    Hetzner Online AG

Kolom #1 AS netwerk
Kolom #2 http-acccess hits
Kolom #3 handmatig opgezochte naam

Ik heb het AS waar ik zelf erop zit weggehaald, dit gaf eenv ertekend beeld.

[CAPSLOCK2000]

Als je over een wat langere periode naar IPv4 kijkt (bv https://stats.ams-ix.net/...l?log=totalall;png=yearly of bij deze Duitse IX: http://www.de-cix.net/about/statistics/ ) zie je dat we ieder jaar een teruggang hebben tussen februarie en augustus. IPv6 lijkt hetzelfde patroon te volgen.
Misschien omdat de vakanties weer voorbij zijn?

[CyBeR]

De enige echte achteruitgang is inderdaad vanwege de vakanties en dat is in juli tot begin augustus. En de avond van 1e kerstdag is ook altijd duidelijk te spotten.

[ Voor 7% gewijzigd door CyBeR op 22-08-2013 18:18 ]

[Maurits van Baerle]

Gisteren is de AMS-IX ineens dwars door de 10 Gb/s heen gevlogen naar 10.8. Er is duidelijk iets aan de hand met IPv6 consumentenverkeer.

[Raven]

Hmm, hebben we een aankondiging van een grote ISP gemist die ineens IPv6 ondersteund?

[ Voor 3% gewijzigd door Raven op 02-09-2013 12:02 ]

[Maurits van Baerle]

Nee, dat lijkt me stug. Het is eerder een grote ISP die onaangekondigd aan het experimenteren is. Bovendien, als bijvoorbeeld Ziggo in één keer al hun klanten overzet zal de toename veel groter zijn. Het lijkt er eerder op alsof er één regio of klantengroep van een consumentenISP ineens dual-stack is gegaan om te kijken wat er gebeurt.

[Raven]

Maar levert dat niet een beveiligingsrisico op voor de gebruikers? Als IPv6 ineens onverwacht aangaat en de firewall daar niet op voorbereid is, staat je pc dan niet ineens helemaal open en bloot?

[Maurits van Baerle]

Raven schreef op maandag 02 september 2013 @ 13:11:
Maar levert dat niet een beveiligingsrisico op voor de gebruikers? Als IPv6 ineens onverwacht aangaat en de firewall daar niet op voorbereid is, staat je pc dan niet ineens helemaal open en bloot?

Dit zijn natuurlijk allemaal routers die sowieso al voorbereid waren op Dual-Stack (anders was er geen IPv6 verkeer) en die dus ook normaal gesproken een default-deny firewall aan hebben staan. Ik heb nog niet gehoord van consumenten routers waarbij dat niet zo is.

[CAPSLOCK2000]

Wat is er vannacht gebeurd?
We kunnen moeilijk bij ieder piekje hier blijven posten, maar WTF, het dal van vannacht lag hoger dan de hoogste pieken van een maand geleden.

[Keiichi]

Geen idee, maar het zijn wel signalen dat er her en der veranderingen zijn. Ik heb gisterenavond dan ook wel tijd lang wat extra ipv6 gegenereerd, maar dat waren maar mbits

[Raven]

Millibitjes ga je inderdaad niet zien op die grafieken

[Maurits van Baerle]

Inderdaad vreemd, een forse piek ineens naar 11.6 Gb/s (ook nog rond middernacht) en een veel hoger dal. Aangezien er ineens een veel meer stabiel hoog dal is, is het amper een plotselinge toename van het consumentenverkeer. Die gebruiken niet zoveel om 4 uur 's nachts.

Het zou me niets verbazen als deze toename komt omdat de AMS-IX per 6 september (afgelopen nacht dus) een nieuwe peering erbij heeft die veel IPv6 verkeer levert.

[Bigs]

Maurits van Baerle schreef op maandag 02 september 2013 @ 13:17:
[...]

Dit zijn natuurlijk allemaal routers die sowieso al voorbereid waren op Dual-Stack (anders was er geen IPv6 verkeer) en die dus ook normaal gesproken een default-deny firewall aan hebben staan. Ik heb nog niet gehoord van consumenten routers waarbij dat niet zo is.

Euh de Asus RT-N66U heeft dual stack standaard aanstaan en heeft géén firewall voor IPv6. De standaard firmware biedt die mogelijkheid niet. Dus elk apparaat dat zich via een RA configureert staat automatisch wijd open naar het internet.Had ik niet verwacht toen ik hem kocht.

[webfreakz.nl]

Dat is wel heel kwalijk...

[Nakebod]

Had van ASUS eigenlijk wel iets beters verwacht. Waarschijnlijk één van de vele waarbij dit (totaal) niet goed geregeld is.
Ben ik blij met mijn OpenWRT based router, alleen de poorten open die ik open wil hebben, en de overige poorten zijn standaard geblokkeerd. Ook ICMPV6-ECHO is standaard disabled, dus eigenlijk bestaan al mijn andere apparaten niet voor het grote boze internet

[webfreakz.nl]

Nakebod schreef op vrijdag 06 september 2013 @ 14:28:
Ook ICMPV6-ECHO is standaard disabled, dus eigenlijk bestaan al mijn andere apparaten niet voor het grote boze internet

Ik zou het wel inschakelen, mét een rate-limiter

[Nakebod]

Ik denk eigenlijk dat ik dat tegenwoordig al aan heb staan, onlangs de firewall settings opnieuw doorgelopen, nadat ik eindelijk mijn Windows 8 machine goed dual-stack heb verbonden. (Na verschillende IP/IPv6 stack resets en weetikveel wat nog meer..)

Wel via een sixxs tunnel "helaas". Om één of andere reden wil mijn 6RD van XMS niet goed werken bij mij. Windows machines krijgen een IPv6 adres, en dat was het ongeveer wel Terwijl mijn Linux laptop/NAS/Android devices als ik het goed heb allemaal wel via IPv6/dualstack konden verbinden.

[FatalError]

Nakebod schreef op vrijdag 06 september 2013 @ 15:00:
Wel via een sixxs tunnel "helaas". Om één of andere reden wil mijn 6RD van XMS niet goed werken bij mij. Windows machines krijgen een IPv6 adres, en dat was het ongeveer wel Terwijl mijn Linux laptop/NAS/Android devices als ik het goed heb allemaal wel via IPv6/dualstack konden verbinden.

Werkt Windows nu wél of niet?
Ik had laatst ook even 6RD geprobeerd bij Lijbrandt.. Dat werkte zo op het eerste gezicht prima.

[Nakebod]

In het kort: Het werkt (gelukkig) weer.
Net de SixXS tunnel uitgezet en ik zie weinig problemen meer met de XMS verbinding op dit moment

Ergens in mijn Win8 install zat een probleem waardoor de 6RD oplossing van XMS een hele tijd uberhaupt niet goed gewerkt heeft. Ik kreeg het niet gevonden waar het nu in zat. De SixXS tunnel deed het wel. Na mijn laatste pogingen van afgelopen week (o.a. nogmaals ipv6 stack reset) werkt het IPv6 gedeelte van XMS nu schijnbaar wel. Gister volgens mij toch echt nog niet

Voor die tijd kon ik via XMS niet eens verbinden naar (mijn) servers via IPv6-only, ondanks dat mijn Win8 PC gewoon een goed IPv6 adres had, en ook vanaf mijn router/laptop pingbaar was (En andersom).

Maar dualstack loopt via IPv4 (Omdat 6RD dat nu eenmaal zo wil). Het is natuurlijk wel leuker om alles via IPv6 te doen:
Start -> Run -> "cmd" -> "netsh" -> "interface" -> "ipv6"
set prefix 2002::/16 30 1

En om IPv4 weer standaard te maken:
set prefix 2002::/16 30 2

En dualstack op mijn Windows machine werkt nu ook. Denk wel dat ik mij vergist heb qua Linux, daar werkt dualstack ook niet via XMS. Tenzij ik ook daar de volgorde aanpas.
Enige wat nog steeds niet werkt is ping -6, krijg wel het juiste adres terug, maar ook een timeout. Via mijn Linux laptop werkt ping6 wel goed.

[databeestje]

Let op dat 6rd en tunnels soms probleme geven met mtu en fragmentaties, dit door internet providers die op ipv6 icmp packet too big niet doorlaten.

Een ander probleem is bijvoorbeel met pf, de firewall in bsd land welke niet om kan gaan met gefragmenteerd ipv6 verkeer. Daar geeft dit ook problemen.

[Bigs]

Ik heb zelf een 6rd verbinding via Onsbrabantnet (lokale glasvezel provider) i.c.m. de eerder genoemde Asus router en dat werkt eigenlijk prima. Alleen ontdek je dan toch rare dingen. Ik heb op de bovenverdieping een 2e Wi-Fi access point via een Homeplug AV en op de een of andere manier ontvangen apparaten die daaraan hangen geen RA's van mijn Asus router. Aan een andere Homeplug ontvanger hangt een bedraadde computer en die ontvangt ze wel. Dat wil zeggen dat er in dat access point dus toch iets raars gebeurt. Beetje jammer.

[Out.of.Control]

databeestje schreef op vrijdag 06 september 2013 @ 20:59:
Let op dat 6rd en tunnels soms probleme geven met mtu en fragmentaties, dit door internet providers die op ipv6 icmp packet too big niet doorlaten.

Een ander probleem is bijvoorbeel met pf, de firewall in bsd land welke niet om kan gaan met gefragmenteerd ipv6 verkeer. Daar geeft dit ook problemen.

Dat eerste lijkt me eerder een probeem van te strak afgerichte firewalls (ICMP is evil!) dan providers die filteren.

En dat laatste was misschien zo, maar nu niet meer. In OpenBSD (waar de ontwikkeling van pf gebeurt) is dit sinds versie 5.1 flink verbeterd. Pingen met een payload die veel groter is dan de MTU van mijn Sixxs-tunnel werkt in ieder geval probleemloos.

[databeestje]

Bigs schreef op zaterdag 07 september 2013 @ 15:34:
Ik heb zelf een 6rd verbinding via Onsbrabantnet (lokale glasvezel provider) i.c.m. de eerder genoemde Asus router en dat werkt eigenlijk prima. Alleen ontdek je dan toch rare dingen. Ik heb op de bovenverdieping een 2e Wi-Fi access point via een Homeplug AV en op de een of andere manier ontvangen apparaten die daaraan hangen geen RA's van mijn Asus router. Aan een andere Homeplug ontvanger hangt een bedraadde computer en die ontvangt ze wel. Dat wil zeggen dat er in dat access point dus toch iets raars gebeurt. Beetje jammer.

Sommige routers/switches/accesspoints/etc filteren helaas Multicast in zijn geheel. Multicast != broadcast maar wordt door veel wifi bedrijven wel als dusdanig gefiltered.

[Bigs]

databeestje schreef op dinsdag 10 september 2013 @ 20:26:
[...]

Sommige routers/switches/accesspoints/etc filteren helaas Multicast in zijn geheel. Multicast != broadcast maar wordt door veel wifi bedrijven wel als dusdanig gefiltered.

Ik had me eigenlijk nog niet eerder verdiept in hoe de Neighbor Discovery werkt, maar dat verklaart inderdaad wel waarom mijn access point het (onterecht) filtert.

[Freeaqingme]

Waarom zouden die dingen dat filteren?

[Osiris]

Naar mijn weten kent IPv6 geen broadcast meer. Enig niveau van multicast-filtering is dus niet zo heel erg raar. Veel shit uit 't interne netwerk qua multicasting hoeft niet richting je ISP ofzo. Al zijn er meerdere niveaux van multicasting, waardoor het tot je LAN beperkt zou moeten blijven.

[Maurits van Baerle]

Als we vanaf nu ineens een constant toegenomen hoeveelheid IPv6 verkeer zien dan is het waarschijnlijk Netflix. Die gebruiken IPv6 en zijn net een uurtje geleden in Nederland gelanceerd..

Het patroon wat we tot nu toe hebben gezien zou goed kloppen, weinig 's morgens, veel 's avonds en dus wat testjes in de afgelopen weken in aanloop naar de lancering.

[Xanland]

IPv6 is toch even "gemakkelijk" te configureren als IPv4-adressen bij je netwerkadapter?

Via het knopje "Advanced" heb ik meerdere IPv6-adressen staan met ::1, ::2 en ::3 en subnet 48. Maar pingen met: ping -6 -S [IPv6-IP::2] irc.gtanet.com werkt gewoon niet: 100% packet loss. Met het pingen vanaf ::3 hetzelfde en ::1 0/25% packet loss.
Zie ik dan verder nog iets over het hoofd?

Xanland schreef op woensdag 11 september 2013 @ 21:35:
Woops, sorry onduidelijk.

Heb een 2a01-ip, gewoon een publiekelijk IP van mijn VPS-hoster CloudVPS. Het is van een /64, maar ik moet dan weer 48 invullen bij subnet... Met dat eerst ingestelde IP, wat je dus meteen in kan stellen zonder Advanced, heb ik gewoon internet. Gateway en subnet kloppen dus gewoon!

[ Voor 35% gewijzigd door Xanland op 11-09-2013 21:35 ]

[Osiris]

Ligt eraan.

Als jij een setje link-local adressen hebt, phat chance dat 't gaat werken natuurlijk

Verder kan iets wel IPv6-adressen "uitdelen", maar als het vervolgens verderop richting 't interwebz kaduuk is, dan schiet dat ook niet op. Je ISP e.d. moet 't ook supporten natuurlijk. Daar hoor ik je niet over

[Xanland]

Woops, sorry onduidelijk.

Heb een 2a01-ip, gewoon een publiekelijk IP van mijn VPS-hoster CloudVPS. Het is van een /64, maar ik moet dan weer 48 invullen bij subnet... Met dat eerst ingestelde IP, wat je dus meteen in kan stellen zonder Advanced, heb ik gewoon internet. Gateway en subnet kloppen dus gewoon!

[Maasluip]

Maurits van Baerle schreef op woensdag 11 september 2013 @ 01:09:
Als we vanaf nu ineens een constant toegenomen hoeveelheid IPv6 verkeer zien dan is het waarschijnlijk Netflix. Die gebruiken IPv6 en zijn net een uurtje geleden in Nederland gelanceerd..

Het patroon wat we tot nu toe hebben gezien zou goed kloppen, weinig 's morgens, veel 's avonds en dus wat testjes in de afgelopen weken in aanloop naar de lancering.

Er is geen constant toegenomen IPv6 verkeer. Het was een eenmalig iets. Sinds 7 september is het weer exact zoals het voor 6 september was.

[Maurits van Baerle]

Maasluip schreef op donderdag 12 september 2013 @ 07:29:
[...]

Er is geen constant toegenomen IPv6 verkeer. Het was een eenmalig iets. Sinds 7 september is het weer exact zoals het voor 6 september was.

Ja, we kunnen Netflix dus uitsluiten als de veroorzaker. Zou het dan toch één van de twee grote kabelISP's zijn die dit jaar IPv6 zouden introduceren voor consumenten?

[Out.of.Control]

Maurits van Baerle schreef op donderdag 12 september 2013 @ 14:47:
[...]

Ja, we kunnen Netflix dus uitsluiten als de veroorzaker. Zou het dan toch één van de twee grote kabelISP's zijn die dit jaar IPv6 zouden introduceren voor consumenten?

Of zou Netflix een grote bult content van weet ik veel waar naar een datacenter ergens in Nederland hebben overgezet?

[Keiichi]

Out.of.Control schreef op donderdag 12 september 2013 @ 19:28:
[...]


Of zou Netflix een grote bult content van weet ik veel waar naar een datacenter ergens in Nederland hebben overgezet?

Dat lijkt me wel het meest logische. Met AMS-ix zijn ze met 140G gepeered nu (zie https://www.peeringdb.com...rticipant_view.php?id=457 ) Met NL-ix zelfs 180G lijkt het.

Het lijkt me niet dat je zulke hoeveelheden over je transit verbinding wil gooien, dat is vrij duur namelijk.

[webfreakz.nl]

Netflix host vooral bij Amazon.

[CyBeR]

Netflix hangt met 2x 100GbE aan AMS-IX.

Stevig aangepakt moet ik zeggen.

[ Voor 35% gewijzigd door CyBeR op 13-09-2013 00:03 ]

[Nakebod]

Kan mij alleen niet voorstellen dat Netflix zo redelijk last-minute alle content naar lokale servers heeft gepompt. Of misschien aanvullen van wat er in de loop van de tijd stond.
Al zou het qua data misschien wel kunnen, de piek was ongeveer 4 Gbps hoger dan normaal.
Als ik de waardes een keer niet door elkaar haal komt dat geloof ik neer op ~512MB per seconde, ~30GB per minuut, 1.8TB per uur. Ofzoiets. Er zijn dagen dat ik minder download

[webfreakz.nl]

Mja, 4Gbps is niet zo heel spannend.

reviews: Netflix: legale luiheid voor 8 euro per maand

Netflix probeert ook de kosten van bandbreedte laag te houden door rechtstreeks te peeren met internetproviders. In Nederland heeft Netflix peeringcontracten met KPN en Ziggo. "We zijn in onderhandeling met UPC", zegt Hunt. "Dat is een wat lastiger verhaal, omdat UPC ook in veel andere landen actief is."

Interessant met die private peerings. Misschien wel een constructie waarbij Netflix aan de peeringpartijen betaalt voor de porten. Zou vergelijkbaar zijn met de situatie dat Netflix had met Comcast / Level3.

[Maurits van Baerle]

Nakebod schreef op vrijdag 13 september 2013 @ 07:40:
Kan mij alleen niet voorstellen dat Netflix zo redelijk last-minute alle content naar lokale servers heeft gepompt. Of misschien aanvullen van wat er in de loop van de tijd stond.
Al zou het qua data misschien wel kunnen, de piek was ongeveer 4 Gbps hoger dan normaal.
Als ik de waardes een keer niet door elkaar haal komt dat geloof ik neer op ~512MB per seconde, ~30GB per minuut, 1.8TB per uur. Ofzoiets. Er zijn dagen dat ik minder download

Ach, het was een week vantevoren. Zo last-minute is dat nou ook weer niet. Overigens zou het wel verklaren waarom het een constante stroom was die zo'n 24 uur duurde en dus dat dal flink vulde. Het enige dat vreemd is dat ze dat dan uitgerekend op de drukste tijd van de week doen, zondag avond...

[Raven]

Hier was het misschien het drukste moment, maar aan de andere kant van de aardbol (andere tijdzone) misschien niet? Weet niet waar het vandaan kwam?

[ Voor 12% gewijzigd door Raven op 13-09-2013 11:12 ]

[Nakebod]

Nouwja, ik zou een kleine week voor de grand opening in een nieuw land toch aardig defineren als last minute
Maar misschien was het niet eens last minute, en was de content al gewoon beschikbaar, alleen hebben ze nu meer content via lokale servers.

Als het uiteraard Netflix is geweest dan.

[CyBeR]

webfreakz.nl schreef op vrijdag 13 september 2013 @ 10:21:
Mja, 4Gbps is niet zo heel spannend.

reviews: Netflix: legale luiheid voor 8 euro per maand


[...]
Interessant met die private peerings. Misschien wel een constructie waarbij Netflix aan de peeringpartijen betaalt voor de porten. Zou vergelijkbaar zijn met de situatie dat Netflix had met Comcast / Level3.

Nergens staat dat 't private peerings zijn.

[webfreakz.nl]

CyBeR schreef op vrijdag 13 september 2013 @ 12:09:
[...]


Nergens staat dat 't private peerings zijn.

Ik vermoed dat het wel private peerings zijn, gezien de significante hoeveelheid van Netflix op de AMS-IX porten zullen ze dit op een beter punt het netwerk in willen laten komen, ook om zo de rest van het AMS-IX verkeer niet te storen.

[CyBeR]

webfreakz.nl schreef op vrijdag 13 september 2013 @ 13:38:
[...]

Ik vermoed dat het wel private peerings zijn, gezien de significante hoeveelheid van Netflix op de AMS-IX porten zullen ze dit op een beter punt het netwerk in willen laten komen, ook om zo de rest van het AMS-IX verkeer niet te storen.

Nouja policy van KPN is zo veel mogelijk via AMS-IX te doen.

En AMS-IX ligt ook niet echt wakker van een honderd gig aan verkeer meer of minder.

[Keiichi]

CyBeR schreef op vrijdag 13 september 2013 @ 13:58:
[...]

Nouja policy van KPN is zo veel mogelijk via AMS-IX te doen.

En AMS-IX ligt ook niet echt wakker van een honderd gig aan verkeer meer of minder.

Ik denk dat dat wel de policy van elke nederlandse provider is. De prijzen voor een fysieke aansluiting op een IX is een fractie van een transit lijn.

[CyBeR]

Keiichi schreef op vrijdag 13 september 2013 @ 15:42:
[...]


Ik denk dat dat wel de policy van elke nederlandse provider is. De prijzen voor een fysieke aansluiting op een IX is een fractie van een transit lijn.

Ik bedoelde ams-ix versus private peering.

[Keiichi]

CyBeR schreef op vrijdag 13 september 2013 @ 16:21:
[...]


Ik bedoelde ams-ix versus private peering.

Wat is eigenlijk het verschil tussen private en public peering? Het leek mij sowieso als een BGP beer opzet met ASxxxx dat via die 'verbinding' alleen verkeer van en naar ASxxxx verloopt. Voor alle niet direct-gepeerde AS-netwerk zullen via transits moeten lopen.

Het kan zijn dat ik misschien een verkeerd beeld van een IX heb.

[webfreakz.nl]

Het idee van peering is dat je alleen hun routes zal ontvangen. Bij transit zal je alle routes uit de DFZ (Default Free Zone) ontvangen, of een subset daarvan via BGP communities, of alleen een default route.

Public peering, bijvoorbeeld via de AMS-IX / NL-IX / LINX, geeft je dus alleen de routes van elke partij waar jij een peering mee opzet. Eventueel kan je een route-server gebruiken, zodat je op het moment van schrijven niet met ~616 partijen een peering hoeft op te zetten, niet alle partijen doen dat.

Private peering, hier komt de AMS-IX helemaal niet bij kijken, is letterlijk een kabel tussen partij X naar partij Y, waarbij je ook alleen hún routes ontvangt en geen routes uit de DFZ.

[ Voor 7% gewijzigd door webfreakz.nl op 13-09-2013 18:55 ]

[Raven]

Weet iemand een goede manier om te testen of protocol 41 door de router heen komt? Google verwijst naar http://www.sixxs.net/forum/?msg=setup-5200361

code:

hping3 -0 <destination> -H 41 -d 10

maar of ik heb telkens IP-adressen te pakken die niet reageren, of het wordt geblokkeerd. Maar ik zie niets in IPFire's log voorbij komen dat er op duid dat het geblokkeerd wordt

[ Voor 8% gewijzigd door Raven op 19-09-2013 19:15 ]

[Freeaqingme]

Ik heb het net even geprobeerd. Op A:

code:

sudo hping3 -0 B -H 41 -d 10
HPING B (eth0 <ip van b>): raw IP mode set, 20 headers + 10 data bytes
^C
--- B hping statistic ---
62 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Op B:

code:

sudo tcpdump -i any ip proto 41 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:28:26.315860 IP A > B: [|ip6]
19:28:27.313052 IP A > B: [|ip6]
19:28:28.313920 IP A > B: [|ip6]

Dat is overigens vanaf een particulier Ziggo abbo naar een VPS bij Transip.

[ Voor 6% gewijzigd door Freeaqingme op 19-09-2013 19:30 ]

[Raven]

Is die VPS wel ingesteld om te reageren met protocol 41 pakketjes en laat jouw router ze wel door? Zowel bij jou als bij mij worden ze wel verstuurd, maar er komt geen antwoord terug.

[ Voor 9% gewijzigd door Raven op 19-09-2013 19:43 ]

[ik222]

Keiichi schreef op vrijdag 13 september 2013 @ 18:46:
[...]


Wat is eigenlijk het verschil tussen private en public peering? Het leek mij sowieso als een BGP beer opzet met ASxxxx dat via die 'verbinding' alleen verkeer van en naar ASxxxx verloopt. Voor alle niet direct-gepeerde AS-netwerk zullen via transits moeten lopen.

Het kan zijn dat ik misschien een verkeerd beeld van een IX heb.

In beide gevallen ontvang je via de peering inderdaad de routes van dat AS. Maar het grote verschil is natuurlijk dat bij een verbinding via een IX (public peering) het verkeer vervolgens over de verbinding met de IX gaat lopen waar ook het verkeer van en naar de overige peers overeen gaat. Terwijl je met een private peering een aparte verbinding gebruikt, bij wijze van spreken een kabeltje naar de kast ernaar als daar de router van je peering partner staat. Als je veel verkeer uitwisselt kan dat dus aantrekkelijk zijn, bijvoorbeeld omdat je op die manier niet afhankelijk bent van het IX platform of vanwege kosten. Je kunt er ook nog redundantie mee creëeren als je met een belangrijke partij zowel een public als een private peering hebt.

[ Voor 5% gewijzigd door ik222 op 19-09-2013 19:47 ]

[Freeaqingme]

Raven schreef op donderdag 19 september 2013 @ 19:43:
Is die VPS wel ingesteld om te reageren met protocol 41 pakketjes en laat jouw router ze wel door? Zowel bij jou als bij mij worden ze wel verstuurd, maar er komt geen antwoord terug.

Zowel A als B kunnen gewoon een tunnel naar tunnelbroker.net opzetten, een firewall die er tussen zit is het dus niet (ik heb 100% zeker geen ip adressen van tunnelbroker geexclude). Je moet alleen even kijken wat hping3 doet, met de H-parameter verstuur je raw packets, er is dus weinig IPv6 of encapsulatie aan de pakketjes die hping3 aan 't versturen is. Of ik nou protocol 111 (random) of 41 gebruik, nagenoeg dezelfde packets worden verstuurd.

De ruwe pakketjes van hping3 komen dus wel gewoon goed aan, maar omdat ze vervolgens invalid zijn - ze voldoen niet aan rfc2473 - discard de kernel deze packets gewoon.

[Raven]

Dus het zou heel goed kunnen dat er gewoon niks geblokkeerd wordt en dat ik hping3 niet helemaal goed gebruik?

[Freeaqingme]

Raven schreef op donderdag 19 september 2013 @ 20:29:
Dus het zou heel goed kunnen dat er gewoon niks geblokkeerd wordt en dat ik hping3 niet helemaal goed gebruik?

Dat zou ik denken. Of zelfs wel goed gebruikt, maar enkel de resultaten verkeerd interpreteert

Ik heb overigens nog nooit proto 41 geblokkeerd zien worden, ook niet op de meest gare adsl thompson routers.

[Raven]

pfSense blokkeerde het toen ik het gebruikte. Máár er was in de betreffende versie (v1.2.3 van 2009) wél een vinkje te vinden om dat soort verkeer toe te staan.

Zojuist maar even mijn FEL-VM opgestart en geprobeerd de tunnel daar op te zetten...... Ik zie een bewegende schildpad op kame.net Wel Google voor moeten gebruiken, Fedora staat niet in het lijstje met besturingssystemen bij de configuratie-info op tunnelbroker.net
edit: Gelijk daar maar een verzoek ingediend info om Fedora erbij te vermelden.

[ Voor 25% gewijzigd door Raven op 19-09-2013 21:05 ]

[MORCIK]

Hebben jullie ook de indruk dat SixXS de maximale snelheid verhoogd heeft van 80 naar 100 Mbit/s? Als ik over Ipv6 van ftp.surfnet.nl download gaat dit met c.a. 12,5 MByte/s. Benchmark is ook een stuk hoger dan ruim een maand geleden:

[Verwijderd]

Kan iemand mij aub helpen?

Ik moet een stateless auto configuratie (SLAAC) hebben met dynamische dns. De hosts moeten zichzelf automatisch resolven maar hiermee zit ik vast.

Wat ik heb:
Ik heb een router die aan router advertising (RA) doet. Aan de hand van deze bepalen de hosts (linux client1, linux client2, windows client1, windows client2, ....) hun eigen ip adres. Dan zijn er 2 linux servers (server1 = dhcpv6, die alleen de adres van dns meegeeft aan hosts) en server2 = dns.

Omdat hosts hun ip zelf bepalen, door ofwel mac achter de prefix van router advertisements te plakken ofwel door privacy extensions, weten de servers niet welke host welke ip heeft. Wat ik wil doen is deze hosts automatisch hun ip en naam doorgeven aan dns server. Dus automatisch zichzelf resolven. Ik wil dit niet statisch ingeven (gaat ook, werkt ook maar is niet de bedoeling) omdat er privacy extensions er toegepast moet worden. Dat betekent dat er elke keer een andere ip wordt gekozen. En dit elke keer statisch ingeven is niet doenbaar.

Alle hulp is welkom en alvast bedankt!!

[CAPSLOCK2000]

Kijk eens naar de tool 'nsupdate' en zoek naar 'dynamic dns'. Eerlijk gezegd denk ik dat die privacy-extensions een probleem gaan worden. Je zal zelf moeten bepalen wanneer je ip verandert en dan nsupdate aanroepen.

[Verwijderd]

Dan moet je altijd nsupdate doen van de hostkant wanneer er een toestel ip heeft. Is toch ook niet doenbaar als je veel toestellen hebt?

[CAPSLOCK2000]

Dat is toch precies wat je vroeg?
Als je niks wil updaten kun je nog mdns gebruiken maar dat werkt alleen binnen je lokale netwerk.

[FatalError]

Ik heb een klein irritant probleempje onder Windows 7 met IPv6 en Privacy Extensions (staat standaard aan). Volgens mij is het volgende aan de hand:
Standaard pakken programma's het PE adres voor uitgaande verbindingen. Bij verbindingen die lang open blijven staan (zoals een IRC sessie) valt na een bepaalde tijd de verbinding weg omdat het PE adres wijzigt.
Is er een manier om te zorgen dat programma's niet het PE adres pakken, maar het vaste IPv6 adres?
In MIRC zelf kan je dit niet configureren, ik kan het in ieder geval niet vinden. Maar misschien is er een manier om vanuit windows dit te regelen.
Ik wil liever niet de Privacy Extensions uitzetten.

[databeestje]

Ik heb een bijzondere ontdekking gedaan met betrekking tot Netflix. Thuis heb ik een HE.net tunnel voor mijn IPv6.

Nou had ik de rare situatie dat met de Netflix App op mijn Tablet/Telefoon ik andere content kreeg dan op de PC en Mac. Dat wil zeggen, ik krijg op de PC/Mac het Amerikaanse aanbod (hallo Breaking Bad).

Nou heb ik ontdekt dat als ik naar de netflix website ga op het tablet in plaats van de App ik ook de Amerikaanse store krijg. Misschien interresant om te weten. Dual Stack ftw.

[Verwijderd]

Wat ik wil is eigenlijk als een host een ip heeft, dat die zichzelf automatisch in dns zet. Met nsupdate is dit nog altijd manueel en als je met privacy extensions werkt moet dit elke keer wanneer men een nieuwe ip heeft.

[CAPSLOCK2000]

Naast nsupdate zijn er nog tientallen andere tools voor dynamische dns. Ik denk niet of je er een gaat vinden die met privacy-extensions overweg kan, maar wie weet.

[Zsub]

CAPSLOCK2000 schreef op dinsdag 24 september 2013 @ 13:49:
Naast nsupdate zijn er nog tientallen andere tools voor dynamische dns. Ik denk niet of je er een gaat vinden die met privacy-extensions overweg kan, maar wie weet.

Kan je niet zowel een PE als vast IPv6 geven?

[CAPSLOCK2000]

Het is me ook niet helemaal duidelijk wat de gebruiker wil bereiken.
Een vaste DNS-naam en privacy-extensions lijken het tegenovergestelde doel te hebben. Ik vermoed dat het de bedoeling is om lokaal DNS te kunnen gebruiken maar verbindingen naar de buitenwereld met PE te maken.

[Freeaqingme]

Als dat het doel is zou ik intern ULA gebruiken en daar de DNS naar laten verwijzen, en dan voor al het externe verkeer PE gebruiken.

[CyBeR]

Verwijderd schreef op dinsdag 24 september 2013 @ 12:16:
Wat ik wil is eigenlijk als een host een ip heeft, dat die zichzelf automatisch in dns zet. Met nsupdate is dit nog altijd manueel en als je met privacy extensions werkt moet dit elke keer wanneer men een nieuwe ip heeft.

PE en (forward) dns gaat niet echt samen, wat is je doel?

[Verwijderd]

Ik heb een netwerk waar meer dan 100 vaste pc's maar ook laptops (gasten) en smartphones (gasten) moeten kunnen verbinden. Deze netwerk draait nog op ipv4. Maar men wil dit volledig overschakelen naar ipv6 (geen dual stack dus). Als men mac gebruikt voor achter de prefix, wordt dit een security issue (vooral voor windows dan). Daarom het gebruik van privacy extensions. Omdat door privacy extensions ip's altijd veranderen kan ik het niet statisch ingeven in dns. Dit moet automatisch gebeuren. (met automatisch bedoel ik dan niet dat je elke keer een tool moet uitvoeren bij een nieuwe client). In theorie gaat dit, maar hoe is de vraag?

[CyBeR]

Hoe is het gebruik van SLAAC met EUI-64 een security issue precies?

[CAPSLOCK2000]

Meerdere adressen per host lijkt mij de juist oplossing. Eventueel alles via DHCPv6 regelen?

Hoe heb je het onder IPv4 geregeld, NAT?

[Keiichi]

Google heeft 2% IPv6 traffic.

http://www.internetsociet...the-internet-is-changing/

De grafiek van google zelf gaat ook gewoon de goede kant op: http://www.google.com/intl/en/ipv6/statistics.html

[Verwijderd]

CyBeR schreef op dinsdag 24 september 2013 @ 21:15:
Hoe is het gebruik van SLAAC met EUI-64 een security issue precies?

Mac adres van host staat in ip , is mac spoofing dan geen security issue?

[Orion84]

Verwijderd schreef op woensdag 25 september 2013 @ 09:25:
[...]
Mac adres van host staat in ip , is mac spoofing dan geen security issue?

MAC spoofing kan een security issue zijn, de vraag is op welke manier het vermelden van het MAC adres in het IP bijdraagt aan MAC spoofing? Op het lokale netwerk maakt het geen verschil, daar was het MAC adres immers toch al zichtbaar in de netwerkpakketjes. Buiten het lokale netwerk is MAC spoofing dan weer een stuk minder interessant lijkt me?

[Snow_King]

CyBeR schreef op dinsdag 24 september 2013 @ 21:15:
Hoe is het gebruik van SLAAC met EUI-64 een security issue precies?

Als je het MAC adres kent zou je het IPv6 adres kunnen raden als iemand ergens remote zit.

Ik zie het écht grote probleem niet, want iedereen mag van mij het IPv6 van mijn desktop hebben, die moet gewoon goed dicht zitten.

Jezelf verstoppen zie ik als "security through obsecurity"

[CyBeR]

Verwijderd schreef op woensdag 25 september 2013 @ 09:25:
[...]


Mac adres van host staat in ip , is mac spoofing dan geen security issue?

Hoe is dat bij IPv6 wel, en bij IPv4 waar je met één simpele ARP-query achter het MAC-adres komt, geen issue dan?

Ik denk dat je beren ziet op een weg die niet eens bestaat.

[Verwijderd]

Ik vroeg het gewoon eh, ik ben ook in leerproces. Ik zoek gewoon een manier om ipv6 te configureren zoals ipv4 dat alles dan werkt (voor dns dan). Ik wil niet bij elke nieuwe hosts een script of een tool uitvoeren.