Het grote IPv6 topic

[tcviper]

Nou, de Cisco RV3x series (SMB range) Doet het prima by default

[databeestje]

Hipska schreef op donderdag 22 januari 2015 @ 11:22:
[...]


Dat is de eerste keer dat ik dit op die manier hoor. Lijkt me ook goed en logisch en beter dan telkens opnieuw PAT te doen.

Dit wil ik wel eens testen op een Linux host (Raspberry, VM). Hoe ga ik dan te werk zodat het even automagisch werkt als die router van de MediaMarkt?

Niet zo heel erg moeilijk, ik heb het onder pfSense als volgt geimplementeerd.

Vanuit de DHCP-PD van de ISP (/56 of groter), pak ik dan de hoogste /60 bij een /56, of een /52 bij een /48.

Ik maak dan op de DCHP6 server op de router een DHCP-PD delegatie, uit deze /60 of /52 deel ik dan /64 of /56 netwerken uit. Op die manier kunnen dus respectievelijk 4 en 8 onderliggende mediamarkt routers aangesloten worden.

Wel is het zaak dat er automatisch routes in de route tabel van de router geplaatst worden zodat deze naar de DHCP-PD delegatie gaan. Daar is in pfSense een apart script voor gemaakt die dit regelt aan de hand van de ISC dhcpd6.leases file.

In de laatste variant (/48 van de ISP) zou er dus nog een keer gedelegeerd kunnen worden.

Met andere woorden, elke DHCP6 client die dan een prefix vraagt krijgt dus zijn eigen delegatie. Dat is precies wat de meeste consumenten routers standaard doen op de ethernet poort.

d--amo schreef op donderdag 22 januari 2015 @ 13:02:
Wat is de ervaring met de doorsnee consumentenrouters, zoals D-Link, TP-Link, Linksys ed mbt tot IPv6?
Wat is daar vaak de default config? Doen zulke routers (default) goed aan prefix delegation?

Ik zou verwachten dat ze default vaak DHCPv6 hebben aanstaan op de WAN, maar dan geen PD. In de meeste gevallen zal er dus een config aanpassing nodig zijn als de ISP DHCPv6 en PD gebruikt. Of heb ik dat fout?

Op de Draytek Vigor 2850/2860 moet expliciet DHCP6 op de WAN aangezet worden, tevens moet hier expliciet een PD aanvraag gedaan worden voor delegatie op het LAN.

Net even in de Draytek 2850 DHCP6 settings gegeken, maar deze heeft alleen uit/aan, start en end, LAN IP6 address. Er is dus geen instelling om DHCP6-PD op het LAN te doen. Slecht!

[ Voor 24% gewijzigd door databeestje op 22-01-2015 13:22 ]

[d--amo]

databeestje schreef op donderdag 22 januari 2015 @ 13:17:
[...]

Niet zo heel erg moeilijk, ik heb het onder pfSense als volgt geimplementeerd.

Vanuit de DHCP-PD van de ISP (/56 of groter), pak ik dan de hoogste /60 bij een /56, of een /52 bij een /48.

Ik maak dan op de DCHP6 server op de router een DHCP-PD delegatie, uit deze /60 of /52 deel ik dan /64 of /56 netwerken uit. Op die manier kunnen dus respectievelijk 4 en 8 onderliggende mediamarkt routers aangesloten worden.

Wel is het zaak dat er automatisch routes in de route tabel van de router geplaatst worden zodat deze naar de DHCP-PD delegatie gaan. Daar is in pfSense een apart script voor gemaakt die dit regelt aan de hand van de ISC dhcpd6.leases file.

In de laatste variant (/48 van de ISP) zou er dus nog een keer gedelegeerd kunnen worden.

Met andere woorden, elke DHCP6 client die dan een prefix vraagt krijgt dus zijn eigen delegatie. Dat is precies wat de meeste consumenten routers standaard doen op de ethernet poort.

Dat is een implementatie van hiërarchische PD? Dat is mooi, welnog niet gestandaardiseerd dacht ik. Of is dit niet helemaal hetzelfde?
Dat ga ik thuis alleszins ook eens testen!

databeestje schreef op donderdag 22 januari 2015 @ 13:17:

Op de Draytek Vigor 2850/2860 moet expliciet DHCP6 op de WAN aangezet worden, tevens moet hier expliciet een PD aanvraag gedaan worden voor delegatie op het LAN.

Net even in de Draytek 2850 DHCP6 settings gegeken, maar deze heeft alleen uit/aan, start en end, LAN IP6 address. Er is dus geen instelling om DHCP6-PD op het LAN te doen. Slecht!

Die Draytek kan dus wel een PD aanvragen via DHCPv6, maar kan deze vervolgens niet gebruiken op het LAN? Of zal hij automatisch prefixen gaan kiezen en toewijzen aan het LAN?

Of heb je het hier ook over hiërarchische PD? Hij kan de prefixen wel gebruiken op het LAN, maar kan er zelf geen meer delegeren naar andere routers?

EDIT: Even herlezen, ik neem aan dat je het laatste bedoelt

[databeestje]

Je hebt het helemaal goed begrepen, hiërarchische is een ding, dat zou eigenlijk beter uitgelicht moeten worden. Het gaat hier niet om hoeveel randapparatuur je wel of niet aan zou kunnen sluiten, dat is nimmer het probleem met 2^64 adressen.

Het probleem dat hiermee opgelost wordt is dat IPv6 werking gegarandeerd wordt met 3e partij apparatuur, waar de ISP dus ook niet perse aan hoeft te ondersteunen. Het geeft tevens keuze aan de klant om het rond uit brakke Wifi van de Ubee op te lossen zonder enige kennis en toch knap internet zonder dubbele NAT44 *met* uPNP/Rendezvous/Avahi ondersteuning. (dwz, de meeste mensen pluggen de mediamarkt router achter de bestaande Kabelmodem/router waardoor ze uPNP op dit modem verliezen op dit "nieuwe" LAN)

Edit: Als je toch de vraag hebt over technische kennis mbt instellen, hoeveel mensen weten hoe ze op IPv4 een wifi router kunnen gebruiken als alleen een wifi accesspoint (deactiveren dhcp server, IP adres in zelfde range instellen)

[ Voor 13% gewijzigd door databeestje op 22-01-2015 21:51 ]

[Hipska]

databeestje schreef op donderdag 22 januari 2015 @ 21:21:
Je hebt het helemaal goed begrepen, hiërarchische is een ding, dat zou eigenlijk beter uitgelicht moeten worden. Het gaat hier niet om hoeveel randapparatuur je wel of niet aan zou kunnen sluiten, dat is nimmer het probleem met 2^64 adressen.

Inderdaad, mijn ogen zijn nu ook open gegaan voor deze invalshoek. Nog een argument erbij waarom het voor Jan met de pet beter is dan IPv4 Thanks!

[databeestje]

Point in case, net een D-Link DIR810L uit de outlet store van Informatique gehaald en firmware 1.0.2 erop gezet. Deze heeft IPv6 op "autodetect" staan, en wat blijkt, het werkt gewoon in 1 keer.

Mijn pfSense alloceert een een DHCP-PD voor deze "mediamarkt" router (uit mijn /48 HE.net prefix) en zo heeft mij Macbook zonder enige hulp een IPv6 adres gekregen. Daarom moet DHCP-PD doorgegeven worden zodat de keten werkt.

Een 10/10 op test-ipv6.com

code:

IPv6 Connection Information
IPv6 Connection Type :    Auto Configuration (SLAAC/DHCPv6)
Network Status :      Connected
Connection Up Time :      0 Day, 0:06:06
     
 
WAN IPv6 Address :  
  2001:470:d72c::d81/128
  2001:470:d72c:0:c2a0:bbff:feeb:df60/64
IPv6 Default Gateway :    fe80::20d:b9ff:fe1b:b36c
LAN IPv6 Address :    2001:470:d72c:4f01:c2a0:bbff:feeb:df5f/64
LAN IPv6 Link-Local Address :     fe80::c2a0:bbff:feeb:df5f/64
Primary DNS Address :     2001:4860:4860::8844
Secondary DNS Address :       2001:4860:4860::8888
DHCP-PD :     Enabled
IPv6 Network assigned by DHCP-PD :    2001:470:d72c:4f00::/56

[Jerrythafast]

Het wegvallen van Facebook vanmorgen heeft voor een flinke dip in IPv6 verkeer op AMS-IX gezorgd! Zie de AMS-IX IPv6 traffic stats van vandaag.

[CAPSLOCK2000]

Grappig om te zien. Blijkbaar is heel Nederland het nu aan het inhalen want het gaat vanavond erg hard, misschien wel een record.

[Maasluip]

Ik denk het wel. Op de hourly, daily en monthly grafieken van de ether type distributie is nu het oranje streepje twee pixels hoog.
Jammer dat je niet meer de logarithmische schaal kan zien.

[CAPSLOCK2000]

Dat kan nog steeds, je moet alleen de URL handmatig aanpassen en 'scale=normal' vervangen door 'scale=log':
https://stats.ams-ix.net/...;scale=log;interval=daily

Mijn huidige vermoeden is dat de piek van vanavond is veroorzaakt door de GHOST bug. Linux-gebruikers en distributies zitten bovengemiddeld veel op IPv6 en de hele Linux wereld is nu druk aan het patchen.

[ Voor 43% gewijzigd door CAPSLOCK2000 op 28-01-2015 02:19 ]

[Verwijderd]

CAPSLOCK2000 schreef op woensdag 28 januari 2015 @ 02:16:
Dat kan nog steeds, je moet alleen de URL handmatig aanpassen en 'scale=normal' vervangen door 'scale=log':
https://stats.ams-ix.net/...;scale=log;interval=daily

Mijn huidige vermoeden is dat de piek van vanavond is veroorzaakt door de GHOST bug. Linux-gebruikers en distributies zitten bovengemiddeld veel op IPv6 en de hele Linux wereld is nu druk aan het patchen.

Terwijl ik toch zag dat een aantal patches (centos 6 en 7) pas later (na 00:00) gedistribueerd werden. Maar ik denk ook wel dat dat het is, zeker dat een hoop mensen niet alleen de glibc updaten maar ook overige updates gelijk meedraaien.

Centos 5 kwam al wat eerder uit, laten we het dan maar hopen want dan zouden er in iedergeval een hoop machines snel gepatched zijn om dit niet te laten uitmonden in een groot probleem.

[ Voor 10% gewijzigd door Verwijderd op 28-01-2015 06:55 ]

[Hipska]

Dit is wel interessant: https://fosdem.org/2015/news/2015-01-31-ipv6-only-again/
Jammer dat ik er niet bij was.

[CAPSLOCK2000]

Goed bezig daar. Zeker omdat ze daar een berg developers hebben die zo geconfronteerd worden met de bugs in hun eigen software

Nu nog een ipv6-only netwerk zonder NAT64.

[Snow_King]

Hipska schreef op maandag 02 februari 2015 @ 10:03:
Dit is wel interessant: https://fosdem.org/2015/news/2015-01-31-ipv6-only-again/
Jammer dat ik er niet bij was.

Heel goed! Even iedereen met neus op de feiten drukken.

Ook té veel developers zijn nog in IPv4-only-modus en snappen maar niets van IPv6. Veel denken ook dat het er nooit gaat komen of schuiven het op de "future" map.

[Hipska]

Vorig jaar waren er door die actie blijkbaar heel wat tickets en bugreports voor Android.

[d--amo]

databeestje schreef op donderdag 22 januari 2015 @ 13:17:
[...]
Ik maak dan op de DCHP6 server op de router een DHCP-PD delegatie, uit deze /60 of /52 deel ik dan /64 of /56 netwerken uit. Op die manier kunnen dus respectievelijk 4 en 8 onderliggende mediamarkt routers aangesloten worden.

Hoe kom je hierbij?

Lijkt me dat je uit een /60, 16 /64 prefixen kan uitdelen? Of bedoel je het anders?

Ik neem aan dat je die PD-pool op je PfSense static aanmaakt?
Net even getest op cisco, er lijkt niet direct een manier te zijn om dit dynamisch te doen.. Dus een PD-pool maken uit een prefix die je net zelf gedelegeerd hebt gekregen.

[Osiris]

Hipska schreef op maandag 02 februari 2015 @ 21:37:
Vorig jaar waren er door die actie blijkbaar heel wat tickets en bugreports voor Android.

Sinds wanneer doet Google iets met tickets en bug reports?

[databeestje]

d--amo schreef op dinsdag 03 februari 2015 @ 22:53:
[...]


Hoe kom je hierbij?

Lijkt me dat je uit een /60, 16 /64 prefixen kan uitdelen? Of bedoel je het anders?

4 bits is 16, klopt, maar ...

Als de ISP een /60 allocatie stuurt kan je vrijwel alleen nog maar /64 netwerken uitdelen, valt iets voor te zeggen, maar moet je wel zorgen dat je geen al gebruikt netwerk in de PD server hebt zitten. Vandaar dat ik dan weer een deel daarvan "reserveer" voor PD. Feitelijk 9-f, de rest is voor "eigen" gebruik.

Echter, automatisch gegenereerd is het iets lastiger uiteraard, de "mooie" lage netwerken gebruik ik niet voor delegatie, dus werk ik vanaf ff terug met (ongeveer) een 1/4 van de oorspronkelijke allocatie.

Ik neem aan dat je die PD-pool op je PfSense static aanmaakt?
Net even getest op cisco, er lijkt niet direct een manier te zijn om dit dynamisch te doen.. Dus een PD-pool maken uit een prefix die je net zelf gedelegeerd hebt gekregen.

Nee de PD pool wordt automatische gegenereerd aan de hand van de grote van de ISP allocatie. Dat de Cisco dat niet kan verbaast me niets, dat is niet mijn leidraad geweest.

Nu is deze thuis wel statisch ivm met de HE.net tunnel, echter hebben we al verschillende rapporten van mensen die dit gebruiken in combinatie met een ISP dhcp-pd. In Vmware heb ik dit ook zo getest.

[Hipska]

Osiris schreef op dinsdag 03 februari 2015 @ 23:42:
[...]

Sinds wanneer doet Google iets met tickets en bug reports?

Haha ja, ik wist niet dat het zo erg was, maar ik heb ook niet gezegd dat ze al opgelost waren he.

Blijkbaar kan Android niet op een wifi netwerk aanmelden als er geen IPv4 beschikbaar is. Hij maakt verbinding test connectiviteit en zegt dan geen verbinding mogelijk oid. Best jammer

[Verwijderd]

Hipska schreef op woensdag 04 februari 2015 @ 09:06:
[...]

Haha ja, ik wist niet dat het zo erg was, maar ik heb ook niet gezegd dat ze al opgelost waren he.

Blijkbaar kan Android niet op een wifi netwerk aanmelden als er geen IPv4 beschikbaar is. Hij maakt verbinding test connectiviteit en zegt dan geen verbinding mogelijk oid. Best jammer

Ik dacht dat het wel kan met versie 4.4 en hoger, omdat er dan een xlat464 service draait die IPv4 verkeer over 6 kan tunnelen maar dit moet je provider ook ondersteunen (nat64 + dns64). In de USA gebeurd dit op grote schaal.

[Hipska]

Op grote schaal op Mobile ISP niveau, maar niet op WiFi netwerken, en daar ging het hem nu net om...

[Snow_King]

Iemand al opgemerkt dat de NOS ineens via IPv6 bereikbaar is?

code:

www.nos.nl is an alias for nos.nl.
nos.nl has address 145.58.28.175
nos.nl has IPv6 address 2a02:458:101:28:100:28:0:af
nos.nl mail is handled by 15 mx1.mail.omroep.nl.
nos.nl mail is handled by 15 mx2.mail.omroep.nl.
nos.nl mail is handled by 25 mx3.mail.omroep.nl.
nos.nl mail is handled by 15 mx0.mail.omroep.nl.

Zelfde gaat ook op voor duo.nl bijvoorbeeld:

code:

www.duo.nl has address 194.171.77.135
www.duo.nl has IPv6 address 2001:67c:262c:860::135

Stap de goede kant op!

[ Voor 15% gewijzigd door Snow_King op 08-02-2015 20:28 ]

[Raven]

http://www.rijksoverheid.nl/ lijkt ook IPv6 te ondersteunen

Nu Tweakers nog, als de ICT-afdeling van de overheid het al voor elkaar kan krijgen....

[ Voor 41% gewijzigd door Raven op 08-02-2015 20:50 ]

[databeestje]

Snow_King schreef op zondag 08 februari 2015 @ 20:27:
Iemand al opgemerkt dat de NOS ineens via IPv6 bereikbaar is?

code:

www.nos.nl is an alias for nos.nl.
nos.nl has address 145.58.28.175
nos.nl has IPv6 address 2a02:458:101:28:100:28:0:af
nos.nl mail is handled by 15 mx1.mail.omroep.nl.
nos.nl mail is handled by 15 mx2.mail.omroep.nl.
nos.nl mail is handled by 25 mx3.mail.omroep.nl.
nos.nl mail is handled by 15 mx0.mail.omroep.nl.

Zelfde gaat ook op voor duo.nl bijvoorbeeld:

code:

www.duo.nl has address 194.171.77.135
www.duo.nl has IPv6 address 2001:67c:262c:860::135

Stap de goede kant op!

Onbewust wel, ik lag thuis ziek in bed dit weekend en de laptop gaaf ineens 6 aan met de chrome plugin toen ik het nieuws keek. Ik wist alleen niet voor hoe lang dat al was

De videos en alles werkte verder prima iig. (HE.net tunnel via pfSense op Ziggo)

Edit:

In ander nieuws, het CBS heeft hun Juniper NAT 46 uit dienst genomen, misschien zullen mijn klachten via de belangenvereniging hier iets aan bijgedragen hebben. Nu is de vraag wanneer ze dan wel weer IPv6 gaan ondersteunen. De oorspronkelijke uitrol was iets geforceerd afgedwongen vanuit de overheid, daarom ook de keuze voor de Juniper NAT ipv dual stack reverse proxy.
Herstel, mxtoolbox.com is stom en ondersteunt geen IPv6

[ Voor 18% gewijzigd door databeestje op 08-02-2015 21:34 ]

[Verwijderd]

Volgens mij is de NOS al een tijdje IPv6, echter niet streaming content helaas.

[tweegroenethee]

Goedemorgen mannen,

Hierbij meld ik mij aan bij het IPv6 topic. Ik ben als stagiaire aangenomen bij een klein bedrijf (verdeelt over 4 locaties) om IPv6 uit rollen over het netwerk. Ik heb ondertussen 2 Cisco certificaten weten te behalen op school, maar helaas niks over IPv6 (te lastig denk ik).

De startpost heeft mij goed op weg geholpen. De locaties in het bedrijf zijn via VPNs verbonden met elkaar. Heeft iemand een handige start guide om mij op weg te helpen met de uitrol van IPv6 in een bedrijfsnetwerk als deze?

[Snow_King]

Daan87423 schreef op maandag 09 februari 2015 @ 10:53:
Goedemorgen mannen,

Hierbij meld ik mij aan bij het IPv6 topic. Ik ben als stagiaire aangenomen bij een klein bedrijf (verdeelt over 4 locaties) om IPv6 uit rollen over het netwerk. Ik heb ondertussen 2 Cisco certificaten weten te behalen op school, maar helaas niks over IPv6 (te lastig denk ik).

De startpost heeft mij goed op weg geholpen. De locaties in het bedrijf zijn via VPNs verbonden met elkaar. Heeft iemand een handige start guide om mij op weg te helpen met de uitrol van IPv6 in een bedrijfsnetwerk als deze?

De VPN kan je de deur uit gooien Als alle 4 de locaties van hun ISP gewoon een /48 IPv6 krijgen kunnen alle apparaten elkaar direct benaderen.

Via ACL's op de routers kan je instellen wie elkaar mag benaderen.

IPSec is een onderdeel van IPv6, maar niet altijd even goed geïmplementeerd in alle routers, maar die zouden nog encryptie van het onderliggende verkeer kunnen doen.

Het mooie aan IPv6 is dat het allemaal publieke adressen zijn. VPN's en poortjes forwarden zijn niet meer nodig.

[tweegroenethee]

Snow_King schreef op maandag 09 februari 2015 @ 11:05:
[...]

De VPN kan je de deur uit gooien Als alle 4 de locaties van hun ISP gewoon een /48 IPv6 krijgen kunnen alle apparaten elkaar direct benaderen.

Dat is erg handig, blijkbaar waren hier altijd al problemen mee.

Hoe zit het met de conversie van een IPv4 host naar een IPv6 webserver? De klanten gebruiken namelijk allemaal nog IPv4, terwijl de webservers dan een IPv6 adres zouden hebben. Levert dit problemen op?

[Osiris]

Ik neem aan dat die webservers ook hun IPv4-adressen zullen behouden. En over het algemeen geeft dat geen problemen. Veel grote zaken als Google/Facebook draaien dualstack, dus de clients komen snel genoeg in de problemen als client-side dualstack-support niet fatsoenlijk werkt

[Miepermans]

Ter Info,

IPv6 via VPN gaat wel gewoon en blijft voor de meeste bedrijven de juiste en veilige manier van werken. ( sommige dingen wil je niet over het public ip forwarden ).

Er kan net zoals met IPv4 gewoon een route gezet worden door de tunnel heen om zo de verkeersstromen buiten internet om te routeren. Dit is zelfs een zeer gebruikelijke methode.

[Snow_King]

Miepermans schreef op maandag 09 februari 2015 @ 12:50:
Ter Info,

IPv6 via VPN gaat wel gewoon en blijft voor de meeste bedrijven de juiste en veilige manier van werken. ( sommige dingen wil je niet over het public ip forwarden ).

Er kan net zoals met IPv4 gewoon een route gezet worden door de tunnel heen om zo de verkeersstromen buiten internet om te routeren. Dit is zelfs een zeer gebruikelijke methode.

Waarom zou je IPv6 over een aparte VPN gaan sturen? Je gebruikt gewoon de publieke adressen en met ACL's geef je aan welke subnets waar bij komen.

Encryptie kan je met IPSec gewoon regelen.

[Miepermans]

Snow_King schreef op maandag 09 februari 2015 @ 13:03:
[...]

Waarom zou je IPv6 over een aparte VPN gaan sturen? Je gebruikt gewoon de publieke adressen en met ACL's geef je aan welke subnets waar bij komen.

Encryptie kan je met IPSec gewoon regelen.

En IPSec is wat vele mensen noemen een VPN

Ik wilde er niet al te diep op ingaan.

[Snow_King]

Miepermans schreef op maandag 09 februari 2015 @ 13:12:
[...]


En IPSec is wat vele mensen noemen een VPN

Ik wilde er niet al te diep op ingaan.

Duidelijk. Maar je kan gewoon je publiek routeerbare adressen gebruiken en op de ondergrond de encryptie laten plaats vinden.

Je gaat dan nooit dubbele subnets of 'private' adressen krijgen. De routers doen gewoon de de/encryptie van het verkeer.

[tweegroenethee]

Snow_King schreef op maandag 09 februari 2015 @ 13:16:
[...]

Duidelijk. Maar je kan gewoon je publiek routeerbare adressen gebruiken en op de ondergrond de encryptie laten plaats vinden.

Je gaat dan nooit dubbele subnets of 'private' adressen krijgen. De routers doen gewoon de de/encryptie van het verkeer.

Dus je dient van de provider een IPv6 adres range te krijgen? Met dat adres kan je vervolgens met 16 bits subnetten. Elke host zal dus een publiek IP adres krijgen die altijd(?) vanaf buitenaf benaderbaar is. Geen gedoe met NAT meer dus?

[Miepermans]

Daan87423 schreef op maandag 09 februari 2015 @ 14:35:
[...]

Dus je dient van de provider een IPv6 adres range te krijgen? Met dat adres kan je vervolgens met 16 bits subnetten. Elke host zal dus een publiek IP adres krijgen die altijd(?) vanaf buitenaf benaderbaar is. Geen gedoe met NAT meer dus?

Optioneel, je kan er altijd een firewall tussen zetten he .

Maar je snapt in ieder geval het ( voor ons ) belangrijkste doel van IPv6.. geen NAT meer

[tweegroenethee]

Miepermans schreef op maandag 09 februari 2015 @ 14:43:
[...]


Optioneel, je kan er altijd een firewall tussen zetten he .

Maar je snapt in ieder geval het ( voor ons ) belangrijkste doel van IPv6.. geen NAT meer

Een host krijgt dus 2 IPv6 adressen:

Een lokaal Link-Local IPv6 adres (fe80)
Een global IPv6 die je van de provider krijgt (2001)

Het Link local adres wordt gebruikt om binnen het lokale layer 2 netwerk (iedereen die aangesloten is op de switch) te communiceren. Het global adres wordt gebruikt om naar buiten te communiceren. Begrijp ik het zo goed?

[Miepermans]

Dat word inderdaad leuk met IPv6 dadelijk,

je hebt een fe80::/1 address, een lokaal geadverteerd addres, misschien nog een lokaal geadverteerd address ( dual WAN ) en 1 of meerdere privacy extension addressen

Laten we t maar erop houden dat de verkeersstroom altijd geinitieerd word vanaf de meest "interessante" interface, behalve als het binnen hetzelfde L2 domain zit ( dan is het meestal via de fe80 interface ).

[Snow_King]

Daan87423 schreef op maandag 09 februari 2015 @ 14:35:
[...]

Dus je dient van de provider een IPv6 adres range te krijgen? Met dat adres kan je vervolgens met 16 bits subnetten. Elke host zal dus een publiek IP adres krijgen die altijd(?) vanaf buitenaf benaderbaar is. Geen gedoe met NAT meer dus?

Ja, je krijgt vaak een /48 subnet, daar kan je zelf dan weer 65k aan /64 subnets mee uitdelen.

Vaak volstaat per kantoor één subnet, maar wij hebben op ons kantoor bijvoorbeeld:

* 1e subnet is desktops, laptops, medewerker WiFi
* 2e subnet is guest network
* 3e subnet is servers, printers

Via ACL's hebben we zo geregeld wie er wel en niet bij onze servers mag.

Op je andere locaties kan je dit ook weer regelen in de firewalls/routers. Kantoor X mag bij kantoor Y.

[databeestje]

In mijn situatie heb ik voor het bedrijf tussen 2 locaties wel degelijk IPsec VPNs met IPv6 gemaakt, dit om het onderlinge verkeer wat minder aftapbaar te maken. Oude gewoontes.

Wat niet wil zeggen dat er geen verkeer buiten de VPN tunnel om ging, dat scheelt gewoon heel veel snelheid en overhead. Iets met apps van 3e partijen die in een plain tekst wereld leven.

Op de IPv6 TF lijst had ik het als volgt samengevat.

Regel een IPv6 allocatie: Heb je een eigen ASN, geweldig, dan krijg je meteen een knappe eigen PI space van RIPE.
Je hebt PI space, en nu?
- Dual stack de BGP sessies
- Dual stack routers (je hoeft geen RA te doen, dit kan iBGP regelen of een ander intern routing protocol)
- Dual stack DNS servers (Gemakkelijk te realiseren zonder grote consequenties)
- Dual stack mail servers (kan je testen zonder dat iemand het echt in de gaten heeft, benodigd reverse DNS, zie boven)
- Dual stack de rest, web, load balancers, etc, zoals hierboven aangegeven, begin met de eigen website, die worden niet zo snel kwaad

Zelf gebruik ik vrijwel altijd pfSense, maar dat heeft meer met kosten te maken dan wat anders. De HA werkt goed genoeg, en is verder ook dual stack geschikt (genoeg).

Dingen die je wil voorkomen: Gebruik geen ULA address space, dit lijkt soms handig als je uit de huidige wereld komt maar gaat zo eindeloos veel problemen opleveren met source adres selectie dat het niet grappig is. Het wordt nog regelmatig voorgestelt, niet doen.

Zorg dat de Mobile vpn oplossing Dual Stack is, ik gebruik de Viscosity client in combinatie met de OpenVPN server in pfSense. Dan weet ik in ieder geval zeker dat zowel IPv4 en IPv6 via een publieke wifi hotspot versleuteld onze kant op komt. Het hangt van de onderneming en het gebruik af, maar je snap wat ik bedoel.

Nu is het wel zo dat de meeste servers Dual Stack zijn, inclusief de proxy servers, maar de desktops niet. Aangezien toegang via de proxy wordt afgedwongen is alles automatisch dual stack genoeg. Uiteraard zijn web, mail, dns etc wel dual stack.

Ik heb het niet ervaren als ingewikkeld om uit te rollen, het is best goed te doen. Neem wel een korte cursus in route aggregatie voor het maken van een nummer plan, dat maakt het op de lange termijn een end makkelijker. Zelf heb ik uit de /48 een /52 voor de site gepakt, waarbij de eerste /56 voor de LAN netwerken zijn en de 2e /56 uit de /52 voor de DMZ en WLAN netwerken. Hierdoor kan je makkelijker firewall rules maken en acls tussen onderliggende zones. Mijn netwerk is een paar lagen diep, waardoor deze hierarchie zich makkelijk laat opleggen.

[tweegroenethee]

databeestje schreef op maandag 09 februari 2015 @ 20:45:
[...]

Dank voor de reactie.

Hier in het bedrijf maken ze zich al zorgen als ze die 128 bits adressen zien. Nu is het heel simpel 192.168.1.10 pingen naar server 1, hoe hebben jullie dit geregeld? Ik neem aan dat alle IPv6 adressen met een AAAA record gekoppeld kunnen worden aan de server om op deze manier die server te pingen.

[Jaap-Jan]

Dat is wel de beste optie.

Als je ook onafhankelijk wil zijn van DNS kun je ook 'korte' IP- adressen instellen. Iets als 2001:1234:5678:90::10. Als ze dan hun eigen prefix weten (op te vragen met ipconfig), hoeven ze alleen maar het tweede (simpele) gedeelte van het adres te onthouden.

[CAPSLOCK2000]

Ik zet sowieso alles in DNS, maar dat deed ik met IPv4 ook al.
Voor de paar machines die zo belangrijk zijn dat ik ze ook zonder DNS wil kunnen vinden gebruik ik handig gekozen nummers.
bv
2001:xxxx:yyyy::80 -> webserver
2001:xxxx:yyyy::25 -> mailserver
2001:xxxx:yyyy::22 -> jumphost
2001:xxxx:yyyy::1 -> gateway
2001:xxxx:yyyy:: -> dnsserver

[tweegroenethee]

Jaap-Jan schreef op dinsdag 10 februari 2015 @ 09:56:
Dat is wel de beste optie.

Als je ook onafhankelijk wil zijn van DNS kun je ook 'korte' IP- adressen instellen. Iets als 2001:1234:5678:90::10. Als ze dan hun eigen prefix weten (op te vragen met ipconfig), hoeven ze alleen maar het tweede (simpele) gedeelte van het adres te onthouden.

Dat had ik ook al in gedachte inderdaad. Ik denk alleen dat er dan een probleem bij komt door link local adressen. Ze zullen dan om lokale servers te pingen fe80::10 moeten onthouden en op de andere locaties in Nederlands 2001:1234:5678:90::10. Of kan je lokaal ook gewoon de 2001::10 pingen?

[Ximon]

Even ervanuitgaande dat het bedrijf via de ISP danwel Sixxs oid een eigen IPv6 blok krijgt, waarom zou je dan uberhaupt fe80 adressen gebruiken? Deze adressen zijn niet via internet routeerbaar en dus ongeveer even nuttig als een 192.168.x.x adres lijkt me?

Ik kan het natuurlijk mis hebben, maar het verschil internet server/lokale server = internet IP/lokaal IP bestaat in de IPv6 wereld niet meer. Er zijn uiteraard nog wel firewalls en DMZs maar dat heeft niets met adressering te maken denk ik?

[ Voor 2% gewijzigd door Ximon op 10-02-2015 10:20 . Reden: spelling ]

[databeestje]

Daan87423 schreef op dinsdag 10 februari 2015 @ 09:35:
[...]

Dank voor de reactie.

Hier in het bedrijf maken ze zich al zorgen als ze die 128 bits adressen zien. Nu is het heel simpel 192.168.1.10 pingen naar server 1, hoe hebben jullie dit geregeld? Ik neem aan dat alle IPv6 adressen met een AAAA record gekoppeld kunnen worden aan de server om op deze manier die server te pingen.

Wat we hier doen is het laatste octet van het 4 adres gebruiken voor de 6 prefix. Hierdoor krijg je dus <prefix>:<lanid>::<hostoctet>.

Voor op het DMZ gebruiken we ::25 en ::25:25 voor de primair en secundaire mail server bijvoorbeeld. Ach, het is net wat past. Dat grote stuk in het midden vat je gewoon samen met ::

En zoals de anderen al opmerken, al die adressen staan in de DNS, niemand die ze ziet, maar ze worden wel gebruikt.

De Link local adressen hoef je niets mee te doen, dat kan je lekker laten gaan. Wat het wel mogelijk maakt is communicatie onderling zonder dat er een prefix is. Het maakt volledige TCP/IP communicatie mogelijk zonder organisatie. Het is een betere APIPA

Zo kan je onafhankelijk van wat de provider configureerd altijd met bijvoorbeeld de printer praten, al dan niet via rendezvous/Avahi/Bonjour (zo lang je op hetzelfde layer 2 zit)

[Snow_King]

Ximon schreef op dinsdag 10 februari 2015 @ 10:19:
Even ervanuitgaande dat het bedrijf via de ISP danwel Sixxs oid een eigen IPv6 blok krijgt, waarom zou je dan uberhaupt fe80 adressen gebruiken? Deze adressen zijn niet via internet routeerbaar en dus ongeveer even nuttig als een 192.168.x.x adres lijkt me?

Ik kan het natuurlijk mis hebben, maar het verschil internet server/lokale server = internet IP/lokaal IP bestaat in de IPv6 wereld niet meer. Er zijn uiteraard nog wel firewalls en DMZs maar dat heeft niets met adressering te maken denk ik?

Een IPv6 netwerk gebruikt voor de lokale communicatie altijd de link-local, fe80 addressen. Deze gebruik je als eindgebruiker niet, maar je netwerk gebruikt ze wel.

Net zoals dat je met IPv6 nooit ICMP moet blokkeren, want dan gaat de boel kapot.

[tweegroenethee]

databeestje schreef op dinsdag 10 februari 2015 @ 10:31:
De Link local adressen hoef je niets mee te doen, dat kan je lekker laten gaan. Wat het wel mogelijk maakt is communicatie onderling zonder dat er een prefix is. Het maakt volledige TCP/IP communicatie mogelijk zonder organisatie. Het is een betere APIPA

Zo kan je onafhankelijk van wat de provider configureerd altijd met bijvoorbeeld de printer praten, al dan niet via rendezvous/Avahi/Bonjour (zo lang je op hetzelfde layer 2 zit)

En hoe worden de printers dan ingesteld? Op basis van het Link local adres of het global adres?

Op dit moment zijn het netwerkprinters die met een 192.168.x.x adres worden toegevoegd aan werkstations. Onze netwerkbeheerder is momenteel niet aanwezig, maar ik neem aan dat de printers gewoon worden toegevoegd op de AD server. Vervolgens zien de werkstations ze staan bij het toevoegen van een printer.

[Ximon]

Ximon schreef op dinsdag 10 februari 2015 @ 10:19:
Even ervanuitgaande dat het bedrijf via de ISP danwel Sixxs oid een eigen IPv6 blok krijgt

Snow_King schreef op dinsdag 10 februari 2015 @ 10:43:
[...]

Een IPv6 netwerk gebruikt voor de lokale communicatie altijd de link-local, fe80 addressen. Deze gebruik je als eindgebruiker niet, maar je netwerk gebruikt ze wel.

...

Die snap ik even niet. Als je een 2001: adres op een host configureert is er geen fe80 adres meer nodig neem ik aan? Mocht je op dat LAN met fe80-hosts willen praten kan je beter een router toevoegen zou ik zeggen.

[Verwijderd]

Ook zou ik als je een IP plan maakt waarbij je bijvoorbeeld diensten en locatie verwerkt in een octet niet met de 0 beginnen, vaak wordt deze in de weergave van tools niet getoond en dan zit je wel eens raar te kijken.

Ik heb ongeveer zoiets
2001:4d10:AA11::1
rir:isp:DMZ locatie 11::gateway

Als je in een octet de weergave voor diensten voor de locatie notatie gebruikt (mocht je een dergelijke invulling wensen) dan kun je in de acl's en firewall's voor meerdere locaties tegelijk poorten openzetten voor bv een dienst (voip, dns, http). Anders moet je namelijk per locatie een set met rules bijhouden die in sommige situatie vaak identiek aan elkaar zijn.

Er zijn wel wat papers voor: https://www.surf.nl/kenni...nummerplan-opstellen.html

[Verwijderd]

Daan87423 schreef op dinsdag 10 februari 2015 @ 10:54:
[...]

En hoe worden de printers dan ingesteld? Op basis van het Link local adres of het global adres?

Op dit moment zijn het netwerkprinters die met een 192.168.x.x adres worden toegevoegd aan werkstations. Onze netwerkbeheerder is momenteel niet aanwezig, maar ik neem aan dat de printers gewoon worden toegevoegd op de AD server. Vervolgens zien de werkstations ze staan bij het toevoegen van een printer.

Via een router advertisement zouden ze gewoon een unicast adres moeten ontvangen, zakelijke printers hebben vaak ook nog de optie om zich te registreren bij een DNS server.

Ze hebben ook een link-local adres maar die is alleen in dat vlan bereikbaar.

Ik heb zo diverse printers uitgerolt en toen er werd gevraag waarom deze "global" bereikbaar moesten zijn had ik de situatie waar je normaliter nachtmerries van krijgt. Namelijk een leverancier die bij deze klant wilde kunnen printer echter zijn interne subnet nummering was gelijk aan die van deze klant.
Double nat

Met IPv6 was het zo gepiept, het werd namelijk een routing "issue" routing instellen, poortje openen, dns naampje aanmaken en dat was het.

[ Voor 3% gewijzigd door Verwijderd op 10-02-2015 11:04 ]

[Verwijderd]

Ximon schreef op dinsdag 10 februari 2015 @ 10:56:
Die snap ik even niet. Als je een 2001: adres op een host configureert is er geen fe80 adres meer nodig neem ik aan? Mocht je op dat LAN met fe80-hosts willen praten kan je beter een router toevoegen zou ik zeggen.

FE80 adressen worden niet gerouteerd, ook is het niet de bedoeling dat je op routers routes voor FE80 gaat aanmaken, dan krijg je wel hele rare situaties. Ik betwijfel zelfs of routers het zelfs zouden toestaan om dit in te voeren.

FE80 adressen zullen apparaten altijd hebben, dit zodat ze ge-discoverd kunnen worden en netwerk connectiviteit hebben in een netwerk waar ze geen router advertisement hebben ontvangen.

Stel je voor een apparaat wat je wilt configuren als test of om de interface te bekijken. Dan hang je deze vaak niet gelijk aan je netwerk maar even lokaal iets proberen. Discover tools of een FE80 adres op de doos of even met een packetsniffer kijken en je kan bij het apparaat.

Met routers kun je ook routeren zonder dat het koppelnetwerk een IP reeks krijgt, ze zien elkaar via de link op een uniek interface FE80 adres en kunnen zo gegevens uitwisselen. Voor management van de apparaten gebruik je mogelijk een andere interface / lan / subnet. Het hoeft natuurlijk niet maar het kan.

[Out.of.Control]

Verwijderd schreef op dinsdag 10 februari 2015 @ 11:11:
[...]
FE80 adressen worden niet gerouteerd, ook is het niet de bedoeling dat je op routers routes voor FE80 gaat aanmaken, dan krijg je wel hele rare situaties. Ik betwijfel zelfs of routers het zelfs zouden toestaan om dit in te voeren.

Dat dacht ik ook, maar sinds ik native IPv6 van XS4ALL gebruik (was eerst een Sixxs tunnel), krijg ik met enige regelmaat dit in de logs van mijn router:

cannot forward src fe80:9::216:3eff:fe0c:c3ce, dst 2001:****:****:4::10, nxt 17, rcvif pppoe0, outif em4

Het destination adres (dat ik heb bewerkt met *) is een NTP server die in de NTP-pool zit, dus op zich niet raar dat er verkeer voor dat IP binnenkomt. Maar een fe80 als source adres, dat vind ik wel vreemd. Blijkbaar wordt er dus niet overal gefilterd op fe80 als source adres.

[Ximon]

Verwijderd schreef op dinsdag 10 februari 2015 @ 11:11:
[...]


FE80 adressen worden niet gerouteerd, ook is het niet de bedoeling dat je op routers routes voor FE80 gaat aanmaken, dan krijg je wel hele rare situaties. Ik betwijfel zelfs of routers het zelfs zouden toestaan om dit in te voeren.

FE80 adressen zullen apparaten altijd hebben, dit zodat ze ge-discoverd kunnen worden en netwerk connectiviteit hebben in een netwerk waar ze geen router advertisement hebben ontvangen.

Stel je voor een apparaat wat je wilt configuren als test of om de interface te bekijken. Dan hang je deze vaak niet gelijk aan je netwerk maar even lokaal iets proberen. Discover tools of een FE80 adres op de doos of even met een packetsniffer kijken en je kan bij het apparaat.

Met routers kun je ook routeren zonder dat het koppelnetwerk een IP reeks krijgt, ze zien elkaar via de link op een uniek interface FE80 adres en kunnen zo gegevens uitwisselen. Voor management van de apparaten gebruik je mogelijk een andere interface / lan / subnet. Het hoeft natuurlijk niet maar het kan.

Makes sense. Voor de volledigheid:

quote: http://tools.ietf.org/html/rfc4291#section-2.5.6

code:

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

Dat had ik natuurlijk ook in eerste instantie kunnen opzoeken

[ Voor 0% gewijzigd door Ximon op 10-02-2015 12:26 . Reden: Opmaak ]

[Hipska]

databeestje schreef op maandag 09 februari 2015 @ 20:45:
Dingen die je wil voorkomen: Gebruik geen ULA address space, dit lijkt soms handig als je uit de huidige wereld komt maar gaat zo eindeloos veel problemen opleveren met source adres selectie dat het niet grappig is. Het wordt nog regelmatig voorgestelt, niet doen.

Kan je hier eens meer over uitweiden? Ik sta op het punt om binnen ons bedrijf IPv6 te testen en ik dacht er aan om hiervoor een Site Local adres range te gebruiken omdat we nog geen IPv6 verbinding hebben.

Verwijderd schreef op dinsdag 10 februari 2015 @ 10:58:
Als je in een octet de weergave voor diensten voor de locatie notatie gebruikt (mocht je een dergelijke invulling wensen) dan kun je in de acl's en firewall's voor meerdere locaties tegelijk poorten openzetten voor bv een dienst (voip, dns, http). Anders moet je namelijk per locatie een set met rules bijhouden die in sommige situatie vaak identiek aan elkaar zijn.

Er zijn wel wat papers voor: https://www.surf.nl/kenni...nummerplan-opstellen.html

Thanks, leest vlot en geeft duidelijke voorbeelden.

[Paul]

Hipska schreef op dinsdag 10 februari 2015 @ 17:43:
omdat we nog geen IPv6 verbinding hebben

Dat is wat mij ook tegenhoudt; ik kan al wel beginnen maar zodra we dan een verbinding hebben die wel IPv6 doet kunnen we weer alles om gaan nummeren. Idem wanneer we de huidige leverancier (om wat voor reden dan ook) de deur uit doen...

Hoe los je zoiets op? Want een andere internetleverancier is zo gevonden, het complete bedrijf omnummeren daarentegen...

[anboni]

Mijn gedachte daarbij is om voor intern gebruik een unique local range te pakken. Servers en andere statische dingen geef je handmatig een adres in die range en alleen publiek bereikbare dingen geef je statisch een adres in je publieke range. Verder gebruik je op je LAN dus alleen dynamisch uitgegeven publieke adressen. IPv6 is als het goed is dusdanig intelligent dat 'ie automatisch het meest geschikte bronadres pakt om een verbinding op te zetten.

[Maurits van Baerle]

Paul schreef op dinsdag 10 februari 2015 @ 18:00:
[...]
Dat is wat mij ook tegenhoudt; ik kan al wel beginnen maar zodra we dan een verbinding hebben die wel IPv6 doet kunnen we weer alles om gaan nummeren. Idem wanneer we de huidige leverancier (om wat voor reden dan ook) de deur uit doen...

Hoe los je zoiets op? Want een andere internetleverancier is zo gevonden, het complete bedrijf omnummeren daarentegen...

Je zou het lokale gedeelte van je adressen gewoon hetzelfde kunnen houden lijkt me. Als je van tunnel of ISP wisselt verandert alleen je prefix terwijl je eigen DHCP/DNS er voor zorgt dat je printer etc. hetzelfde laatste stuk van het adres houdt.

[databeestje]

Paul schreef op dinsdag 10 februari 2015 @ 18:00:
[...]
Dat is wat mij ook tegenhoudt; ik kan al wel beginnen maar zodra we dan een verbinding hebben die wel IPv6 doet kunnen we weer alles om gaan nummeren. Idem wanneer we de huidige leverancier (om wat voor reden dan ook) de deur uit doen...

Hoe los je zoiets op? Want een andere internetleverancier is zo gevonden, het complete bedrijf omnummeren daarentegen...

Als het bedrijf een knap formaatje heeft dan raad ik aan een Provider Independent IP space aan te vragen bij RIPE, dit hebben we voor het bedrijf gedaan wat ontzettend veel complicaties scheelt. Tenzij we plots uit de /48 groeien hoeven we nimmer om te nummeren.

Let wel, je hebt een ISP nodig die BGP met je wil doen, of, maak gebruik van de gratis HE.net BGP tunnel peering, dat hebben wij circa 2 jaar gebruikt naar volle tevredenheid.

De ULA adres ruimte is feitelijk hetzelfde als RFC1918 space gebruiken, maar dan zonder apparatuur die feitelijk NAT kan doen. Dat heet jezelf in de hoek verfen.
Het probleem hier is dat sommige apparaten wel een klein beetje IPv6 NAT kunnen doen, zoals NPt, maar dat verwacht software dan weer niet zoals SIP toestellen en dergelijke en dan ben je alsnog terug bij af.

Je kan met IPv6 wel meerdere adressen aan een enkel apparaat hangen, maar met wel adres gaat deze naar het internet communiceren? Er is een 50% kans dat het 100% de verkeerde is en het niet werkt.

Je gaat dan feitelijk de source adres selectie op apparaat niveau doen, veel succes daarmee in een grotere omgeving

[Verwijderd]

Wat ook nog een issue kan opleveren is dat je (windows) systemen al een IPv6 verbinding hebben, het zou niet voor het eerst zijn dat ik een teredo tunnel tegenkom op servers. Dit is dat een windows server over IPv4 een tunnel opbouwt voor IPv6 verkeer, waarbij de de firewall dus wordt omzeilt.

Je server wordt dus benaderbaar op een IPv6 adres zonder dat je dat weet of wenst. Ik heb het nu even niet bij de hand maar je zou in een group policy moeten aangeven dat je tunnel mechanismes zoas 6to4 en toredo (er is nog een derde meen ik) wilt disablen op je servers en clients. Let wel, niet IPv6 uitschakelen maar de tunnel mechanismes.

Op een enkele client: http://www.dickson.me.uk/...ap-and-6to4-in-windows-7/

[CAPSLOCK2000]

Ik zou geen "unique local" adressen gebruiken in productie, maar een beetje te spelen en te testen is het prima.

Weet je overigens zeker dat je ISP geen IPv6 levert? Een paar grote ISPs leveren het wel aan zakelijke klanten als je er om vraagt.

Als tussenoplossing kun je een tunnel aanvragen bij Sixxs of HE. Daar wil je niet je hele bedrijf van laten afhangen maar het is prima geschikt als tijdelijke oplossing. Voorlopig gaat er toch niet meer dan een paar procent van je verkeer via IPv6.

[Paul]

Maurits van Baerle schreef op dinsdag 10 februari 2015 @ 18:09:
Als je van tunnel of ISP wisselt verandert alleen je prefix

...en mag je alsnog alles om gaan nummeren

databeestje schreef op dinsdag 10 februari 2015 @ 18:12:
Als het bedrijf een knap formaatje heeft dan raad ik aan een Provider Independent IP space aan te vragen bij RIPE, [..] Let wel, je hebt een ISP nodig die BGP met je wil doen

Hmm, dat zou wel moeten lukken

CAPSLOCK2000 schreef op dinsdag 10 februari 2015 @ 19:37:
Weet je overigens zeker dat je ISP geen IPv6 levert? Een paar grote ISPs leveren het wel aan zakelijke klanten als je er om vraagt.

Het is niet alleen de ISP, ook in de organisatie vind men andere zaken belangrijker. En op zich snap ik dat wel (er zijn meer dan genoeg andere zaken om aan te pakken die wel direct invloed hebben op de bedrijfsprocessen) maar toch denk ik dat we relatief simpel vrij grote slagen kunnen maken om zo in ieder geval de diensten die we zelf (extern) aanbieden ook op IPv6 te ontsluiten, en zelf ook bij IPv6-only zaken te kunnen.

Het probleem is dat wij nog geen diensten nodig hebben die enkel op IPv6 draaien, en de mensen die naar onze diensten verbinden allemaal IPv4 hebben

[ Voor 43% gewijzigd door Paul op 10-02-2015 19:49 ]

[Verwijderd]

Paul schreef op dinsdag 10 februari 2015 @ 19:39:
[...]
...en mag je alsnog alles om gaan nummeren
[...]
Hmm, dat zou wel moeten lukken
[...]
Het is niet alleen de ISP, ook in de organisatie vind men andere zaken belangrijker. En op zich snap ik dat wel (er zijn meer dan genoeg andere zaken om aan te pakken die wel direct invloed hebben op de bedrijfsprocessen) maar toch denk ik dat we relatief simpel vrij grote slagen kunnen maken om zo in ieder geval de diensten die we zelf (extern) aanbieden ook op IPv6 te ontsluiten, en zelf ook bij IPv6-only zaken te kunnen.

Het probleem is dat wij nog geen diensten nodig hebben die enkel op IPv6 draaien, en de mensen die naar onze diensten verbinden allemaal IPv4 hebben

Ik heb zelf ook wat partijen naar IPv6 bewogen die er geen reden voor zagen, er zijn redelijk wat dingen die je kunt doen zonder dat daar directe kosten en veel tijd aan verbonden zijn.

- Vraag manager/ collega's bij aankopen nieuwe apparatuur (switches, printers, firewall's loadbalancers) of ze in iedergeval IPv6 ondersteuning hebben omdat ze anders waarschijnlijk voor het eind van hun beoogd termijn vroegtijd vervangen worden en dat zou zonde van het geld zijn

- Gooi je domein in ip6.nl en kijk of je DNS provider en mailprovider mocht je dit niet zelf afhandelen IPv6 support hebben. Indien niet, stuur een standaars informatief mailtje of ze hier een planning voor hebben.

- Geef aan dat jullie al IPv6 draaien, aangenomen dat je ergens in het netwerk minimaal 2 windows 2008 of hoger servers hebt of windows 7 werkstations in hetzelfde lan. Deze praten onderling IPv6. Dat het beter is dat er kennis wordt opgedaan dan dat er verkeer in je netwerk zit waar je geen zicht op hebt of kennis van hebt.

- Controleer wat windows 2008 of hoger servers als je die hebt met een ipconfig /all als daar een unicast ipv6 adres tussen zit dan heb je waarschijnlijk een teredo tunnel, dan is deze server ook mogelijk al te benaderen op het internet op dit IP. Ik heb servers gezien met meerdere (virtual) nic's waarop deze adressen zaten en geen active firewall (windows firewall) actief was. Dus onbeschermd online
IPv6 disablen levert ook issues op en wordt volgens mij zelfs ontraden door MS. Tunnels uitzetten en blokkeren is een stuk beter> http://www.howfunky.com/2...pv6-tunneling-across.html

Zo zijn er nog wel wat dingen, ofwel zoek de beste argumenten op, krijg wat support om in iedergeval een plan van aanpak te maken zodat de bal gaat rollen.

[CAPSLOCK2000]

Niet vragen, dan gaat management zich er mee bemoeien. Doen. Voor IPv4 vraag je toch ook geen toestemming?

Bel je ISP voor IPv6 of zet zelf een tunneltje op. De volgende keer dat je een systeem inricht of groot onderhoud pleegt voeg je ook een IPv6-adresje toe.

Blijf wel voorzichtig, als er iets gruwelijk stuk gaat heb je het management opeens tegen.

Zorg in ieder geval dat het bij alle aankopen op de lijst met requirements staat. Als je er nu niet aan begint zit je over 10 jaar nog met apparatuur die er niet mee overweg kan. Verder niet te zwaar aan tillen maar gewoon op nemen in de lange lijst met technische eisen en wensen.

[ Voor 28% gewijzigd door CAPSLOCK2000 op 11-02-2015 03:58 ]

[tweegroenethee]

Even een (dom) vraagje tussendoor.

We hebben hier allerlei verschillende virtuele servers draaien met applicaties. Denk aan WDS, Exchange, Print, Telefoon. Hoe hebben jullie de migratie (of dual-stack) ervaren met IPv6?
Blijven de applicaties gewoon werken? Is er eigenlijk alleen op OS niveau verandering, dus alleen IPv6 adressen invoeren, AAAA record aanmaken en voor de rest hoeft er niet veel veranderd te worden? Of heeft het ook veel effect op de software zelf?

[Snow_King]

Daan87423 schreef op woensdag 11 februari 2015 @ 10:44:
Even een (dom) vraagje tussendoor.

We hebben hier allerlei verschillende virtuele servers draaien met applicaties. Denk aan WDS, Exchange, Print, Telefoon. Hoe hebben jullie de migratie (of dual-stack) ervaren met IPv6?
Blijven de applicaties gewoon werken? Is er eigenlijk alleen op OS niveau verandering, dus alleen IPv6 adressen invoeren, AAAA record aanmaken en voor de rest hoeft er niet veel veranderd te worden? Of heeft het ook veel effect op de software zelf?

Niet direct, maar sommige software kán kapot gaan. Zo ver ik weet werkt Exchange prima over IPv6, maar veel VOIP applicaties bijvoorbeeld niet.

Je zal het gewoon moeten testen. Eerst IPv6 er bij zetten, nog niet direct het AAAA-record, dat langzaam doen.

Zo lang de clients geen IPv6 hebben merken ze het ook niet.

[CAPSLOCK2000]

Mijn ervaring is dat de meeste applicaties blijven werken. De meeste applicaties doen zelf niks met IP-adressen en hebben dus nergens last van. De meeste server-software is al jaren geleden geschikt gemaakt voor IPv6. Apache, mysql, bind, apache, en dergelijke applicaties doen het gewoon.

Wel moet je rekening houden met applicaties die ACL's op IP-adres gebruiken, daar zul je ook IPv6-adressen moeten gaan toevoegen. Net als in je firewalls, dat wordt nogal eens vergeten.

Vervelend zijn met name de kleine en zelfgebouwde applicaties die al jaren zonder onderhoud draaien en 'iets' met IP-adressen doen. Denk aan applicaties die adres-ranges hebben gehardcode of die IP-adressen in een database of logfile op slaan. Daar is vaak geen rekening gehouden met IPv6. Dan heb je bv een database met een 32-bit veld voor een IP-adres. Daar krijg je nooit een IPv6-adres in. Of applicaties die een IP-adres in een integer stoppen. Met IPv4 werkt dat, met IPv6 niet. Of applicaties die een syntax-check doen en er van uit gaan dat een IP-adres altijd puntjes bevat en nooit een dubbele punt. Of applicaties die

In mijn ervaring werkt de grote bulk gewoon direct. Als het niet werkt merk je dat eigenlijk ook direct, dan wil de applicatie bv niet meer opstarten. Applicaties het gewoon lijken te doen maar pas later in de problemen komen ben ik zelf nog niet tegen gekomen, al bestaan ze vast.

Het meeste last heb ik van applicaties die wel IPv6-support hebben maar waar dat heel naief is gedaan.
255.255.255.0 en 1.1.168.192 zijn nog wel te doen, maar ffff:ffff:ffff:ffff:0:0:0:0 en 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f zijn niet leuk om in te moeten voeren. Ik heb ook een applicatie waar je 1 ip-adres per gebruiker kan opgeven. Zowel een IPv4 als een IPv6 adres kan niet.

[Hipska]

databeestje schreef op dinsdag 10 februari 2015 @ 18:12:
Je kan met IPv6 wel meerdere adressen aan een enkel apparaat hangen, maar met wel adres gaat deze naar het internet communiceren? Er is een 50% kans dat het 100% de verkeerde is en het niet werkt.

Je gaat dan feitelijk de source adres selectie op apparaat niveau doen, veel succes daarmee in een grotere omgeving

Dus jij beweert dat een host die zowel een publiek IPv6 adres als een ULA heeft soms het ULA gebruikt als source wanneer die naar een ander publiek IPv6 verbindt? Is dat echt zo?

[anboni]

Hipska schreef op woensdag 11 februari 2015 @ 13:24:
[...]

Dus jij beweert dat een host die zowel een publiek IPv6 adres als een ULA heeft soms het ULA gebruikt als source wanneer die naar een ander publiek IPv6 verbindt? Is dat echt zo?

Ik had er gisteren al twijfels bij toen ik die reactie las, maar geen tijd om er in te duiken. Nu wel. Er is dus inderdaad gewoon een RFC (6724) die vastlegt hoe het source adres gekozen moet worden. Mijn idee met ULA's begint me meteen nog een stuk logischer in de oren te klinken (hier meer leesvoer)

[databeestje]

anboni schreef op woensdag 11 februari 2015 @ 14:04:
[...]


Ik had er gisteren al twijfels bij toen ik die reactie las, maar geen tijd om er in te duiken. Nu wel. Er is dus inderdaad gewoon een RFC (6724) die vastlegt hoe het source adres gekozen moet worden. Mijn idee met ULA's begint me meteen nog een stuk logischer in de oren te klinken (hier meer leesvoer)

De summary onder aan die pagina vat het mooi samen:

Summary

The rules for determining which of many possible unicast addresess to use for the source address of outgoing packets are very complex and difficult for most people to predict. Influencing the choice by modifying the policy table is even more complex. To most people the choice of source address will appear random. If you want to be sure a particular address is used as source, the only certain way is to eliminate all the other global unicast addresses (except for the autonomously generated Link-Local address).

De situatie wordt nog veel interessanter als je meer dan 1 globale prefix gebruikt, dan wordt het helemaal een verhaal. Dat is wat er in japan gebeurt waarbij er zowel IPTV als Internet een prefix gebruikt op hetzelfde LAN. Door deze selectie op de eindapparatuur te laten plaats vinden kan dit tot problemen leiden.

In het minste geval dropt ISP A verkeer van ISP B omdat het een andere prefix is.

De aanname van de IETF was dat alle wegen naar Rome (het internet) leiden, en dat is pertinent niet waar. Ik kan helaas de video van 1 van deze conferences niet meer vinden waar de verontwaardiging en verwarring al snel compleet was onder de mensen toen dit aangegeven werd.

[anboni]

Ik kan me inderdaad voorstellen dat er bij meerdere globale prefixes nog wel verwarring kan optreden. Voor site-local vs global ben ik daar minder bang voor. Het is in ieder geval zeker iets om mee te testen, omdat een eventuele hernummering toch een stuk eenvoudiger zou zijn als je alle interne dingen alleen een statisch ULA geeft en global volledig dynamisch laat voor dingen die geen firewall entry nodig hebben.

[Hipska]

Inderdaad, ik heb tot nu toe ook nog van niemand een harde argumentatie gezien waarom geen ULA te gebruiken in je LAN.

Enigste dat ik gezien heb is databeestje die beweert dat soms het ULA adres kan gekozen worden als src voor traffic naar internet toe. Wat ik verder nog nooit ben tegen gekomen en ook niemand anders melding zie van maken.

Dus kan iemand deftige argumenten geven waarom ik geen ULA zou moeten gebruiken?

[Verwijderd]

Hipska schreef op woensdag 11 februari 2015 @ 16:11:
Inderdaad, ik heb tot nu toe ook nog van niemand een harde argumentatie gezien waarom geen ULA te gebruiken in je LAN.

Enigste dat ik gezien heb is databeestje die beweert dat soms het ULA adres kan gekozen worden als src voor traffic naar internet toe. Wat ik verder nog nooit ben tegen gekomen en ook niemand anders melding zie van maken.

Dus kan iemand deftige argumenten geven waarom ik geen ULA zou moeten gebruiken?

Ik heb niet alle reacties en motiveringen gelezen maar ik wil even de vraag omdraaien, waarom zou je wel ULA adressen willen gebruiken?

Als het is om IPv6 te testen dan vraag ik me af hoe beperkt wilt je testen, namelijk tussen een paar systemen lokaal lijkt me dan. Omdat je niet wilt dat er dingen stuk gaan in je operationele omgeving en je een test daar zeker op wilt laten lijken geld het al oude IP principe, routing moet werken. Dus werk van buiten naar binnen. Eerst een verbinding, dan bv een test server in een DMZ, kijken of deze bereikbaar is van het internet dus dat routering van het internet naar je test server werkt en zo dieper je netwerk in.

[anboni]

Verwijderd schreef op woensdag 11 februari 2015 @ 17:16:
Ik heb niet alle reacties en motiveringen gelezen maar ik wil even de vraag omdraaien, waarom zou je wel ULA adressen willen gebruiken?

anboni in "Het grote IPv6 topic"

[Verwijderd]

anboni schreef op woensdag 11 februari 2015 @ 17:26:
[...]
anboni in "Het grote IPv6 topic"

Ik zie nog geen motivatie waarom je dit zou willen doen dus ik doe het even met een aanname die mogelijk verkeerd is.

Security, zodat interne systemen nooit extern bereikbaar zijn.
Dit maakt de boel zowel complexer met routering, want interne systemen moeten vroeger of later toch iets externs doen zoals contact met een externe partij voor uitwisseling of ? dns, ntp, etc. Dingen die je wel zou kunnen afvangen maar er toch iets komt opduiken zoals remote-access.

Verder is security natuurlijk een netwerk issue, dus je firewall en een stapje verder accesslists op switches, nog een stapje verder of ertussen een host-based firewall. (windows firewall of linux IPtables).

Tevens is de bedreiging van een systeem vaak niet alleen meer van "buiten" naar binnen maar ook van binnen naar buiten, denk aan gast systemen of werknemers die foute software installeren of sites bezoeken. Mallware vind zich vaak een weg en kan dan interne systemen besmetten die via proxy servers (voor updates van windows (bij gebrek aan wsus) of overige software) via een proxy server aan het internet verbinden om overige rommel -mall-ware- te downloaden. En proxy filters kunnen helpen maar connecten naar een httpS site omzeilt dit al weer grotendeels, certficaat meldingen kan mall-ware negeren.

Ook maakt het het zoeken en/of filteren van logfiles wat makkelijker omdat je niet met verschillende IP reeksen aan de slag bent maar 1 globale reeks gebruikt.

/EDIT

Wat ik altijd doe is uitgaand verkeer blokkeren, iets wat je kan met een firewall maar bv niet thuis enkel met een NAT device. Een reject rule erop en logging. Dan zie je vanzelf wat een apparaat wilt en wat je dus mogelijk bent vergeten, zoals DNS instellingen, NTP of HTTP access voor updates van software. Dan kan je bewust een keuze maken.

[ Voor 14% gewijzigd door Verwijderd op 11-02-2015 17:42 ]

[anboni]

De motivatie waarom stond in de post er vlak boven: wat als je van ISP verandert en dus een andere global prefix krijgt. Als je intern alle fixed adressen in een ULA gooit (behalve wat een firewall entry naar de buitenwereld nodig heeft), wordt een dergelijke hernummering een heel stuk eenvoudiger.

[databeestje]

2 netwerk prefixes onderhouden is ook niet iets om naar uit te kijken. Zoals boven aangeven maakt het de situatie (vaak) een stuk complexer maken dan je lief is.

Zoals een ander aangeeft, er komt vaak een punt dat iets wat oorspronkelijk geen internet toegang nodig had nu wel het internet op moet. Ga je dubbele ACLs onderhouden? Ga je meerdere gemixte RA uitsturen voor zowel de RA en GUA prefixes op hetzelfde VLAN? Ga je tegelijkertijd de GUA en ULA routeren, hoe houd je deze hierarchie gelijk?

Ik zou me er echt niet aan wagen, ik heb het overwogen, maar na een lijst van toegenomen administratief beheer en complexiteit heb ik er van af gezien. Het is makkelijker om even een subnetje met 50 printers om te nummeren. De prefix aanpassen van een buts apparaten is soms makkelijker.

Heel veel configuratie heb ik omgezet van statisch naar dynamisch, dat maakt dit soort dingen een stuk simpeler. Het hele omnummer verhaal kan je soms met de beste wil van de wereld niet omzeilen.

De helft van mijn werkgever is verkocht, daar kan geen enkel nummer plan tegenop. Tsjakka ...

Ik zou niet blind willen vertrouwen op de source adres selectie van apparaten, het impliceert dat deze dit allemaal zelf kunnen invullen, en zullen dat dan ook doen. En ik ben ervan overtuigd dat de Samsung printer dit anders doet dan de HP printer of een Dell DRAC kaart.

Tevens ondersteunen veel apparaten dan weer niet meerdere IP6 adressen (ook al vermeld de RFC dit expliciet), maar ik wel graag de server van thuis beheren. Dus een GUA adres, met een route in mijn OpenVPN server voor toegang, maar een blok ACL op de firewall voor van buiten. Prima!

Apparaten met enkel een ULA adres zullen altijd met dat adres naar het internet toe proberen te verbinden, want er is geen keuze. Zo lekt meer van dat verkeer het internet op, want NAT bestaat niet

Door de GUA adressering weet ik ook zeker dat de nummering uniek is en er dus geen situatie onstaat waarbij er overlap ontstaat dat 2 ondernemingen dezelfde ULA prefix gebruiken. Iets wat nu al schering en inslag is tussen ondernemingen met het 10/8 blok.

[CyBeR]

Het idee van ULA's is ook wel dat ze uniek zijn; daar staat de U ook voor. Er is zelfs een mogelijkheid tot registratie van ULA's: https://www.sixxs.net/tools/grh/ula/

Moet je wel netjes een random prefix gebruiken en niet iets moois of '1' ofzo.


Niet dat ik aanraad ULA te gebruiken voor internet-connected netwerken overigens.

[ Voor 14% gewijzigd door CyBeR op 11-02-2015 19:06 ]

[databeestje]

CyBeR schreef op woensdag 11 februari 2015 @ 19:06:
Het idee van ULA's is ook wel dat ze uniek zijn; daar staat de U ook voor. Er is zelfs een mogelijkheid tot registratie van ULA's: https://www.sixxs.net/tools/grh/ula/

Moet je wel netjes een random prefix gebruiken en niet iets moois of '1' ofzo.


Niet dat ik aanraad ULA te gebruiken voor internet-connected netwerken overigens.

Nee, ULA voor internet connected netwerken heeft niet veel zin, dan ben je imho veel beter uit met een ACL en een beetje firewall.

De ULA prefix is een /7, maar omdat je nullen weg kan laten met :: ben ik toch een beetje bang dat je vermoeden waar wordt. Iets met "lui" en "het werkt".

Toegegeven, 10/8 is niet zo groot, maar in de afgelopen 15 jaar hebben wel al met 3 leveranciers problemen gehad. 1tje hebben we opgelost met een 1:1 netwerk NAT (holy crap, broken brains everywhere), en toen hebben we zelfs nog meer NAT toegepast omdat de applicatie BRAK en niet met NAT om kon gaan (2 weg verkeer). Lang leve enterprise software.

De andere hebben we opgelost door de ene of de andere kant om te nummeren.

Edit:

Offtopic: Om dezelfde reden je Active Directory domein bij de SIDN registreren en een subdomein daarvan te gebruiken. Dan wordt je .local en .work TLD niet ineens een echt domein en breekt er van alles.

[ Voor 8% gewijzigd door databeestje op 11-02-2015 20:33 ]

[Osiris]

CyBeR schreef op woensdag 11 februari 2015 @ 19:06:
Het idee van ULA's is ook wel dat ze uniek zijn; daar staat de U ook voor. Er is zelfs een mogelijkheid tot registratie van ULA's: https://www.sixxs.net/tools/grh/ula/

Moet je wel netjes een random prefix gebruiken en niet iets moois of '1' ofzo.

RFC 4193 noemt inderdaad dat het globally unique zou moeten zijn, maar zegt ook expliciet "with high probability of uniqueness". En dat daarvoor een fatsoenlijke PRNG gebruikt dient te worden, om "clashes" te voorkomen tussen twee ranges bij bepaalde situaties.

De geest van de RFC geeft overduidelijk weer dat het niet per se unique dient te zijn. Maar meer 'streven naar'.

ULA-registers zijn IMO dan ook achterlijk.. Maargoed, SixXS hè

[CAPSLOCK2000]

Tja, eerlijk en nuttig of niet, ik heb wel twee ULA's geregistreerd die mij en mijn werkgever handig uit komen. Ik heb ze al tijden niet meer gebruikt, maar ja, gratis is gratis he

[tweegroenethee]

Jullie geven aan dat het verstandig is om afdelingen in aparte subnets te plaatsen en deze specifieke ACLs te geven op de firewalls. In ons bedrijf hebben we de servers voor onze diensten buiten het hoofdkantoor draaien bij een speciaal hosting bedrijf. Er loopt momenteel vanuit het hoofdkantoor een VPN tunnel naar deze servers.

Hoe moet ik dat dan zien met Access lists? Kan ik bepaalde IPv6 subnets en/of adressen dan toegang geven op bepaalde IPv6 subnets en/of adressen op het hosting bedrijf (waar ook een firewall staat)? Deze verbinding onderling wordt dan beveiligd door IPsec.

En is het beter om stateful IP adressen dmv DHCPv6 uit te delen aan de werkstations in dat subnet ipv stateless met mac adres?

[CyBeR]

Persoonlijk zou ik 't zo veel mogelijk stateless houden. Geen administratiewerk en gedoe.

[Snow_King]

Daan87423 schreef op donderdag 12 februari 2015 @ 15:24:
Jullie geven aan dat het verstandig is om afdelingen in aparte subnets te plaatsen en deze specifieke ACLs te geven op de firewalls. In ons bedrijf hebben we de servers voor onze diensten buiten het hoofdkantoor draaien bij een speciaal hosting bedrijf. Er loopt momenteel vanuit het hoofdkantoor een VPN tunnel naar deze servers.

Hoe moet ik dat dan zien met Access lists? Kan ik bepaalde IPv6 subnets en/of adressen dan toegang geven op bepaalde IPv6 subnets en/of adressen op het hosting bedrijf (waar ook een firewall staat)? Deze verbinding onderling wordt dan beveiligd door IPsec.

En is het beter om stateful IP adressen dmv DHCPv6 uit te delen aan de werkstations in dat subnet ipv stateless met mac adres?

Allereerst moeten je servers dus een IPv6 adres krijgen van je hoster aldaar en dat moet je daar configureren.

Op je kantoor krijg je dan een /48 subnet waaruit je een /64 zal gebruiken voor je desktops e.d.

In de (IPv6) firewall van je servers geef je dan aan dat enkel die ene /64 verbinding mag maken met je servers.

Op kantoor zelf zou ik gewoon met SLAAC de adressen uitdelen en DHCPv6 nog draaien om eventueel de DNS uit te delen, niet alle clients snappen SLAAC met DNS.

[CyBeR]

Zolang je geen V6-only clients hebt, is dns ook niet zo boeiend. Dat krijgen ze wel via (v4) dhcp.

[Ximon]

Snow_King schreef op donderdag 12 februari 2015 @ 19:54:
Op kantoor zelf zou ik gewoon met SLAAC de adressen uitdelen en DHCPv6 nog draaien om eventueel de DNS uit te delen, niet alle clients snappen SLAAC met DNS.

quote: http://www.sixscape.com/j...s-autoconfiguration-slaac

No DHCPv6 server is required for SLAAC to happen, but SLAAC can inform nodes that a DHCPv6 server is available, from which it can obtain stateless information (such as IPv6 addresses of DNS)

quote: http://blog.geoff.co.uk/2...ed-network-configuration/

SLAAC has limitations, however. The most significant one is that, until recently, it provided no mechanism for configuring DNS resolver information. RFC 6106, published late last year, finally standardized two Router Advertisement options that permit this: RDNSS (Recursive DNS Server) and DNSS (DNS Search List). (These options are commonly referred to simply as “RDNSS”.) Support for these options is only just starting to appear in operating systems.

quote: https://social.technet.mi...8-server-support-rfc-6106

No version of Windows supports RFC 6106, either as a client or a router, and there are no plans currently to add support.

Het lijkt me dat SLAAC op dit moment nog niet geschikt is voor gebruik in omgevingen met Windows erin, tenzij je met addons als rdnssd-win32 wilt gaan werken.

EDIT: Je kan inderdaad dit soort dingen ook via de IPv4 infrastructuur regelen, maar hoe ga je dan ervoor zorgen dat clients ook automatisch een AAAA record registreren in de DNS server? De server open zetten voor dynamic updates van clients lijkt me onwenselijk.

[ Voor 7% gewijzigd door Ximon op 13-02-2015 10:49 ]

[Snow_King]

Ximon schreef op vrijdag 13 februari 2015 @ 10:47:


Het lijkt me dat SLAAC op dit moment nog niet geschikt is voor gebruik in omgevingen met Windows erin, tenzij je met addons als rdnssd-win32 wilt gaan werken.

Werkt prima. De Windows machine krijgt via SLAAC zijn adres en vervolgens zal deze bij de DHCPv6 server om de DNS-servers en het domein vragen.

In de RA kan je uiteraard de DNS servers en domein wel adverteren, dan kan de client zelf kiezen wat hij doet.

Zo kan je op een client IPv4 volledig uit zetten. Zo werkt het hier bij mij thuis ook, geen problemen mee.

[ijdod]

Ximon schreef op vrijdag 13 februari 2015 @ 10:47:

EDIT: Je kan inderdaad dit soort dingen ook via de IPv4 infrastructuur regelen, maar hoe ga je dan ervoor zorgen dat clients ook automatisch een AAAA record registreren in de DNS server? De server open zetten voor dynamic updates van clients lijkt me onwenselijk.

DDNS is nog steeds een beetje een lastige, tenminste, als je dual-stack clients zowel met A als AAAA wilt laten registeren. De techniek is er (RFC4701 enz), maar client support is nog niet optimaal.

[d--amo]

Ik heb even wat zitten testen, sinds ik native IPv6 heb via mijn ISP.

Ik krijg op mijn WAN RA's binnen met de M-flag op 1. Mijn router start dus zijn DHCP service voor een adres. Hij krijgt vervolgens een /128 adres van mijn ISP.

Als ik het goed heb, gaat mijn router steeds de default gateway (link-local) uit de RA's gebruiken. Ook al is er statefull DHCPv6 actief. Is dat correct?

Op IPv4 zijn we gewoon van een gateway in hetzelfde subnet te zien. Dat is dus niet mogelijk, sinds ik hier een /128 adres krijg. Het zijn dus de link-local adressen in IPv6 die zulke setup mogelijk maken?

In IPv4 kan je denk ik geen /32 adres gebruiken en nog verwachten dat je buiten dat netwerk geraakt?

[CyBeR]

d--amo schreef op dinsdag 17 februari 2015 @ 10:50:
Ik heb even wat zitten testen, sinds ik native IPv6 heb via mijn ISP.

Ik krijg op mijn WAN RA's binnen met de M-flag op 1. Mijn router start dus zijn DHCP service voor een adres. Hij krijgt vervolgens een /128 adres van mijn ISP.

Als ik het goed heb, gaat mijn router steeds de default gateway (link-local) uit de RA's gebruiken. Ook al is er statefull DHCPv6 actief. Is dat correct?

Op IPv4 zijn we gewoon van een gateway in hetzelfde subnet te zien. Dat is dus niet mogelijk, sinds ik hier een /128 adres krijg. Het zijn dus de link-local adressen in IPv6 die zulke setup mogelijk maken?

Yep.

In IPv4 kan je denk ik geen /32 adres gebruiken en nog verwachten dat je buiten dat netwerk geraakt?

Jawel, maar alleen op point-to-pointverbindingen. Je ziet dat heel vaak (of eigenlijk altijd) bij PPP-gebaseerde verbindingen bijvoorbeeld.

[Snow_King]

d--amo schreef op dinsdag 17 februari 2015 @ 10:50:
Ik heb even wat zitten testen, sinds ik native IPv6 heb via mijn ISP.

Ik krijg op mijn WAN RA's binnen met de M-flag op 1. Mijn router start dus zijn DHCP service voor een adres. Hij krijgt vervolgens een /128 adres van mijn ISP.

Als ik het goed heb, gaat mijn router steeds de default gateway (link-local) uit de RA's gebruiken. Ook al is er statefull DHCPv6 actief. Is dat correct?

Op IPv4 zijn we gewoon van een gateway in hetzelfde subnet te zien. Dat is dus niet mogelijk, sinds ik hier een /128 adres krijg. Het zijn dus de link-local adressen in IPv6 die zulke setup mogelijk maken?

In IPv4 kan je denk ik geen /32 adres gebruiken en nog verwachten dat je buiten dat netwerk geraakt?

Ja, zo ziet het er bij mij uit via ZeelandNet:

code:

2a02:f68:XXX:X::a dev eth0  proto kernel  metric 256 
default via fe80::201:5cff:fe44:d643 dev eth0  proto ra  metric 1024  expires 1778sec

[d--amo]

CyBeR schreef op dinsdag 17 februari 2015 @ 10:59:
[...]


Yep.


[...]


Jawel, maar alleen op point-to-pointverbindingen. Je ziet dat heel vaak (of eigenlijk altijd) bij PPP-gebaseerde verbindingen bijvoorbeeld.

Oh ja, ik denk te vaak enkel aan multi-access ethernet netwerken
Thnx!

Implementaties van IPv6 snooping, zijn dus (nog steeds) onontbeerlijk in productie netwerken.

[tweegroenethee]

"Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6."

Aldus RFC 4861: https://tools.ietf.org/html/rfc4861#ref-ADDRCONF

Betekent dit dat als beide flags op 0 staan, het geen stateful configuration meer is maar stateless?

[Snow_King]

Daan87423 schreef op dinsdag 17 februari 2015 @ 14:04:
"Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6."

Aldus RFC 4861: https://tools.ietf.org/html/rfc4861#ref-ADDRCONF

Betekent dit dat als beide flags op 0 staan, het geen stateful configuration meer is maar stateless?

Volgens mij wel ja. Je krijgt dan enkel een prefix (en wellicht RR-DNS) informatie waarna de client het zelf mag uitzoeken.

[CyBeR]

Daan87423 schreef op dinsdag 17 februari 2015 @ 14:04:
"Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6."

Aldus RFC 4861: https://tools.ietf.org/html/rfc4861#ref-ADDRCONF

Betekent dit dat als beide flags op 0 staan, het geen stateful configuration meer is maar stateless?

Correct.

[tweegroenethee]

CyBeR schreef op dinsdag 17 februari 2015 @ 15:17:
[...]


Correct.

Ze noemen stateless auto configuration ook wel Plug & Play, maar hoe kan een client op het internet zonder DNS instellingen? Wordt dit via de provider geregeld dan?

[CyBeR]

RDNSS. Of met v4 dhcp als je dat ook hebt.

DNS info is op zich niet stateful he.

[ Voor 32% gewijzigd door CyBeR op 17-02-2015 16:06 ]

[joopv]

Voor de IPv6 - enabled lezers hier :

Stel je hebt een Wolfgang (Aldi) mobieltje wat stuk is en je probeer het RMA formulier te downloaden op
http://www.wolfgangmobile...Docs/RMA_Formulier_AT.pdf

Bij werkt dat alleen als ik de IPv6 stack even de nek omdraai

[Osiris]

Doet 't prima hier, via IPv6

[Eärendil]

Bij mij werkt het ook niet via IPv6. Er wordt wel een TCP-verbinding geopend maar er komt geen response, zelfs geen foutmelding.

edit:
Via een Sixxs tunnel

[ Voor 12% gewijzigd door Eärendil op 17-02-2015 19:18 ]

[Osiris]

Nou, raar.. Gebruiken jullie tunnels? Werkt een traceroute wel?

[b][green]osiris@desktop[/][blue] ~ $ [/][/]telnet www.wolfgangmobile.com 80
Trying 2001:4b98:dc0:950::137...
Connected to www.wolfgangmobile.com.
Escape character is '^]'.
HEAD /Downloads/Docs/RMA_Formulier_AT.pdf HTTP/1.1
Host: www.wolfgangmobile.com


HTTP/1.1 200 OK
Server: Apache/2.4.10
Last-Modified: Mon, 10 Nov 2014 10:21:09 GMT
ETag: "36b22-5077e85731bcf"
Accept-Ranges: bytes
Cache-Control: max-age=31536000
Expires: Wed, 17 Feb 2016 18:16:53 GMT
X-Powered-By: W3 Total Cache/0.9.4
Content-Type: application/pdf
Content-Length: 224034
Accept-Ranges: bytes
Vary: User-Agent
Date: Tue, 17 Feb 2015 18:16:53 GMT
Connection: keep-alive
Via: 1.1 varnish
Age: 0

Connection closed by foreign host.
[b][green]osiris@desktop[/][blue] ~ $ [/][/]

[b][green]osiris@desktop[/][blue] ~ $ [/][/]traceroute6 www.wolfgangmobile.com 
traceroute to www.wolfgangmobile.com (2001:4b98:dc0:950::137), 30 hops max, 80 byte packets
 1  2001:981:[i]knip[/]:1:3631:c4ff:fe2d:4338 (2001:981:a545:1:3631:c4ff:fe2d:4338)  0.922 ms  0.899 ms  1.317 ms
 2  lo0.dr13.1d12.xs4all.net (2001:888:1:1003::1)  12.613 ms  12.621 ms  13.234 ms
 3  1323.ae3.xr3.3d12.xs4all.net (2001:888:1:4027::1)  14.331 ms  13.503 ms 1318.ae3.xr3.3d12.xs4all.net (2001:888:1:4033::1)  14.299 ms
 4  0.so-0-2-0.xr1.tc2.xs4all.net (2001:888:1:4000::1)  15.062 ms 0.ge-1-2-0.xr1.sara.xs4all.net (2001:888:1:4005::1)  15.042 ms  15.035 ms
 5  2001:7f8:1::a502:9169:1 (2001:7f8:1::a502:9169:1)  30.439 ms  30.775 ms  30.767 ms
 6  p252-dist1-d-ip6.paris.gandi.net (2001:4b98:1f::c2d1:242)  30.748 ms  42.883 ms  42.871 ms
 7  vl2-ip6.dist3-d.paris.gandi.net (2001:4b98:2::46)  25.915 ms  26.451 ms  26.438 ms
 8  gpaas7.dc0.gandi.net (2001:4b98:dc0:950::137)  26.417 ms  27.422 ms  27.411 ms
[b][green]osiris@desktop[/][blue] ~ $ [/][/]

[ Voor 38% gewijzigd door Osiris op 17-02-2015 22:42 ]