요약

  • RFC 1883부터 IPv6 TLV 옵션 타입의 최상위 두 비트는 처리 노드가 해당 옵션을 인식하지 못할 때 취해야 할 행동을 규정했다: 건너뛰기, 패킷 폐기, 또는 정확히 지점을 가리키는 ICMPv6 오류를 반환하며 폐기하기.
  • 세 번째 비트는 옵션 데이터가 경로 중에 변경될 수 있는지를 선언했다. 이 비트들은 무지의 범위를 제한하고 인증 계산을 보호했지만, 노드가 헤더를 처리하리라는 보장, 중간 장비가 이를 통과시키리라는 보장, 혹은 옵션이 신뢰받을 자격이 있다는 보장은 결코 하지 않았다.

최초의 IPv6 옵션은 낯선 이를 위한 지시를 담았다

IPv6 목적지가 Destination Options 헤더는 인식하지만 그 안의 특정 TLV는 인식하지 못하는 경우를 생각해 보자. 이 노드는 타입과 길이는 읽을 수 있지만 옵션 데이터를 위한 파서는 갖고 있지 않다. 패킷은 확장 메커니즘이 살아남도록 설계된 바로 그 호환성 경계에 도달한 것이다: 새로운 의미가 낡은 코드 앞에 도착한 것이다.

1995년 12월 발표된 최초의 공개 IPv6 사양인RFC 1883은 그 노드를 무작정 “알 수 없음” 사례에 맡기지 않았다. 대신 옵션 타입 옥텟 자체에 폴백을 인코딩했다. 최상위 두 비트는 무지가 얼마나 비용을 치러야 하는지를 말했고, 세 번째 비트는 데이터가 최종 목적지로 가는 동안 변경될 수 있는지를 말했다. 나머지 다섯 비트는 옵션 식별에 참여했다.

이는 작지만 결과가 큰 권한 배분이었다. 새 옵션의 설계자는 비인식의 안전한 결과를 전역적으로 파싱 가능한 형태로 선언할 수 있었다. 낡은 구현은 데이터에 대한 의미론을 발명할 필요가 없었다. 공통 봉투를 이해하고 좁은 지시를 따르기만 하면 되었다.

두 비트가 무지의 네 가지 결과를 제한했다

네 가지 두 비트 값은 무해에서 악의적까지의 사다리를 이루지 않았다. 이들은 처리 결과를 기술했다.

00은: 이 옵션을 건너뛰고 헤더 처리를 계속하라는 뜻이었다. 길이 바가 경계를 제공했으므로 노드는 개별 데이터를 이해하지 않고도 앞으로 진행할 수 있었다.01은 패킷을 폐기하라는 뜻이었다.10은 폐기하고 출발지로 ICMPv6 Parameter Problem, Code 2를 전송하되 포인터가 인식되지 않은 옵션 타입을 가리키도록 하라는 뜻이었다.11은 동일한 폐기를 요구했지만 패킷의 목적지가 멀티캐스트가 아닌 경우에만 그 오류를 전송했다.

포인터가 중요했다. 포인터는 일반적인 손실을 처리를 중단시킨 정확한 옥텟에 대한 증거로 바꾸었다. 그러나 오류는 여전히 패킷이었지 판정 서비스가 아니었다. 오류는 레이트 리밋되거나, 필터링되거나, 잘못 라우팅되거나, 유실될 수 있었다. 오류의 도착은 한 노드가 하나의 미인식 타입을 보고했음을 보여줄 뿐; 오류의 부재는 모든 노드가 옵션을 건너뛰었다는 증명이 아니었다.

00은 통과 권리를 부여하지도 않았다.00은 이미 그 옵션 헤더를 처리 중인 규격 준수 노드에게 진행 방법을 알려줄 뿐이었다. 방화벽은 여전히 로컬 규칙을 적용할 수 있고, 라우터는 Hop-by-Hop 옵션을 처리하도록 구성되지 않았을 수 있으며, 경로는 의도된 처리기가 타입을 보기 전에 실패할 수 있었다.

멀티캐스트 구분은 오류 트래픽을 제한했다

10과11의 차이는 타입 안에서 의도적으로 드러나 있었다.10의 경우 처리 노드는 목적지가 멀티캐스트여도 실패를 보고했다.11의 경우 멀티캐스트 목적지에 대해서는 ICMP 응답을 억제했다.

이 구분은 보고 정책을 구현체의 중요도 추측이 아니라 옵션 자체에 붙도록 했다. 또한 가능한 증폭 면을 감사 가능하게 만들었다. 운영자는 옵션이 멀티캐스트 사례에서 보고를 요구하는지 읽어볼 수 있다; 운영자는 여전히 레이트 리밋을 통제하며 응답이 실제로 발송되는지 관찰해야 한다.

비트 패턴은 멀티캐스트 자체가 안전하지 않다고 말하지 않았다. 비트 패턴은 처리기가 인식하지 못할 때 이 특정 옵션 타입에 어느 오류 행동이 속하는지를 말했을 뿐이다.

세 번째 비트는 변이 가능한 데이터를 거짓 약속 밖에 두었다

다음 비트는 다른 질문에 답했다. 0은 옵션 데이터가 경로 중 변경되지 않는다고 선언했고; 1은 변경될 수 있다고 선언했다. 이는 또 다른 미지 옵션 행동이 아니었다. 데이터의 안정성을 기술한 것이다.

이 구분은 IPv6 인증 헤더가 존재할 때 중요했다. 변경 가능으로 표시된 옵션의 경우 인증 값을 계산하거나 검사할 때 옵션 데이터 필드 전체가 0 값 옥텟으로 취급되었다. 프로토콜은 변하는 필드를 인증한 뒤 정상적인 경로 내 갱신을 변조로 둔갑시키지 않았다.

이 제외는 좁았다. 모든 라우터에게 옵션을 재작성할 권한을 준 것이 아니었다. 무엇을 누가 변경할 수 있는지는 옵션 자체의 사양이 여전히 결정했다. 그 비트는 단지 예상된 변이를 인증 계산이 커버하는 불변 영역 밖에 유지했을 뿐이다.

그 비트들은 타입에 속했다

RFC 2460은 1998년 중요한 명확화를 했다: 세 개의 상위 비트는 완전한 8비트 옵션 타입의 일부였다. 이들은 5비트 식별자 위에 덧씌워진 별도의 정책 필드가 아니었다. 상위 비트가 다른 두 옵션은 하위 다섯 비트가 같더라도 서로 다른 타입이었다.

Hop-by-Hop Options와 Destination Options는 동일한 타입 번호 공간을 사용했으며, 다만 옵션 사양이 그 타입이 유효한 위치를 제한할 수 있었다. 옵션은 또한 나타난 순서대로 처리되어야 했다. 수신기가 앞서 탐색해 익숙한 옵션을 찾아 미지의 선행 옵션보다 먼저 실행하는 것은 허용되지 않았다.

순서는 인과성을 보존했다. 앞선 옵션이 폐기를 요구했다면 뒤의 옵션은 소급하여 패킷을 수용 가능하게 만들 수 없었다. 공통 문법은 바이트 경계와 결정 경계를 모두 제공했다.

미지 옵션은 미지 확장 헤더가 아니었다

이 메커니즘에는 날카로운 한계가 있었다. 이 비트들은 인식되는 Hop-by-Hop Options 또는 Destination Options 헤더가 운반하는 TLV 옵션 안에 존재한다. Next Header 값이 노드가 인식하지 못하는 확장 헤더 타입을 가리키는 사례는 이 비트들이 해결하지 못한다.

미지 TLV는 여전히 자신의 길이와 행동 비트를 노출한다. 미지 확장 헤더는 역사적으로 레거시 검사기가 안전하게 통과할 수 있는 형식을 노출하지 않았을 수 있다. 그래서RFC 6564는 가능한 경우 목적지 정보를 옵션으로 추가하는 쪽을 선호했고 미래의 확장 헤더에 공통의 길이 포함 레이아웃을 부과했다. 그러나 이는 낡은 헤더 형식을 균일하게 만들지는 않았다.

RFC 7045는 역할 경계를 그었다. 목적지 호스트는 미인식 확장 헤더를 포함한 패킷을 폐기한다. 중간 전달 노드는 새로 표준화된 헤더를 인식하지 못한다는 이유만으로 폐기해서는 일반적으로 안 되며; 확장 헤더를 검사하기로 선택했다면 자신의 지식을 최신으로 유지해야 한다. 이는 이미 파싱 방법을 아는 헤더 안의 미지 옵션의 행동 비트를 참조하는 것과는 다른 계약이다.

중간 장비는 자기 기술이 해결할 수 없는 것을 드러냈다

옵션 형식은 동시 업그레이드 압박을 줄였지만 배포 마찰을 폐지하지는 않았다. 전송 포트를 찾거나, 접근 규칙을 강제하거나, 흐름을 분산하는 장비는 IPv6 헤더 체인을 통과해야 할 수 있다. 미지 타입, 긴 체인, 패스트 패스를 벗어나는 옵션은 실질적인 파싱 및 자원 비용을 만든다.

RFC 8200은 네 가지 행동과 변경 비트를 유지하면서, 경유 노드의 Hop-by-Hop 처리를 명시적 구성에 의존하도록 만들었다. 이후RFC 9098은 필요한 정보를 찾을 수 없는 장비가 직면하는 운영적 선택을 문서화했다: 원하는 검사 없이 통과시키거나, 폐기하거나, 정상 패스트 패스 밖에서 처리한다. 각 선택에는 보안 또는 용량 비용이 따른다.

이것이 자기 기술 폴백이 필요하지만 불충분한 이유다. 타입은 규격 준수 처리기가 그 옵션에 도달한 후 무지가 무엇을 의미하는지 알려준다. 중간 장비가 그 옵션에 도달하도록 강제하거나, 실리콘을 할당하게 하거나, 자원 비용을 수용하게 만들 수는 없다.

그 비트들이 결코 허가하지 않은 것

행동 등급은 진위성 등급이 아니다.00은 안전을 의미하지 않고,11은 적대적을 의미하지 않는다. 변경 비트는 임의의 수정에 대한 허가가 아니다. ICMP 포인터는 발신자의 신원이나 의도를 증명하지 않는다. 등록된 타입은 경로가 이를 지원한다는 확립이 아니다.

이 아키텍처가 유용한 것은 바로 권한이 좁기 때문이다. 표준은 공통 결과를 정의한다. 발신자는 옵션을 선택한다. 처리 노드는 자신의 경계에서 행동한다. 운영자는 자원 정책을 소유한다. 실제 흐르는 패킷이 배포의 증거를 제공한다.

출처와 증거의 한계

원래의 비트 의미론은 RFC1883과2460에서 나오며, 현재의 핵심 규칙은 RFC8200에 있다. 새 확장 헤더 형식 및 전달 행동과의 구분은 RFC6564와7045에서 나온다. 운영상의 제약은 RFC9098에서 나온다. 이 문서들은 규칙과 기록된 실패 양상을 정의한다. 이들은 모든 제품이나 네트워크에 대한 현재의 지원 여부, 폐기율 또는 규격 준수를 증명하지는 않는다.