IPv6 global vs link-local address vraagje

[ITnetadmin]

Ok; IPv6 implementeren heeft dus nog altijd een hele resem kinderziektes.
Software/firmware die moeilijk doet (bv vmware aanvaardt geen link-local adres als gateway, en synologie blijkbaar geen global adres als gateway)

Routers die moeilijk doen (pfsense is altijd moeilijk als het op dynamische WAN IPs aankomt, en kan dus blijkbaar geen static suffix definieren dat dan aangevuld wordt met een dynamic prefix; of het is me alleszins nog niet gelukt)

Voor lokale "routing" (ik mag het eigenlijk zo niet noemen) wordt vaak het link-local address gebruikt. Bv veel routers raden het gebruik van fe80::1 aan als default gateway.


Soit, pfsense en andere perikelen terzijde, is dit mijn vraagje:

Bij het assignen van IP addressen gebruiken ITers vaak graag "leesbare" IP adressen. Het gebruik van NPT of NAT66 kan er bv al voor zorgen dat een onleesbare 20011234:aedf::/64 prefix vertaald kan worden in iets dat intern makkelijk leest en typt.

Bij het gebruik van DHCPv6 kan je ook "eenvoudigere" suffixen uitdelen, ipv een volle EUI-64 op basis van het mac adres.
Echter, voor "lokale" communicatie gebruikt een toestel zeer vaak zijn link-local address (zie hierboven mijn referentie naar het gebruik van fe80::1 als gateway).
Probleem is dat een link-local adres, in de fe80::/64 range, nog altijd een complexe suffix heeft. Dit kan uiteraard verholpen worden door een static address in te geven.

Wat ik echter graag zou willen, is dat de link-local suffix zich instelt zodat hij hetzelfde is als de DHCPv6 assigned suffix.
Dus als bv de DHCP server een client het adres <prefix>::120 geeft, dat het link-local address ook op fe80::120 komt te staan.
Anders wordt network management, packet tracing, logfiles, etc... gewoon een nachtmerrie.

Iemand een idee hoe dit te verwezenlijken?

[ubremoved_539]

Bij het assignen van IP addressen gebruiken ITers vaak graag "leesbare" IP adressen. Het gebruik van NPT of NAT66 kan er bv al voor zorgen dat een onleesbare 20011234:aedf::/64 prefix vertaald kan worden in iets dat intern makkelijk leest en typt.

Euh, daarvoor heeft men DNS uitgevonden... hoe complex en moeilijk je IP-adres is maakt dus niet uit.

[ITnetadmin]

Nee, dus. Het maakt wel degelijk uit.
Ik werk liever op layer 3; ik onthou ook beter IP adressen dan benamingen, en als den DNS faalt kan ik anders nergens meer aan.

Punt blijft dat ik vind dat je toestellen op IP moet kunnen herkennen.
En ik ben duidelijk niet de enige, want ik kan het aantal ITers niet tellen die hun toestellen in ranges gooien, bv servers in de 50 block, printers in 20, switchen in de 240 reeks, etc etc...

Ik weet dat er meerdere visies hierover bestaan, dat er verschillende kampen zijn; I don't care.
Waar ik werk komt IPv6 niet binnen als de IPs niet op een leesbare manier ingesteld kunnen worden.

[ubremoved_539]

En ik ben duidelijk niet de enige, want ik kan het aantal ITers niet tellen die hun toestellen in ranges gooien, bv servers in de 50 block, printers in 20, switchen in de 240 reeks, etc etc...

Count me in... ik doe dat ook Feit is dat je geen controle hebt over het link-local adres.

Waar ik werk komt IPv6 niet binnen als de IPs niet op een leesbare manier ingesteld kunnen worden.

Tja, dan zal je het dus zonder moeten doen... veel nood aan IPv6 op LAN niveau gaat er toch nog niet meteen zijn.

[ITnetadmin]

Ik weet dat je een link-local enkel kunt automatisch laten genereren of static instellen.
Ik ben er gewoon zeker van dat er ergens ooit iemand even geergerd geraakt hieraan, dat er ofwel een tooltje, ofwel een heus protocol komt om die link-local suffix te syncen met een global suffix.

IPv6 is zeker niet dringend.
Maar de mogelijkheid om bovenstaande te doen zal toch een van mijn breekpunten worden, dat of ik wacht zolang tot het echt niet meer anders kan

Een ander puntje voor mij is NPT of NAT66, maar zelfs pfsense is not niet genoeg mee. Daar kan je ook geen global IP aan je LAN toekennen dat bestaat uit een fixed suffix, met automatische toevoeging van je global prefix. Of uberhaupt je link-local static instellen. Dat of ik moet er serieus over lezen.

No problem, ik heb geduld

[CCatalyst]

Ok; IPv6 implementeren heeft dus nog altijd een hele resem kinderziektes.
Software/firmware die moeilijk doet (bv vmware aanvaardt geen link-local adres als gateway, en synologie blijkbaar geen global adres als gateway)

Als je erop staat dat je adressen "leesbaar" moeten zijn (whatever that means), of dat IPv6 "eenvoudiger" moet zijn, is het misschien het beste om bij IPv4 te blijven. Dat heeft immers alles dat je wilt.

De recurring theme in je posts (en van nog enkelen hier) is dat je IPv6 wilt implementeren zoals IPv4, maar dat gaat nu eenmaal niet. Het feit dat je plots met 340,282,366,920,938,463,463,374,607,431,768,211,456 adressen werkt ipv 4,294,967,296 maakt dat onmogelijk.

Als je IPv6 gaat implementeren zoals het hoort, volgens de RFC's, dan ga je die problemen niet meer hebben. Wij deployen IPv6 probleemloos in bedrijven, en ook thuis doe ik dat met pfSense waar al mijn devices (met dual-stack) publieke IPv6's hebben. Ik snap niet waarom je het typische IPv4 NATting wilt daarbij, het herstellen van de end-to-end connectivity is immers een fundamentele doestelling van IPv6 (en van het internet!) en er zijn genoeg adressen om dat mogelijk te maken. Ik ben nog nooit een groot bedrijf tegengekomen waar een IP "leesbaar" of "te herkennen" moet zijn, als je werkt in bedrijven met meer dan 100.000 devices is dat ook gewoon niet mogelijk.

Ik denk dat je opties dus zijn om af te stappen van de IPv4-ideëen voor IPv6, ofwel om inderdaad te wachten "zolang tot het echt niet meer anders kan". Je zal zeker niet alleen zijn. Alhoewel het wel niet goed staat om als IT'er dingen te zeggen die deel uitmaken van de IPv6 Excuse Bingo.

Discussies pro en contra IPv6 toepassen zoals IPv4 ga ik niet meer voeren wegens onproductief. Ik kan alleen maar verwijzen naar de gepubliceerde RFC's die de referentie zijn en blijven en totaal ingaan tegen die IPv4-visies.

[ITnetadmin]

Zolang IPv6 er niet in slaagt om de grote nadelen op te lossen die IPv6 ondervindt zoals het problematische multihoming en dynamische adressen (waarvoor NPT of NAT66 tot nu toe nog altijd de beste fix zijn), en de firmware builders er niet in slagen om het juist te gebruiken (bv gateway als global IP of als linklocal?) zijn we idd nog ver van huis.
Zelfs Cisco lijkt aan te raden om op alle gateway poorten fe80::1 in te stellen, en het onderscheid op de router zelf te identificeren met een port ID, stijl fe80::1%FastEthernet0/1 bv.

Qua leesbaarheid: uiteraard eis ik een leesbaar IP adres.
Ik wil (bv) mijn servers in range ::1:xxxx , printers in ::2:xxxx, APs in 3::xxxx, enzovoorts enzoverder.
En dat suffix zowel in linklocal en global ip (en uniquelocal indien gebruikt).
Iets wat overigens binnen IPv6 perfect mogelijk is, alleen nog niet automatisch (de sync tussen linklocal en global bv).

En er zijn nog wel wat andere implementatie issues (bv tijdelijk een parallelle router hangen bij tests is een issue wanneer routers zichzelf adverteren, dus het netwerk zal ook zonder RAs moeten kunnen werken).

Ik geef grif toe dat ik tot de pragmatische kant van de IPv6 "oorlog" behoor, en niet de puristische kant.
En hoe meer IPv6 in aanraking komt met de werkelijke wereld van IT, hoe meer tools er zullen komen om IPv6 in het gewenste keurslijf te dwingen.

Als er momenteel nog geen antwoord op mijn vraag is, wacht ik wel af. Er komen nog wel mensen die graag de IP suffixen van 1 interface overal hetzelfde zouden zien.

[ITnetadmin]

Opvolging:

Dat automatisch correleren van je link-local suffix en je global suffix heb ik dan maar effe opzij geschoven.

Nu probeer ik handmatig mijn windows link-local address in te stellen, maar ik vind blijkbaar niet direct terug hoe je dat moet doen (ik neem aan via command line).
Weet er iemand het juiste commando?

[ubremoved_539]

Is er niets te vinden onder "netsh interface ipv6" ?

[ITnetadmin]

Ik vind niet direct iets terug.
Een adres met fe80 invullen en hopen dat ie automatisch doorheeft dat het een link local betreft zal wel wat te optimistisch zijn zeker?
En aangezien google echt echt echt geen resultaat geeft, behalve dan dat ene vraagje op iirc stackexchange, zonder antwoord, vrees ik er wat voor.

[lithion]

Ik heb al 8tal jaar IPv6 in productie en misschien toch even wat op een rij zetten.

• link-local -> kan niet gerouteerd worden (vandaar dat vmware dat niet aanvaardt als gateway en dat is geen kinderziekte, maar gewoon heel logisch) en begint altijd met FE80::/10 en de volgende 54 bits zijn altijd 0 (rfc4291).
• site-local -> kan wel gerouteerd worden. Begint altijd met FEC0::/10 waarbij de volgende 54 bits typisch het SITE ID aanduiden. Aangezien er onduidelijkheid was over die site ID is deze range deprecated. NIET GEBRUIKEN!
• unique local addresses (ULA)-> fc00::/7 range, is zoals de typische local IPv4 addressen (10.x.x.x en consoorten). De FC00::/7 hebben ze wel nog onderverdeel via de 8e bit (local bit) waardoor je dus een fc00::/8 en fd00::/8 blok krijgt. De eerste is nog niet defined (beschikbaar voor toekomstig gebruik), dus moet je FD00::/8 gebruiken. in IPv4 gedachten zou je dus deze range gebruiken voor je lokale adressen en dan via NAT internet aanbieden
• Global unicast addresses -> 2000::/3 range in IPv4 de typische publieke ip ranges

In praktijk gebruik ik echter altijd global unicast adressen waarbij onze firewall goed ingesteld staat. Sowieso staan de eerste 48 bits vast. De volgende 16 bits gebruiken we typisch om het vlan ID. In de laatste 64 bits gaan het IPv4 adres verwerken zonder de netwerk prefix. Concreet krijg je dan iets in de aard van bvb 2a0270:1 (vlan 100 en ip adres 10.0.0.1/24) of 2a0270:101::1 (vlan 101 en ip adres 10.0.1.1/24). De IPv4 gateway is typisch de ::1/.1 In de DNS zal de host dus altijd gekend zijn met zijn lokaal IPv4 adres en zijn publiek IPv6 adres. Andere toestellen communiceren via het toegewezen IPv6 adres en het link-local wordt nooit gebruikt. Het link-local adres met dezelfde suffix als zijn ULA of GUA klinkt even absurd als mac adres hetzelfde als ip adres.

In het geval van de OP moet er op de servers dus gebruik gemaakt worden van ULA's of GUA's. Link local is zoals een mac-adres: enkel van nut binnen een layer 2 netwerk. Het enige nut van link locak is voor NBP paketten en bij gebruik van bvb DHCPv6 zal een host zijn link local adres gebruiken om te communiceren met de DHCP server om een ander adres te verkrijgen.