Zag wat voorbij komen. over IPv8 draft.
Nog minder privacy?
Grappig. Het eerste wat ik deed is naar de publicatiedatum kijken, April Fools RFCâs zijn ook een ding en dit rook er verdacht veel naar 
.
Ik zie niet zo zeer meer dreiging voor privacy in IPv8. Gezien de al moeilijke adoptie van IPv6 verwacht ik van IPv8 nog minder aangezien dat aanzienlijk meer nodig heeft dan het configureren van een extra adres op een interface:
Dat belooft wat⊠voor mijn achterkleinkinderen . We zijn er in 32 jaar nog niet in geslaagd IPv6 gemeengoed te maken, ook in dit kleine landje niet.
Al rond 1994 hield Erik Huizer van SURFnet lezingen over IP Next Generation (IPng), wat later IPv6 is geworden. De boodschap: IPv4 hebben we nu nog even nodig, maar het heeft zo veel tekortkomingen dat we er zo snel mogelijk weer van af moeten.
Maar bedankt voor de tip, wel de moeite waard om even naar te kijken. Maar ook: iedereen kan een IETF draft indienen, dit is geen RFC.
Ach, het is simpeler om je gehele stack om te bouwen naar iets dat âalleen maarâ een 4 tal extra octets voor het ip adres plakt dan een al 30 jaar bestaande stack gebruiken die toch al overal in zit.
Vage gedachtengang, Azie is al over naar 6, alleen de US wil niet. DIe willen wel meer niet, laat ze.
Hangt van het onderdeel in de US af.
Verizon & Co waarschijnlijk niet, IPv4 boeren waarschijnlijk niet omdat die denken veel geld in IP addressen te hebben die in eens waardeloos worden.
Liberty Global (ie Ziggo) was eerst van plan om iedere abonnee EEN IPv6 /128 adres te leverenâŠ, toen na een paar jaar bleek dat die niet geheel haalbaar was ⊠zijn ze alsnog een soort van normale implementatie te gaan doenâŠ
Met name Google en andere hyper scalers dien IPv6 wel degelijk zitten, maar ja die zitten aan de andere kant van de IPv4 voorraad.
Er zijn ook andere voorstellen zoals alle Multicast adressen weer unicast verklarenâŠ, probleem alle multicast applicatiesâŠ., en alle systemen die verwachten dat Class D adressen multicast zijn.
IPv4 modified betekent gewoonde klok 30 jaar terug zetten en opnieuw beginnen, waarbij een heleboel zaken complexer worden in beheer. Naast NAT krijg je nu ook een routerings laag extra.
En waarvoorâŠ., IPv6 is minder complex, meer flexibel, en een helebooel factoren groter dan IPv8 of IPv4 + NAT kan bieden.
IP protocol stack is juist bedoeld voor een platte communicatie structuur. Helaas is door kunstgrepen als NAT etc. dat om zeep geholpen, met alle ellende van dien. Kijk eens was e allemaal nodig is om een omgeving die achter NAT zit nog te laten functioneren als Server (bv. VOIP achter nat).
Hoi
Er is een verschil tussen 224/4 en 240/4;
224/4 is multicast. 240/4 is reserved for future use. Er is dus discussie over 240/4 gaan gebruiken, niet de status van 224/4 veranderen.
Een idee is om 240/4 uitsluitend uit te delen aan nieuwe providers. Dit omdat juist die problemen hebben met het verkrijgen van IPv4 adressen. Het gaat hierbij om in totaal 2ÂČâž = 268435456 IPv4 adressen. Maar die zijn natuurlijk ook een keer op.
Persoonlijk heb ik geen bezwaar tegen 240/4, maar IPv4 is natuurlijk wel een doodlopende weg.
En over 1 april. Er is er ook een RFC voor TCP via postduif.
Vr.Gr,
Rob
Dit soort voorstellen komen geregeld voorbij. Deze draft is inmiddels expired en lijkt geen tractie hebben gekregen binnen de IETF [1]
In essentie betreft het een voortel voor variabele adres-lengte. Dat is in de IPng werkgroep ook uit en ter na besproken.
Maar zelf al veel eerder was het onderwerp van de meest verhitte discussies tijdens het ontwerp van IPv4. Danny Cohen, die groot voorstander was van variabele adres-lengte, heeft daarop het het beroemde, satirische, IEN137 (Internet Experiment Notes 137) gepubliceerd [2].
Dit document, âOn Holy Wars and a Plea for Peaceâ is vooral beroemd vanwege de introductie de termen âBig-Endianâ en âLittle-Endianâ, voor de bitvolgorde. Maar het is geschreven tegen de achtergrond van de toen woedende âheilige oorlogâ rond de adresstructuur.
Achteraf bezien is het jammer dat Danny en zijn medestanders het hebben verloren van de âstarrenâ die een vaste adres-lengte wilden. Maar in die tijd was het ook wel begrijpelijk om daar voor te kiezen.
[1] https://mailarchive.ietf.org/arch/search/?q=draft-thain-ipv8
[2] https://www.rfc-editor.org/ien/ien137.txt
Ik had informatie dat het ook over de Multicast ging, ik kan het artikel niet meer vinden (bitrot, niet op archive), en dat claimde ook Multicast omdat de schrijver dat âongebruiktâ achte.
anyways. Ook voor class E gebruik vereist aanpassingen in ten minste een deel van de software, ook software waar al jaren geen updates meer voor komt. (Routers etc.)
Over de 1 April RFCâs die zijn er meer dan alleen de postduif variant, er is zelf een ping test met een postduif. (QoS, 1999).(P
Dit jaar weren het:
RFC 9948: IPP (Internet Protocol Police), schedule of punishments
RFC 9949: BUSA-TLS, Mandatory Audio Component (MAC) Pre-Shared Key SK) Derivation for TLS1.3 Using 2 Live Crews âBanned in the USAâ
https://en.wikipedia.org/wiki/April_Foolsâ_Day_Request_for_Comments
Class D en E aanpassingen zijn een no-go. IPv4 is in professionele apparatuur ook in hardware geĂŻmplementeerd. Dat is een can of worms die de mensen met verstand van zaken niet open willen trekken.
Het is echter wel mogelijk om intern, voor apparatuur waar je zelf alle controle over hebt, class E te gebruiken. Daar meen ik ooit een presentie over te hebben gezien bij NLNOG maar ik kan ik niet zo snel terugvinden.
En RFC3514 is mijn persoonlijke favoriete 1 april RFC [1].
Hoi
224/4 en 240/4 worden wel vaker op een hoop gegooid als 224/3. Je moet soms wat dieper spitten om te zien dat het twee verschillende dingen zijn.
Maar met 240/4 loop je tegen dingen aan als dat Linux en Mac OS X het out of the box ondersteunen en MS Windows niet. Er was ooit plan om te inventariseren wat er allemaal niet werkt. Maar zelfs als je alles fikst, het is zo op.
Er is maar Ă©Ă©n manier om de problemen op te lossen en dat is IPv6 ondersteuning verplichten. Niet voor het antiek op de LAN. Maar toch wel op het globale internet.
Vr.Gr,
Rob
Je kan ook naar RFC 1149 - Standard for the transmission of IP datagrams on avian carriers (IPoAC) , is al wat ouder (proven technology?), maar er is ook een RFC voor QoS over RFC 1149, tw. RFC 2549 - IP over Avian Carriers with Quality of Service .
En wie kan er zonder RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) dan wel RFC 7168: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
Collectie:
https://en.wikipedia.org/wiki/April_Foolsâ_Day_Request_for_Comments
Zo jammer dat deze zo vaak gemist is: RFC 9225: Software Defects Considered Harmful RTFM zou moeten helpen.
RFC 1149 is proven technology ja: Rfc1149s | Bergen Linux User Group