Vraagje over de 169.254.0.0/16 range

[ITnetadmin]

Ik ben, kwestie van wat bijscholing, de geschiedenis van IPv4 aan het bestuderen.
Nu zit ik daar toch met een vraagje waarop ik voorlopig geen antwoord kan vinden.

Iedere ITer weet wel dat 169.254.0.0/16 de range is waarin een netwerkkaart die geen IP geconfigureerd krijgt (via static of DHCP) zelf een random IP autoconfigged, blijkbaar oorspronkelijk gebruikt door MS in APIPA.
De range is raar maar waar pas in detail beschreven in een RFC standaard in 2005 (RFC3927).
Voor de duidelijkheid: de range zelf is al terug te vinden in oudere RFCs, waaronder RFC3330, als zijnde voor link-local gebruik, maar zonder extra informatie over wanneer hij gereserved is, door wie, etc...

Uiteraard gaat ook elke ITer beamen dat die range (voor hetzelfde doeleinde) al veel langer in gebruik is dan 2005.
Alleen kan ik daar niet direct iets over terugvinden, noch in de RFCs, noch op google, en ik geraak ook niet aan oude ip whois informatie.

Weet iemand waar de oorsprong van deze range ligt?
Was die al langer reserved, of was het een prive range die MS in bezit had en de facto hiervoor gebruikte?
Ik kan geen historische informatie vinden, buiten het feit dat de originele range reservation uit 1998 dateert.

[dovo]

Aangezien ik nog maar een paar jaar oud was in 1998 kan ik niet veel meer over de originele reservatie vertellen. Wel kan ik nog een soortgelijke range aangeven: `128.0.0.0/16`. Als je in Juniper devices kijkt is dat de range die gebruikt wordt tussen de forwarding en de control plane om met elkaar te spreken. Ook deze heeft een beetje een rare geschiedenis The Curious Case of 128.0/16

Momenteel kom je `169.254.169.254` nog altijd tegen; op AWS, Openstack ... gebruikt men deze om de metadata te serveren op `169.254.169.254`. On boot gaat je virtuele machine een get request naar dit ip doen om zijn init configuratie alsook netwerk configuratie op te halen. En vermits de instance nog geen ipv4 heeft komt er dus een tijdelijk ipv4 in deze range op de interface, wat de connectie naar `169.254.169.254` mogelijk maakt. AWS was de eerste die hier mee begon voor zover ik weet.

[CCatalyst]

Zeer interessante vraag!

De range is raar maar waar pas in detail beschreven in een RFC standaard in 2005 (RFC3927).

De eerste draft hiervan was wel al in maart 2000. Bovendien had Microsoft al patent US6101499 genomen op APIPA in april 1998 (voor Windows 98) waar het adres ook al in vermeld stond. Daar stond in dat het subnet door IANA gereserveerd was voor "automatically generated IP network addresses". Volgens ARIN werd het inderdaad kort daarvoor, op 27 januari 1998, geregistreerd door IANA. Voordien was het gereserveerd voor ARIN maar het was (nog) niet in gebruik. Gezien de amper 3 maanden verschil tussen de registratie en het patent, weet je wel dat dit op vraag van Microsoft gebeurd zal zijn.

maar zonder extra informatie over wanneer hij gereserved is, door wie, etc...

De auteurs van de RFC zeggen eigenlijk genoeg. Microsoft, dat toen het top IT bedrijf van de VS was, zal hiervoor nog snel gelobbyd hebben bij IANA, dat toen nog niet onafhankelijk was maar wel gefund werd door DARPA, waar Microsoft ook oplossingen aan leverde. Enkele maanden later zou IANA onafhankelijk worden en zou dit ongetwijfeld veel moeilijker gegaan zijn. Dat gezegd zijnde hadden ze de assignment ook wel gewoon nodig voor Windows 98 dat zou uitkomen op 25 juni 1998 en voor het eerst de APIPA technologie had. Dan konden ze natuurlijk niet meer riskeren dat dat subnet nog publiek toegewezen zou worden.

Was die al langer reserved, of was het een prive range die MS in bezit had en de facto hiervoor gebruikte?

Met zekerheid weet ik het ook niet, maar op basis van wat ik zie was de range voor publieke adressen van ARIN voorzien, was ze nog niet in gebruik, had IANA voor Microsoft hun APIPA nood aan een ongebruikte range, ARIN was gezien het de Amerikaanse registrar was de minst delicate optie, en dus heeft ARIN die range weer aan IANA "moeten" teruggeven, iets wat ze zich later wellicht nog gaan beklaagd hebben. Een en ander lijkt weliswaar nog met de nodige "ons kent ons" en corporate pressure en achter gesloten deur beslist te zijn, wat toen nog kon (nu niet meer), en dat zal ook de reden zijn dat je er geen publieke documenten over kan vinden die de registratie predateren.

Je kan altijd eens proberen IANA te contacteren om deze vraag te stellen. Hou de mail en de vraag wel zeer kort (enkel de essentie), dan heb je veel meer kans op antwoord! Eventueel kan je ook de auteurs van de RFC eens proberen, je weet nooit. De mens die indertijd verantwoordelijk was voor IANA is wel al lang dood maar soit.

[ITnetadmin]

De mens die indertijd verantwoordelijk was voor IANA is wel al lang dood maar soit.

RIP John Postel, czar of socket numbers


EDIT: toch een paar extra opmerkingen

Wel kan ik nog een soortgelijke range aangeven: `128.0.0.0/16`. Als je in Juniper devices kijkt is dat de range die gebruikt wordt tussen de forwarding en de control plane om met elkaar te spreken. Ook deze heeft een beetje een rare geschiedenis The Curious Case of 128.0/16
Momenteel kom je `169.254.169.254` nog altijd tegen; op AWS, Openstack ... gebruikt men deze om de metadata te serveren op `169.254.169.254`. On boot gaat je virtuele machine een get request naar dit ip doen om zijn init configuratie alsook netwerk configuratie op te halen. En vermits de instance nog geen ipv4 heeft komt er dus een tijdelijk ipv4 in deze range op de interface, wat de connectie naar `169.254.169.254` mogelijk maakt. AWS was de eerste die hier mee begon voor zover ik weet.

Dat is gewoon misbruik van een reserved range; dat kom je wel vaker tegen.
Ter info, toen de classful blocks nog bestonden (en eigenlijk is dat nog zo, want iedereen denkt nog altijd "die range zit in block a/b/c") zijn de eerste en de laatste ranges van elke block gereserveerd.
Dat waren dan
0.0.0.0/8 (een technical reservation voor "this host" adressen)
127.0.0.0/8 (nog een technical reservation, want John Postal besliste om daar 1 adres uit te gebruiken, nl 127.0.0.1 voor localhost)
128.0.0.0/16 (jouw voorbeeld), 191.255.0.0/16, 192.0.0.0/24, 223.255.255.0/24 (allen gereserveerd voor "future use")
De future use reservaties zijn intussen komen te gaan.

Maar veel IPs worden gewoon misbruikt. Een van de redenen waarom 10.0.0.0/8 prive werd is omdat de IP space so poisoned was na het gebruik ervan door de ARPANet backbone.
De 3 test-net IPs (bv test-net-1, 192.0.2.0/24, reserved for documentation) worden al vaak gebruikt voor inter-company routing, omdat ze zoeken naar een range die niet gebruikt werd (vooral bij het fuseren van bedrijven een gigantisch issue).

127.0.0.0 wordt gebruikt voor andere IPs te binden aan de localhost om bv multi-dns te simuleren (127.0.0.2, 127.0.1.1, etc); veel mensen zijn dus ook al pissed dat IPv6 enkel en alleen ::1/128 als localhost reserveert; of hoe practical use als water is en overal dingetjes naar zijn hand zet die de theoretici dan missen bij het uitdenken van vervangers.

169.254.0.0/16 is strict gereserveerd voor local link autoconfig. AWS misbruikt dat dus duidelijk.
Weetje: niet de hele block mag gebruikt worden; de eerste en laatste /24 zijn reserved for future use; de werkelijke use space is dus exclusief 169.254.0.0/24 en 169.254.255.0/24.

Er zijn ook discussies om de laatste /4 vrij te geven (240.0.0.0/8 tot 255.0.0.0/8), zowel voor public use (niet dat het veel uitstel gaat geven), maar ook voor private use (een extensie van de rfc1918 adressen); maar tot nu toe weinig animo voor.
Het argument tegen public use is dat de vrijgegeven adressen maar enkele jaren uitstel zouden geven, en (vooral) dat de meeste internet routers hardcoded zijn om ze te weigeren.
Ook 0.0.0.0/8 wordt gepushed om vrijgegeven te worden.

[dovo]

Er zijn ook discussies om de laatste /4 vrij te geven (240.0.0.0/8 tot 255.0.0.0/8), zowel voor public use (niet dat het veel uitstel gaat geven), maar ook voor private use (een extensie van de rfc1918 adressen); maar tot nu toe weinig animo voor.
Het argument tegen public use is dat de vrijgegeven adressen maar enkele jaren uitstel zouden geven, en (vooral) dat de meeste internet routers hardcoded zijn om ze te weigeren.

En ook die laatste /4 wordt misbruikt. Bijvoorbeeld door ubunutu fan

Het was me ook nog niet opgevallen dat systemd-resolved inderdaad alleen op ipv4 luistert, en niet op v6. Ziet ernaar uit dat Poettering het ook niet dual stack zal gaan maken. Aangezien het localhost trafiek is maakt het inderdaad ook niet echt uit of het v4 of v6 is, maar wel jammer dat hier in het design van v6 niet aan gedacht is.

Code: Selecteer alles

LISTEN0      128                          127.0.0.53%lo:53         0.0.0.0:*     users:(("systemd-resolve",pid=1120,fd=13))