요약

  • 10월 28일자 v6ops 작업반 초안 02판은 ICMPv6 오류의 바깥 IPv6 출발지가 변환 불가능할 때, 번역기가 공인 IPv4를 사용할 수 있으면 그것을 ICMPv4 응답의 출발지로 써야 한다고 권고한다. 없을 때는 192.0.0.8을 사용해야 한다. 01판에는 이 우선순위가 명시되지 않았다.
  • 원래 IPv6 출발지를 담은 Node Identification 객체를 추가하는 편이 권장된다. Packet Too Big에서는 먼저 ICMPv4로 번역한 뒤에야 확장을 붙일 수 있으며 생략도 허용되지만, 오류 자체는 보내는 편이 권장된다. IANA 등록부는 192.0.0.8/32을 IPv4 더미 주소로 분류한다.

응답의 출발지와 오류의 발신자는 다르다

IPv4 통신이 IPv6 전용 구간을 지날 때 목적지 도달 불가, 시간 초과, Packet Too Big 같은 ICMPv6 오류가 돌아올 수 있다. 그 오류의 바깥 IPv6 출발지는 번역 접두사에 속하지 않고 정적·상태 기반 매핑도 없을 수 있다. 번역기는 128비트 주소를 ICMPv4의 32비트 출발지 칸에 그대로 넣을 수 없다. 게다가 공인 IPv4를 하나도 갖지 않았다면 자기 이름으로 답장할 수도 없다. 오류의 내용은 중요한데 봉투에 적을 IPv4 출발지가 없는 셈이다.

02판의 4.1절은 먼저 자원을 살핀다. 공인 IPv4 주소나 그 풀을 사용할 수 있으면 RFC 6791의 접근에 따라 그것을 쓰는 편을 권한다. 그런 주소가 없으면 192.0.0.8을 써야 한다. 이전 판은 변환할 수 없는 출발지에 대해 더미 주소 사용을 넓게 권고했다. 새 분기는 공인 주소가 있는 번역기와 없는 번역기를 같은 장비인 양 취급하지 않는다. 자원이 없는 장치에도 오류를 되돌려 보낼 방법을 마련한다.

IANA의 특수목적 IPv4 등록부는 이 /32를 RFC 7600의 IPv4 더미 주소로 적는다. 출발지로 쓸 수 있다는 표시는 있지만, 목적지로 유효하거나 전달 가능하거나 전 세계에서 도달할 수 있다는 표시는 없다. 진단 화면에 이 값이 나타났다고 해서 경로에 192.0.0.8이라는 실제 라우터가 서 있다는 뜻은 아니다. 번역기가 원래 발신자의 IPv6 주소를 IPv4 출발지에 담지 못해 대신 쓴 표식이다.

원래 출처는 다른 통로가 맡는다. 초안은 Node Identification 객체와 그 안의 IP Address 하위 객체에 원래 IPv6 주소를 넣도록 권한다. 객체를 추가했다면 주소를 포함하고 확장 헤더의 검사합을 갱신해야 한다. 반대로 IPv6 출발지가 정상적으로 변환된다면 더미 주소와 이 확장을 사용해서는 안 된다. 예외 경로가 일반적인 매핑을 덮어쓰지 않도록 조건을 묶은 것이다.

패킷을 만든 뒤에도 사람이 보는 화면까지는 거리가 있다. 초안의 운영 절은 traceroute 같은 도구가 Node Identification을 해석하고 표시해야 추가 정보의 혜택을 얻는다고 말한다. 패킷에는 IPv6 원본이 있는데 화면에는 더미 숫자만 보일 수 있다. 번역기의 기록 책임과 진단 도구의 표시 책임은 별도로 확인해야 한다.

Packet Too Big는 두 목표를 갈라놓는다

Packet Too Big는 송신자에게 현재 패킷 크기가 경로에 맞지 않음을 알려준다. 이 오류를 버리면 크기 조절의 단서가 사라진다. 그러나 ICMPv6 Packet Too Big에는 필요한 ICMP 확장을 번역 전에 붙일 수 없다. 먼저 ICMPv4 오류로 바꾸고 그다음 Node Identification을 추가해야 한다. 초안은 이 경우 확장을 생략할 수 있게 하면서도, 더미 출발지로 오류를 번역해 보내고 버리지 말라고 권한다.

그러면 IPv4 쪽은 크기 정보를 받지만 발신 노드의 정확한 주소는 모를 수 있다. 이것은 어느 정보가 살아남았는지 정확히 말해 주는 결과다. 필수 오류 신호의 전달을 부가적인 신원 표시의 성공에 묶어 버리면, 신원을 못 넣는 순간 크기 정보까지 잃는다.

번역기는 이 처리를 할 오류와 하지 않을 오류도 구분해야 한다. 자신이 IPv4에서 번역한 흐름에 대한 ICMPv6 오류인지, 원래부터 IPv6였던 흐름의 오류인지 판단해야 한다. 번역 전용 IPv6 주소나 /64가 있으면 구분이 쉽다. 같은 주소가 두 역할을 모두 맡으면 상태를 유지하거나 오류를 부른 패킷의 헤더를 살펴야 할 수 있다. IANA가 더미 번호를 예약했다고 해서 이 분류가 자동으로 이뤄지지는 않는다.

Datatracker는 02판을 IESG에 제출돼 AD 평가를 받는 작업반 Internet-Draft로 표시한다. 승인되면 RFC 6791과 RFC 7915를 갱신하려는 문서다. 새 IANA 배정을 요구하지 않으며 실제 배포 장비의 패킷 추적도 제시하지 않는다. 이전 Daniel Kade 기사들은 일반적인 Node Identification의 노출 정책과 알 수 없는 AFI 처리에 집중했다. 이번 쟁점은 공인 IPv4가 없는 번역기가 오류 메시지의 출발지를 무엇으로 선택하느냐다.

출처