이름은 웃기지 만 (IPv4 + IPv6 == IPv10) 실제 제안은 이상하게 보입니다 (패킷 형식 간의 비 호환성을 막기 위해 하나 이상의 패킷 형식).
진지한 얼굴로 "IPv10"을 즐기기 위해 장단점이 균형을 이루는 최소한의 가능한 문서입니까?
심각한 경우 "tl; dr"형식으로 설명하십시오. 왜 이것이 nat64 / teredo와 같은 다른 전환 기술이 아닌가?
이름은 웃기지 만 (IPv4 + IPv6 == IPv10) 실제 제안은 이상하게 보입니다 (패킷 형식 간의 비 호환성을 막기 위해 하나 이상의 패킷 형식).
진지한 얼굴로 "IPv10"을 즐기기 위해 장단점이 균형을 이루는 최소한의 가능한 문서입니까?
심각한 경우 "tl; dr"형식으로 설명하십시오. 왜 이것이 nat64 / teredo와 같은 다른 전환 기술이 아닌가?
답변:
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로 전송되었습니다.
누구든지 IETF에 제안서를 제출할 수 있으며 관심이 없어서 채택되거나 죽을 때까지 진지하게 받아 들여집니다.
이 특정 제안은 저자에 의해 여러 번 만료 및 갱신되었습니다. 지원이 많지 않은 것으로 보이며 제안 된 RFC 상태 (예 : 표준 트랙)도 없습니다. 저자는 아마도 그의 제안에 대해 진지하지만, 그 제안에 대한 진지한지지를 얻지 못한 것 같습니다.
일몰 IPv4 에 대한 진지한 제안이 있으며, 그 뒤에 완전한 실무 그룹이 있지만, 완전히 채택하기에는 아직 길지 않은 길입니다. IPv4에서 IPv6으로의 전환에 내재 된 문제를 해결하려고합니다.
“IPv10”은 농담입니까 아니면 심각한 RFC 초안입니까?
양자 모두. 나는 녀석이 심각하고 그가 제안한 어리석은 계획을 얻지 못한다고 생각합니다. 농담이 그에게 있습니다.
섬유 위성 제안 은 섬유 길이가 필요하고 완전히 궤도 역학을 무시 무시로 더욱 우스꽝입니다.
IETF는 트롤을 막아야합니다.
실제 문제를 해결하려는 진지한 시도입니다. 솔루션이 좋든 나쁘 든 (아마도 쓰레기 일지라도) 문제 설명은 정확합니다. IPv6을 구현하려는 현재 전략은 지금까지 실패했습니다. 소개에서 알 수 있듯이 19 년의 IPv6은 여전히 의미있는 방식으로 전환 한 것을 볼 수있는 방법이 없습니다.
언급했듯이 우리는 이미 NAT64와 같은 브리징 솔루션을 가지고 있습니다 (다른 것들도 언급합니다). 이것들은 훌륭하지만 훌륭하지만 여전히 IPv6으로 완전히 전환 할 수는 없습니다. 공개 IPv4 전용 호스트가 여기에 있다고 가정합니다.
즉, IPv6으로의 전환에 근본적인 문제 가 있다고 생각하면이 사양이 어떻게 도움이 될지에 대해서는 회의적 입니다. 나는 그것이 시도하는 방법을 이해하려고 많은 시간을 소비하지 않았으며 어쩌면 나보다 현명한 것일 수도 있지만 (다른 답변 중 합의가 내가 옳다는 것을 암시하지만) 처음.
그러나 대답은 여전히 문제를 해결하기위한 진지한 시도입니다.
새로운 프로토콜의 구현에는 약간의 타당성이 있습니다. 현재 번역 프로토콜은 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는 항상 병목 현상이었습니다.