요약

  • RFC 3692는 나중에 회수하기 어렵고 재사용 위험이 있는 임시 전용 할당 대신, 일반적인 테스트용 값을 선택했습니다.
  • 그 값 253과 254는 특정 실험을 식별하지 않으며, 기기들이 서로를 이해한다고 보장하지도 않습니다. 안전한 사용은 현지 합의, 명시적 설정, 그리고 영구적인 용도에 대해서는 평상시의 할당 절차에 달려 있습니다.

이름이 생기기 전에 실험에는 번호가 필요하다

두 명의 엔지니어가 패킷에 새 필드를 추가한다고 상상해 보십시오. 코드는 컴파일될 수 있지만, 수신 시스템에는 그 필드가 무엇을 뜻하는지 알려주는 값이 여전히 필요합니다. 닫힌 실험실에서는 사적으로 하나를 고를 수 있습니다. 문제는 그 실험이 다른 누군가의 번호를 차지하지 않으면서, 혹은 나중에 회수해야 할 수도 있는 번호를 당국에 빌려 달라고 요청하지 않으면서 실제 프로토콜 장비를 통과하게 만들고 싶을 때 시작됩니다.

2004년 1월에 Best Current Practice 82로 공개된 RFC 3692는 바로 그 좁은 간격을 다루었습니다. 임시 전용 할당은 서류상으로는 깔끔해 보였습니다. 실험을 위해 값을 할당하고, 작업이 끝나면 돌려주는 방식입니다. 그러나 이 문서는 인간적·운영적 잔여물을 지적합니다. 연락처는 낡고, 테스트가 아직 진행 중인지 아무도 확인할 수 없으며, 값이 제품에 새어 나갈 수 있고, 배포 이력이 더 이상 보이지 않는 기기들에 재사용이 예기치 못한 결과를 줄 수 있습니다.

대안은 이름표가 붙은 열쇠를 빌리는 것보다 공용 실험대 하나를 마련해 두는 것에 가까웠습니다. IP 프로토콜 필드에 대해 IANA는 실험과 테스트를 위해 253과 254를 할당했습니다. 서로 합의한 시스템들은 같은 값을 서로 다른 시험에 사용할 수 있었습니다. 그 값은 의도적으로 일반적이었습니다. 특정 프로토콜의 의미를 예약하지 않았고, 다른 구현자들을 묶지도 않았으며, 호환성 계약을 성립시키지도 않았습니다.

충돌은 설계의 일부였다

여기가 직관에 반하는 부분입니다. RFC 3692는 모든 실험에 고유한 임시 번호를 부여해 충돌을 없애지 않았습니다. 충돌 위험을 명시적으로 만들고, 그 경계를 로컬에 두었습니다. 관리자는 특정 목적을 위해 값을 선택하고 그 환경에서 아직 사용되지 않았는지 확인할 수 있습니다. 그 로컬 선택 바깥에서는 고유성이 보장되지 않습니다.

이것은 테스트 결과가 무엇을 증명할 수 있는지를 바꿉니다. 253을 사용하는 패킷은 설정된 피어가 그 확장을 인식한다는 것을 보여줄 수 있습니다. 그러나 무관한 네트워크가 같은 값을 같은 방식으로 해석할 것임을 보여주지는 못합니다. 합의된 실험실 안에서의 성공적인 교환은 그 끝점들과 조건에 대해 말해줄 뿐, 광범위한 배포에 대해서는 말해주지 않습니다. 실험이 유용해지면 RFC 3692는 영구 번호를 위해 정상적인 할당 절차로 돌아가라고 안내합니다.

제품 경계도 똑같이 분명합니다. 출하되는 제품에서 실험용 인식이 기본으로 켜져 있어서는 안 됩니다. 사용자가 명시적으로 켜야 하고, 대부분의 경우 어떤 값을 사용할지 설정해야 합니다. 하드코딩된 값은 다른 실험과 충돌할 수 있으며, 이 번호들이 전용이 아니라 공유되기 때문에 정확히 상호운용성 문제를 일으킬 수 있습니다.

이후의 카탈로그가 합의를 바꾸지 않았다

RFC 4727은 나중에 IPv4, IPv6, ICMP, UDP, TCP 헤더 공간의 실험용 값을 문서화했습니다. 이 문서는 하나를 골라 시스템에 하드코딩하지 말라고 하며, 독자를 RFC 3692의 주의사항으로 되돌려 보냅니다. 그 더 넓은 카탈로그는 실험을 명세하기 쉽게 만들었지만, 그 값들을 고유한 이름이나 일반적으로 배포되는 기능으로 바꾸지는 않았습니다.

레지스트리를 읽을 때 이 구분은 여전히 중요합니다. IANA는 현재 IPv4 프로토콜 값 253과 254를 실험과 테스트용으로 나열하고 있습니다. 그것은 할당의 목적에 대한 증거이지, 구현 수를 세는 것도 아니고, 실험적 프로토콜이 인터넷 전반에서 실행 중이라는 주장도 아닙니다. RFC 8126은 이후 IANA 고려사항에 관한 일반 지침이며, RFC 3692가 구문서인 RFC 2434를 참조한 것은 2004년의 역사에 속합니다.

RFC 3692의 작은 기여는 무언가를 시도해 보기 위한 더 안전한 문법이었습니다. 일반적인 공간을 예약하고, 로컬 합의를 보이게 만들고, 옵트인을 요구하며, 유용한 작업은 평상시 절차를 통해 정식으로 승격시키는 것입니다. 테스트 값은 문을 열어줍니다. 그러나 문 너머에 무엇이 있는지 모두에게 말해주지는 않습니다.

출처