“IPv10”은 농담입니까 아니면 심각한 RFC 초안입니까?


72

인터넷 프로토콜 버전 10 (IPv10) 사양

이름은 웃기지 만 (IPv4 + IPv6 == IPv10) 실제 제안은 이상하게 보입니다 (패킷 형식 간의 비 호환성을 막기 위해 하나 이상의 패킷 형식).

진지한 얼굴로 "IPv10"을 즐기기 위해 장단점이 균형을 이루는 최소한의 가능한 문서입니까?

심각한 경우 "tl; dr"형식으로 설명하십시오. 왜 이것이 nat64 / teredo와 같은 다른 전환 기술이 아닌가?


9
처음에 링크를 따라갈 때 나는 "4 월 1 일"을 볼 것으로 예상했다.
Vi.


4
제안은 농담 일 수 있지만 그 이름은 아닙니다. IPv4 ~ IPv9는 이미 예약되어 있습니다 (IPv4와 IPv6 만 사용됨). IPv10은 사용 가능한 다음 할당되지 않은 버전입니다.
user4556274

5
32 비트 ASN 이미 관행 때 흥미롭게도 저자는 ASN 필드에 16 비트를 사용하는 제안
하겐 폰 Eitzen

4
4 월 1 일에 전통적으로 출판 된 가벼운 RFC의 훌륭한 전통이 있습니다. en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments 는 시작하기 좋은 곳입니다.
Dominic Cronin

답변:


84

Ron이 말했듯이 누구나 제안서를 작성할 수 있습니다. 그래도 위성과 광섬유의 상호 연결 을 제안하는 사람의 제안을 진지하게 받아들이는 데 어려움을 겪고 있습니다.

또한,이 실제 제안이 추진력을 얻는다고 상상할 수 없습니다. 특히이 메모로 인해 :

사용 된 IP 버전에 관계없이 통신 할 수 있으려면 인터넷에 연결된 모든 호스트가 IPv10 호스트 여야하며 IPv10 배포 프로세스는 호스트 네트워킹 및 보안 장치 용 OS를 개발하는 모든 기술 회사에서 수행 할 수 있습니다.

따라서 IPv4 전용 호스트가 IPv6 전용 호스트와 통신 할 수없고 그 반대의 문제를 해결하려면 다른 프로토콜 인 IPv10 을 구현해야합니다 . 그렇다면 왜 IPv4 전용 호스트에서 IPv6을 구현하는 것이 아니라 그로 인해 귀찮게합니까?

또한 RFC7059 에서 읽을 수 있듯이이 문제의 일부를 해결하는 데 사용할 수있는 충분한 터널 메커니즘이 이미 있습니다.

솔직히 말해서 저자는 다음 트윗 에서 읽을 수 있듯이 저작권을 주장함으로써 상업적인 성공을 기대하고 있습니다 .

발표 : 저작권 보호, # IPv10 및 KHALED 라우팅 프로토콜 (#KRP 또는 #RRP)은 @The_Road_Series CEO가 개발했습니다.

개발자 @Eng_Khaled_Omar의 승인없이 조직에서 발표하거나 발표해서는 안됩니다.

2017 년 5 월 26 일 오늘, 저장소에서 # IPv10 #KRP (#RRP) 초안을 제거하라는 두 번째 요청이 ietf로 전송되었습니다.


15
당신은 그들이 말하는 것을 알고 있습니다-너무 많은 추상화 계층의 문제를 제외하고 다른 추상화 계층의 모든 문제를 해결할 수 있습니다!
bye

13
광섬유로 연결된 위성에서의 ROFL. IPoAC만큼 합리적으로 들립니다.
reirab

14
그는 저작권으로 인해 운이 없다. 그는 IETF 정책을 준수하지 않는 문서 내용에 관계없이 RFC 프로세스에 참여함으로써 IETF에 저작권을 이미 부여했습니다 .
user207421

14
RFC 형식으로 읽은 내용을 암시 적으로 신뢰하지 않도록 뇌를 다시 훈련시킬 시간입니다.
Matt

6
Tweet link my day (/ week / month)
Failed Scientist

27

누구든지 IETF에 제안서를 제출할 수 있으며 관심이 없어서 채택되거나 죽을 때까지 진지하게 받아 들여집니다.

이 특정 제안은 저자에 의해 여러 번 만료 및 갱신되었습니다. 지원이 많지 않은 것으로 보이며 제안 된 RFC 상태 (예 : 표준 트랙)도 없습니다. 저자는 아마도 그의 제안에 대해 진지하지만, 그 제안에 대한 진지한지지를 얻지 못한 것 같습니다.

일몰 IPv4 에 대한 진지한 제안이 있으며, 그 뒤에 완전한 실무 그룹이 있지만, 완전히 채택하기에는 아직 길지 않은 길입니다. IPv4에서 IPv6으로의 전환에 내재 된 문제를 해결하려고합니다.


19

“IPv10”은 농담입니까 아니면 심각한 RFC 초안입니까?

양자 모두. 나는 녀석이 심각하고 그가 제안한 어리석은 계획을 얻지 못한다고 생각합니다. 농담이 그에게 있습니다.

섬유 위성 제안 은 섬유 길이가 필요하고 완전히 궤도 역학을 무시 무시로 더욱 우스꽝입니다.

IETF는 트롤을 막아야합니다.



1

실제 문제를 해결하려는 진지한 시도입니다. 솔루션이 좋든 나쁘 든 (아마도 쓰레기 일지라도) 문제 설명은 정확합니다. IPv6을 구현하려는 현재 전략은 지금까지 실패했습니다. 소개에서 알 수 있듯이 19 년의 IPv6은 여전히 ​​의미있는 방식으로 전환 한 것을 볼 수있는 방법이 없습니다.

언급했듯이 우리는 이미 NAT64와 같은 브리징 솔루션을 가지고 있습니다 (다른 것들도 언급합니다). 이것들은 훌륭하지만 훌륭하지만 여전히 IPv6으로 완전히 전환 할 수는 없습니다. 공개 IPv4 전용 호스트가 여기에 있다고 가정합니다.

즉, IPv6으로의 전환에 근본적인 문제 가 있다고 생각하면이 사양이 어떻게 도움이 될지에 대해서는 회의적 입니다. 나는 그것이 시도하는 방법을 이해하려고 많은 시간을 소비하지 않았으며 어쩌면 나보다 현명한 것일 수도 있지만 (다른 답변 중 합의가 내가 옳다는 것을 암시하지만) 처음.

그러나 대답은 여전히 ​​문제를 해결하기위한 진지한 시도입니다.


1
몇 년 동안 모든 것이 IPv6에 준비되었습니다. 실제 채택은 느리게 보일 수 있으며 그 이유는 IPv4가 여전히 "작동"하기 때문입니다. 그러나 IPv6 트래픽은 약 20 %이며 상당히 빠르게 증가하고 있습니다. 2017 년에 IPv6을 제공하지 않는 인터넷 서비스는 실제로 그 위치를 재고해야합니다. 우리가 지금 정말로 필요로하지 않는 것은 또 다른 전환 메커니즘입니다.
ch7kor

모두 사실입니다. 그러나 IPv6은 결코 의미있는 보급률에 도달 할 수 없다고 생각합니다 (처음 20 %는 가장 쉬운 것으로 가정하고 마지막 20 %는 훨씬 더 어려워 야 함). 전환을 용이하게하기위한 기술에 관한 문제는 일단 오래 사용 되면 새로운 인터넷 이 되었다는 것을 깨닫게 됩니다.
thomasrutter

3
실제로 IPv6에 인터넷 트래픽의 80 %가 있으면 일몰 IPv4에 대한 제안이 표준이되고 대부분의 ISP가 IPv4 트래픽 라우팅을 중지하기 때문에 마지막 20 %가 가장 쉽다고 주장 할 수 있습니다. IPv4 트래픽이 (IPv6) 인터넷을 통해 터널링되도록 IPv6의 시작과 상황이 반대로됩니다.
Ron Maupin

0

새로운 프로토콜의 구현에는 약간의 타당성이 있습니다. 현재 번역 프로토콜은 NAT64입니다.

NAT64는 NAT (Network Address Translation) 형식을 사용하여 IPv6과 IPv4 호스트 간의 통신을 용이하게하는 IPv6 전환 메커니즘입니다. NAT64 게이트웨이는 IPv4와 IPv6 프로토콜 사이의 변환기이며, 1의 기능을 위해서는 적어도 하나의 IPv4 주소와 32 비트 주소 공간을 포함하는 IPv6 네트워크 세그먼트가 필요합니다. IPv6 클라이언트는 IPv6 네트워크 세그먼트의 호스트 부분을 사용하여 통신하려는 IPv4 주소를 임베드하여 IPv4 내장 IPv6 주소 (IPv6 네트워크 세그먼트의 32 비트 주소 공간)를 생성하고 패킷을 결과 주소. NAT64 게이트웨이는 IPv6과 IPv4 주소 간의 매핑을 생성하며,이 주소는 수동으로 구성하거나 자동으로 결정될 수 있습니다.

출처

IPv10의 주요 아이디어는 NAT64를 제거하는 것입니다. 엄밀히 말하면 NAT는 항상 병목 현상이었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.