Waarom is fe80 :: / 10 gereserveerd voor link local-adressen terwijl fe80 :: / 64 daadwerkelijk wordt gebruikt?

Ik denk de link-local scope was ingesteld op / 10 simpelweg om beter te “passen” bij de andere scopes, bijv site-local (voordat het werd vervangen door unique local).

Aanvankelijk dacht ik dat het misschien was om het gebruik van veel link-local-netwerken op dezelfde link toe te staan, maar RFC 4291 stelt expliciet dat alleen fe80 :: / 64 mag worden gebruikt.

Opmerkingen

• Is er een betekenis met betrekking tot SLAAC-implementatie? … is SLAAC " prefix agnostisch "?
• SLAAC vereist een / 64, maar het is niet echt relevant hier, omdat link-local adressen niet ' t zijn toegewezen door SLAAC – in feite vertrouwt SLAAC op het al een link-local adres hebben.

Weet je, ik heb dit nooit overwogen.

Ik neem aan dat fe80 :: / 64 wordt gebruikt omdat systemen voeren vervolgens stateless address autoconfiguration (SLAAC) uit in die / 64. De rest van de / 10 beschikbaar laten voor statisch toegewezen link-local adressen en netblocks. Ik heb moeite met het bedenken van significante use-cases voor statische link-local opdrachten, maar ik neem aan dat er redenen zijn waarom mensen dit uiteindelijk zouden willen doen.

Opmerkingen

• Wat ' is de significantie van SLAAC en / 64? … is er iets inherent aan SLAAC met het / 64-voorvoegsel?
• soms maken statisch toegewezen lokale linkadressen het gemakkelijk om te weten welk knooppunt de volgende hop is bij dynamische routing, dwz R1 is fe80 :: 1 / 64, R2 is fe80 :: 2/64, enz. Werkt goed in het lab, misschien minder in de praktijk.
• @CraigConstantine – ja, SLAAC heeft de / 64-grens hard gecodeerd in het protocol. Dat is de reden dat u in IPv6 geen subnetten kunt maken die kleiner zijn dan a / 64, met uitzondering van subnetten die worden gebruikt voor het routeren van links (d.w.z. voor een point-to-point-link moet u een / 127 gebruiken). Er zijn eigenlijk andere protocollen die ook de / 64-grens hebben ingebakken.
• We hebben een use-case. Een procesisolatiesysteem dat de isolatieomgeving moet oproepen met een bekend link-local adres voor op IPv6 gebaseerde identificatie. En we kunnen ' niet wachten op DAD, omdat de omgeving klaar moet zijn in microseconden of milliseconden.

De ontwerpfilosofie achter IPv6 is dat het hebben van een redelijk gestructureerde adresruimte belangrijker is dan het bewaren van adressen. Overigens is IPv4 bedacht met hetzelfde idee (daarom heeft elk apparaat 16 miljoen loopback-adressen, maar gebruikt het alleen het 127.0.0.1-adres, en de meeste klasse D- en E-adressen zijn ongebruikt).

Link-local-adressen verspillen in theorie miljarden IP-adressen, maar het wordt niet als een probleem beschouwd. Evenzo is het technisch gezien erg verkwistend om elke klant een volledige / 56 of zelfs / 48 te geven, maar niet echt een probleem.

Er zit een donkere kant aan deze benadering: de bewering dat IPv6 een IP-adres kan geven aan elke zandkorrel ter wereld (of iets dergelijks) is onzin, net zoals de bewering dat IPv4 4 miljard apparaten kan ondersteunen. realiteit, tegen de tijd dat je alle verspilling in IPv6 bij elkaar optelt, zul je merken dat de limieten veel smaller zijn (nog steeds groter dan IPv4).

Ik denk dat het neerkomt op 2 dingen. Ten eerste kan een link-local niet worden gerouteerd, dus is er geen subnet-ID nodig. Aangenomen wordt dat, aangezien het niet kan worden gerouteerd, dat alles wat volgt op het voorvoegsel tot de laatste 64 bits nul zal zijn. Ten tweede, net als andere vergelijkbare IPv6-voorvoegsels, is het voorvoegsel alles tot aan het laatste “1” -bit. consistentie.

Opmerkingen

• Als het zo werkte, zou het een /9 niet een /10.