참고 사항
네트워크 배포 및 테스트 진행 중입니다.
소규모 수정이 있을 수 있습니다.
개요
이 제안은 IPv6에 대한 SSU 및 NTCP2 전송 방식의 기능 향상을 구현하는 것입니다.
동기
전 세계적으로 IPv6가 확대되고 있으며, 특히 모바일 환경에서 IPv6 전용 설정이 점점 더 일반화됨에 따라
모든 라우터가 IPv4를 지원한다고 가정하는 것을 제거하고
IPv6에 대한 지원을 개선할 필요가 있습니다.
연결성 확인
터널을 위해 피어를 선택하거나, 메시지 라우팅을 위해 OBEP/IBGW 경로를 선택할 때,
라우터 A가 라우터 B에 연결할 수 있는지 여부를 계산하는 것이 유용합니다.
일반적으로 이는 A가 B가 게시한 인바운드 주소 중 하나와 일치하는 전송 방식 및 주소 유형(IPv4/v6)에 대해
아웃바운드 기능을 가지고 있는지를 결정하는 것을 의미합니다.
그러나 많은 경우 A의 기능을 알 수 없으며 가정을 해야 합니다.
A가 숨겨져 있거나 방화벽 뒤에 있으면 주소가 공개되지 않으며 직접적인 정보를 얻을 수 없으므로,
IPv4는 지원한다고 가정하고 IPv6는 지원하지 않는다고 가정합니다.
해결책은 라우터 정보(Router Info)에 아웃바운드 기능을 나타내는 두 가지 새로운 “caps(기능)“를 추가하여
IPv4 및 IPv6에 대한 아웃바운드 기능을 표시하는 것입니다.
IPv6 소개자(Introducers)
SSU 사양에는 IPv4 소개를 위한 IPv6 소개자가 지원되는지 여부에 관해 오류와 불일치가 존재합니다.
어쨌든 Java I2P나 i2pd 모두에서 이를 구현한 적이 없습니다.
이 부분은 수정되어야 합니다.
IPv6 소개(Introductions)
SSU 사양은 명확히 IPv6 소개가 지원되지 않는다고 명시하고 있습니다.
이는 IPv6는 절대 방화벽 뒤에 있지 않다는 가정 하에 이루어진 것이었습니다.
이 가정은 명백히 잘못되었으며, 방화벽 뒤에 있는 IPv6 라우터에 대한 지원을 개선할 필요가 있습니다.
소개 다이어그램
범례: —– 는 IPv4, ====== 는 IPv6
기존 IPv4 전용:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
IPv4 소개, IPv6 소개자:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
IPv6 소개, IPv6 소개자:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
IPv6 소개, IPv4 소개자:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
설계
구현되어야 할 세 가지 변경 사항이 있습니다.
- 라우터 주소의 기능(caps)에 “4"와 “6” 기능을 추가하여 IPv4 및 IPv6 아웃바운드 지원을 나타냄
- IPv6 소개자를 통한 IPv4 소개 지원 추가
- IPv4 및 IPv6 소개자를 통한 IPv6 소개 지원 추가
사양
4/6 기능(caps)
이 기능은 공식 제안 없이 처음 구현되었지만,
IPv6 소개를 위해 필요하므로 여기에 포함합니다.
두 가지 새로운 기능 “4"와 “6"이 정의됩니다.
이 새로운 기능들은 라우터 정보(Router Info)의 caps가 아니라, 라우터 주소(Router Address)의 “caps” 속성에 추가됩니다.
현재 NTCP2에는 “caps” 속성을 정의하지 않았습니다.
소개자(introducers)가 있는 SSU 주소는 현재 정의상 IPv4입니다. 우리는 아직 IPv6 소개를 전혀 지원하지 않습니다.
그러나 이 제안은 IPv6 소개와 호환됩니다. 아래 참조.
또한, 라우터는 I2P-over-Yggdrasil과 같은 오버레이 네트워크를 통해 연결을 지원할 수 있지만,
주소를 공개하고 싶지 않거나, 해당 주소가 표준 IPv4 또는 IPv6 형식이 아닐 수 있습니다.
이 새로운 기능 시스템은 이러한 네트워크도 지원할 수 있도록 유연해야 합니다.
다음 변경 사항을 정의합니다:
NTCP2: “caps” 속성 추가
SSU: 호스트(host) 또는 소개자(introducers) 없이 아웃바운드 지원을 나타내는 라우터 주소 추가 지원
(IPv4, IPv6, 또는 둘 다)
양쪽 전송 방식 모두: 다음 caps 값 정의
- “4”: IPv4 지원
- “6”: IPv6 지원
단일 주소에서 여러 값이 지원될 수 있습니다. 아래 참조.
라우터 주소에 “host” 값이 포함되지 않은 경우, 적어도 하나의 caps가 필수입니다.
라우터 주소에 “host” 값이 포함된 경우, caps 중 최대 하나만 선택 가능합니다.
향후 오버레이 네트워크 또는 기타 연결성에 대한 지원을 나타내기 위해 추가 전송 caps가 정의될 수 있습니다.
사용 사례 및 예시
SSU:
호스트가 있는 SSU: 4/6 선택 사항, 둘 이상 불가능.
예: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”
하나만 아웃바운드 전용이고 다른 하나는 게시된 경우: caps만 사용, 4/6.
예: SSU caps=“6”
소개자가 있는 SSU: 결합되지 않음. 4 또는 6이 필요함.
예: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…
숨겨진 SSU: caps만 사용, 4, 6, 또는 46. 다중 허용.
4용 하나, 6용 하나의 주소를 둘 다 가질 필요 없음.
예: SSU caps=“46”
NTCP2:
호스트가 있는 NTCP2: 4/6 선택 사항, 둘 이상 불가능.
예: NTCP2 caps=“4” host=“1.2.3.4” i=… port=“1234” s=… v=“2”
하나만 아웃바운드 전용이고 다른 하나는 게시된 경우: caps, s, v만 사용, 4/6/y, 다중 허용.
예: NTCP2 caps=“6” i=… s=… v=“2”
숨겨진 NTCP2: caps, s, v만 사용, 4/6, 다중 허용. 4용 하나, 6용 하나의 주소를 둘 다 가질 필요 없음.
예: NTCP2 caps=“46” i=… s=… v=“2”
IPv4를 위한 IPv6 소개자
사양의 오류와 불일치를 수정하기 위해 다음 변경 사항이 필요합니다.
이를 제안의 “파트 1"로도 설명했습니다.
사양 변경
SSU 사양은 현재 다음과 같이 말하고 있습니다(IPv6 참고):
IPv6는 0.9.8 버전부터 지원됩니다. 게시된 릴레이 주소는 IPv4 또는 IPv6일 수 있으며, Alice-Bob 통신은 IPv4 또는 IPv6를 통해 이루어질 수 있습니다.
다음 추가:
사양은 0.9.8 버전부터 변경되었지만, Alice-Bob 통신을 위한 IPv6 지원은 실제로는 0.9.50 버전까지 구현되지 않았습니다.
이전 버전의 Java 라우터는 실제로 IPv6를 통해 소개자 역할을 하지 않았음에도 불구하고,
IPv6 주소에 대해 ‘C’ 기능을 잘못 게시했습니다.
따라서 라우터는 라우터 버전이 0.9.50 이상인 경우에만 IPv6 주소의 ‘C’ 기능을 신뢰해야 합니다.
SSU 사양은 현재 다음과 같이 말하고 있습니다(릴레이 요청):
IP 주소는 패킷의 소스 주소 및 포트와 다를 경우에만 포함됩니다.
현재 구현에서는 IP 길이는 항상 0이며 포트는 항상 0이며,
수신자는 패킷의 소스 주소와 포트를 사용해야 합니다.
이 메시지는 IPv4 또는 IPv6를 통해 전송될 수 있습니다. IPv6인 경우, Alice는 자신의 IPv4 주소와 포트를 포함해야 합니다.
다음 추가:
이 메시지를 IPv6로 전송할 때 IPv4 주소를 소개하려면 IP와 포트를 반드시 포함해야 합니다.
이 기능은 0.9.50 릴리스부터 지원됩니다.
IPv6 소개(Introductions)
SSU 릴레이 메시지 세 가지(RelayRequest, RelayResponse, RelayIntro) 모두
(Alice, Bob, 또는 Charlie) IP 주소의 길이를 나타내는 IP 길이 필드를 포함하고 있습니다.
따라서 메시지 형식을 변경할 필요는 없습니다.
16바이트 IP 주소가 허용됨을 나타내는 사양의 텍스트만 변경하면 됩니다.
다음 사양 변경이 필요합니다.
이를 제안의 “파트 2"로도 설명했습니다.
사양 변경
SSU 사양은 현재 다음과 같이 말하고 있습니다(IPv6 참고):
Bob-Charlie 및 Alice-Charlie 통신은 IPv4 전용입니다.
SSU 사양은 현재 다음과 같이 말하고 있습니다(릴레이 요청):
IPv6에 대한 릴레이를 구현할 계획은 없습니다.
다음으로 변경:
IPv6에 대한 릴레이는 0.9.xx 릴리스부터 지원됩니다.
SSU 사양은 현재 다음과 같이 말하고 있습니다(릴레이 응답):
Charlie의 IP 주소는 Alice가 홀펀치(Hole Punch) 후 SessionRequest를 전송할 주소이므로 반드시 IPv4여야 합니다.
IPv6에 대한 릴레이를 구현할 계획은 없습니다.
다음으로 변경:
Charlie의 IP 주소는 0.9.xx 릴리스부터 IPv4 또는 IPv6일 수 있습니다.
이는 Alice가 홀펀치 후 SessionRequest를 전송할 주소입니다.
IPv6에 대한 릴레이는 0.9.xx 릴리스부터 지원됩니다.
SSU 사양은 현재 다음과 같이 말하고 있습니다(릴레이 소개):
현재 구현에서는 Alice의 IP 주소는 항상 4바이트입니다. 왜냐하면 Alice는 IPv4를 통해 Charlie에 연결하려고 하기 때문입니다.
이 메시지는 반드시 기존 IPv4 연결을 통해 전송되어야 하며,
이는 Bob이 Charlie의 IPv4 주소를 알 수 있는 유일한 방법이기 때문입니다.
이 주소는 RelayResponse에서 Alice에게 반환됩니다.
다음으로 변경:
IPv4의 경우, Alice의 IP 주소는 항상 4바이트입니다. 왜냐하면 Alice는 IPv4를 통해 Charlie에 연결하려고 하기 때문입니다.
0.9.xx 릴리스부터 IPv6가 지원되며, Alice의 IP 주소는 16바이트일 수 있습니다.
IPv4의 경우, 이 메시지는 반드시 기존 IPv4 연결을 통해 전송되어야 하며,
이는 Bob이 Charlie의 IPv4 주소를 알 수 있는 유일한 방법이기 때문입니다.
0.9.xx 릴리스부터 IPv6가 지원되며, 이 메시지는 기존 IPv6 연결을 통해 전송될 수 있습니다.
또한 추가:
0.9.xx 릴리스부터, 소개자와 함께 게시된 모든 SSU 주소는 “caps” 옵션에 “4” 또는 “6"을 포함해야 합니다.
마이그레이션
이전 모든 라우터는 NTCP2의 caps 속성과 SSU caps 속성의 알 수 없는 기능 문자를 무시해야 합니다.
“4” 또는 “6” cap이 포함되지 않은 소개자와 함께 게시된 모든 SSU 주소는 IPv4 소개용으로 간주됩니다.