Este „IPv10” o glumă sau un proiect RFC serios? (Ingineria rețelelor, Ipv4, Ip, Ipv6, Rfc, Tranziție Ipv6)

Vi. a intrebat.

Specificația protocolului Internet versiunea 10 (IPv10)

Numele este amuzant (IPv4 + IPv6 == IPv10), dar propunerea reală pare ciudată (încă un format de pachete pentru a lupta împotriva incompatibilității dintre formatele de pachete).

Este o propunere normală, cu argumente pro și contra echilibrate, sau doar un document minim viabil pentru a face mișto de „IPv10” cu o față serioasă?

Dacă este serios, vă rugăm să îl descrieți în mod „tl;dr”. De ce aceasta și nu o altă tehnologie de tranziție precum nat64/teredo?

Comentarii

  • Când am urmat inițial link-ul de acolo, mă așteptam să văd „1 aprilie”. –  > Por Vi..
  • XKCD obligatoriu? –  > Por A C.
  • În timp ce propunerea poate fi o glumă, numele nu este. De la IPv4 la IPv9 sunt deja rezervate (deși sunt utilizate doar IPv4 și IPv6). IPv10 este următoarea versiune disponibilă neatribuită. –  > Por user4556274.
  • Este interesant faptul că autorul propune utilizarea a 16 biți pentru câmpul ASN, în condițiile în care ASN de 32 de biți sunt deja o practică obișnuită –  > Por Hagen von Eitzen.
  • Există o frumoasă tradiție de RFC-uri ușoare, publicate în mod tradițional la 1 aprilie. en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments este un bun punct de plecare. –  > Por Dominic Cronin.
5 răspunsuri
Teun Vink

După cum a spus Ron, oricine poate scrie o propunere. Mi-e greu să iau în serios propunerile venite din partea cuiva care sugerează interconectarea sateliților cu fibre optice, , totuși.

De asemenea, nu-mi pot imagina că această propunere actuală va lua amploare, mai ales din cauza acestei note:

Toate gazdele conectate la internet trebuie să fie gazde IPv10 pentru a putea comunica indiferent de versiunea IP utilizată, iar procesul de implementare a IPv10 poate fi realizat de TOATE companiile tehnologice care dezvoltă sisteme de operare pentru gazde de rețea și dispozitive de securitate.

Așadar, pentru a rezolva problema gazdelor care utilizează numai IPv4 și care nu pot comunica cu gazde care utilizează numai IPv6 (și viceversa) trebuie să implementați un alt protocol: IPv10. Atunci, de ce să te deranjezi cu asta și să nu implementezi pur și simplu IPv6 pe acea gazdă numai IPv4 și să termini cu asta.

În plus, după cum se poate citi în RFC7059, , există deja mai mult decât suficiente mecanisme de tuneluri disponibile care pot fi utilizate pentru a rezolva o parte din această problemă.

Sincer să fiu, cred că autorul speră la un oarecare succes comercial prin revendicarea drepturilor de autor, după cum se poate citi în aceste tweet-uri:

ANUNȚ: Protejând drepturile de autor, Protocolul de rutare #IPv10 și KHALED (#KRP sau #RRP) sunt dezvoltate de către CEO-ul @The_Road_Series.

Acestea NU TREBUIE să fie reprezentate sau publicate de nicio organizație fără aprobarea dezvoltatorului lor @Eng_Khaled_Omar

Astăzi, 26 mai 2017, a fost trimisă o a 2-a solicitare către ietf pentru eliminarea proiectelor #IPv10 #KRP (#RRP) din depozitul lor.

Comentarii

    15

  • Ei bine, știți ce se spune – poți rezolva toate problemele cu un alt strat de abstractizare, cu excepția problemei prea multor straturi de abstractizare! –  > Por La revedere.
  • ROFL la sateliții legați prin fibră optică. Sună la fel de rezonabil ca și IPoAC. –  > Por reirab.
  • 15

  • Nu mai are noroc cu drepturile de autor. El a cedat deja drepturile de autor către IETF prin implicarea în procesul RFC, indiferent de ceea ce scrie în textul documentului, care nu este conform cu politicilor IETF. –  > Por utilizator207421.
  • 15

  • E timpul să-mi reeduc creierul să nu mai aibă încredere implicită în tot ceea ce citesc în format RFC. –  > Por Matt.
  • Tweet link mi-a făcut ziua(/săptămâna/luna) –  > Por Cercetător ratat.
Ron Maupin

Trebuie să vă amintiți că oricine poate trimite propuneri către IETF, iar acestea sunt luate în serios, până când sunt adoptate sau mor din lipsă de interes.

Această propunere specifică a expirat și a fost reînnoită de autor de mai multe ori. Nu pare să aibă prea mult sprijin, dacă nu chiar niciunul, și nici măcar nu are un statut de RFC propus, de exemplu, Standards Track. Probabil că autorul este serios în privința propunerii sale, dar nu pare să fi obținut niciun sprijin serios pentru aceasta.

Există o propunere de retragerea IPv4 pe care este serioasă și are în spate un grup de lucru complet, dar are în față un drum lung și greu până la adoptarea completă. Aceasta intenționează să abordeze problemele inerente tranziției de la IPv4 la IPv6.

Zac67

Este „IPv10” o glumă sau un proiect RFC serios?

Ambele. Cred că tipul ăla e serios și nu înțelege ce scheme ridicole propune. Gluma e pe seama lui.

The Propunerea Fiber Satellite este și mai ridicolă, deoarece neglijează lungimile de fibră necesare (265.000 km pe orbită la altitudine geosincronă) și ignoră complet mecanica orbitală (este absolut imposibil să menții sateliții pe orbite diferite la aceeași distanță).

IETF ar trebui să-l blocheze pentru trolling.

Comentarii

thomasrutter

Este o încercare serioasă de a rezolva o problemă reală. Indiferent dacă soluția este bună sau proastă (probabil că este o porcărie), enunțul problemei este corect: strategia actuală de a încerca să implementeze IPv6 a eșuat până în prezent. După cum se spune în introducere, după 19 ani de IPv6, încă nu putem considera că am făcut tranziția într-un mod semnificativ.

După cum se menționează, avem deja unele soluții de tranziție, cum ar fi NAT64 (menționează și altele). Acestea sunt bune și frumoase, dar nu permit nici ele o tranziție completă la IPv6 – ele presupun că gazdele publice care utilizează doar IPv4 sunt aici pentru a rămâne.

Acestea fiind spuse, sunt sceptic cu privire la modul în care această specificație ar putea fi de ajutor, având în vedere ceea ce văd sunt probleme fundamentale cu tranziția la IPv6. Nu am petrecut prea mult timp încercând să înțeleg cum încearcă să o facă și poate că este mai înțelept decât mine (deși consensul dintre celelalte răspunsuri sugerează că am dreptate), dar pare să sufere de aceeași problemă de bootstrap pe care o are IPv6 în primul rând.

Pentru a răspunde la Dar este totuși o încercare serioasă de rezolvare a problemei.

Comentarii

  • Totul este pregătit pentru IPv6 de ani de zile. Adoptarea efectivă poate părea lentă, iar motivul este doar pentru că IPv4 încă „funcționează”. Cu toate acestea, traficul IPv6 este de aproximativ 20% și crește destul de repede. În 2017, un serviciu de internet care nu oferă IPv6 ar trebui să își reconsidere poziția. Nu avem nevoie acum de un alt mecanism de tranziție. –  > Por ch7kor.
  • Totul este adevărat. Dar cred că IPv6 nu va atinge niciodată o penetrare semnificativă (primele 20% ar trebui să fie cele mai ușoare, ultimele 20% ar trebui să fie mult mai dificile) și, într-o zi, oamenii vor decide o altă cale de urmat. Problema cu tehnologiile menite să ușureze tranziția este că, odată ce au fost folosite suficient de mult timp, îți dai seama că au au devenit noul internet. –  > Por thomasrutter.
  • De fapt, s-ar putea spune că ultimii 20% vor fi cei mai ușori, deoarece atunci când IPv6 va reprezenta 80% din traficul pe internet, propunerea de a elimina IPv4 va fi probabil standardul, iar majoritatea furnizorilor de servicii de internet vor înceta să mai ruteze traficul IPv4. Situația va fi inversată de la începutul IPv6, astfel încât traficul IPv4 va trebui să fie tunelat pe Internet (IPv6). –  > Por Ron Maupin.
schnipdip

Implementarea unui nou protocol are o anumită valabilitate. Actualul protocol de traducere este NAT64.

NAT64 este un mecanism de tranziție IPv6 care facilitează comunicarea între gazdele IPv6 și IPv4 prin utilizarea unei forme de traducere a adreselor de rețea (NAT). Gateway-ul NAT64 este un translator între protocoalele IPv4 și IPv6,1 pentru care are nevoie de cel puțin o adresă IPv4 și un segment de rețea IPv6 care cuprinde un spațiu de adrese pe 32 de biți. Un client IPv6 încorporează adresa IPv4 cu care dorește să comunice folosind partea gazdă a segmentului de rețea IPv6, rezultând astfel o adresă IPv6 încorporată în IPv4 (de unde spațiul de adrese pe 32 de biți în segmentul de rețea IPv6) și trimite pachete la adresa rezultată. Gateway-ul NAT64 creează o corespondență între adresele IPv6 și IPv4, care poate fi configurată manual sau determinată automat.

Sursa

Ideea principală pentru IPv10 ar fi eliminarea NAT64. Strict vorbind, NAT a fost întotdeauna un blocaj.