요약

  • RFC 1888은 NSAP와 IPv6 주소 정보를 운반하는 네 가지 선택적 방식을 정의했지만, 먼저 운영자에게 기존 주소 계획을 IPv6에 맞게 새로 설계하도록 권고했다.
  • 문서 자체의 경고가 가역적 인코딩이 라우팅 등가가 아닌 이유를 보여주었다: OSI 에어리어는 IPv6 서브넷과 달리 여러 링크에 걸칠 수 있고, 혼합 프리픽스는 집계에 저항하며, 호스트 전체 NSAP 신원은 인터페이스별 IPv6 신원이 되지 않는다.
  • RFC 4048은 나중에 겉보기에 사용되지 않은 NSAP-in-IPv6 메커니즘을 역사(Historic)로 지정하면서 역방향 매핑의 두 가지 오류를 분리해 지적했고, RFC 4548은 그 좁은 IPv6-in-NSAPA 네임스페이스만 수정했다.

봉투가 곧 아키텍처는 아니었다

1996년 8월,RFC 1888은 OSI NSAP 주소와 IPv6 사이의 매핑을 실험(Experimental) 문서로 제시했다. 그 지위가 중요하다. 이 메모는 인터넷 표준을 규정하지 않았다. 더 알기 쉽게는, 문서의 첫 실질 권고는 기존 전송 이미지를 보존하는 것이 아니었다. 조직이 OSI 주소 체계를 계획하거나 배포했더라도, 네이티브 IPv6 계획을 새로 설계하고 가능한 범위에서 로컬 토폴로지를 다시 매핑하라는 것이었다.

이 경고가 호환성 장치보다 먼저 나온 이유는 두 주소 체계가 네트워크를 서로 다른 방식으로 나누기 때문이었다. OSI 라우팅에서 에어리어는 여러 물리 링크를 덮을 수 있다. IPv6는 서브넷을 하나의 링크로 다룬다. 에어리어 번호를 IPv6 서브넷 필드에 복사하면 숫자상 깔끔한 대응이 생기지만, 이웃이 같은 링크를 공유하는지, 마지막 라우터가 올바른 단말 시스템에 도달하는 방법을 아는지는 증명하지 않는다.

집계는 두 번째 불일치를 만들었다. 광역 라우팅은 주소들이 하나의 경로로 광고할 수 있는 공통 프리픽스를 공유할 때 규모를 얻는다. 일반 IPv6 주소와 RFC 1888의 제한된 NSAPA 기반 주소는 그런 프리픽스를 자동으로 공유하지 않았다. 매핑은 주소 하나씩은 손실 없이 이루어질 수 있지만, 대상 집단에 도달하는 데 필요한 경로 수를 늘리는 결과를 낳았다.

신원이 세 번째 균열선이었다. OSI 단말 시스템은 인터페이스 전반에 걸쳐 호스트를 식별하는 여러 NSAP을 가질 수 있었다. IPv6는 주소를 인터페이스에 할당한다. 호스트 전체 식별자를 인터페이스 주소 아키텍처로 옮기는 것은 목적지가 실제로 도달 가능한 인터페이스를 선택해 주지 않았다. RFC 1888은 ES-IS 및 IS-IS 라우팅 인프라의 마이그레이션도 범위 밖으로 두었다. 주소 조리법이 제어 평면까지 가져오지는 않았다.

네 가지 메커니즘, 네 개의 미완성 인계

첫 번째 메커니즘은0x02로 시작하는 16바이트 IPv6 주소에 제한된 ICD 또는 DCC 형식의 NSAPA를 넣었다. 허용된 하위 집합 안에서는 알고리즘적이고 가역적이었다. 그러나 문서는 라우팅이 비효율적일 수 있고 여러 물리 서브넷을 포함하는 에어리어에는 추가 메커니즘이 필요하다고 경고했다. 디코더는 기존 주소를 복구할 수 있었지만, 라우터에는 여전히 결여된 토폴로지 규칙이 없었다.

두 번째 메커니즘은 IPv6 주소를0x03으로 시작하고 절단된 NSAPA를 실었다. 보존된 계층은 패킷을 올바른 에어리어 쪽으로 라우팅할 수 있었지만, 에지에는 여전히 완전한 목적지가 필요했다. RFC 1888은 전체 NSAPA 목적지 옵션 또는 캡슐화된 CLNP 패킷을 요구했다. 수신자 측에서는 로컬 정책과 구현이 전달, 캡슐 해제 또는 폐기를 결정해야 했다. 자동화된 최종 발견은 정의되지 않았다. 정적 매핑이나 미래의 ES-IS 유사 메커니즘은 단지 가능성이었다.

이 공백은 장애 증거에도 영향을 주었다. 기존 방식의 자동 구성과 발견은 그대로 작동하지 않았다. 전체 NSAPA를 IPv6 라우팅 헤더에 단순히 넣을 수 없었다. 절단된 출처 주소로 향한 ICMP 오류는 실제 발신원에 도달하지 못하고 폐기될 수 있었다. 따라서 경로는 진단 체인이 설명에 필요한 신원을 잃어버린 바로 그 지점에서 실패할 수 있었다.

세 번째 메커니즘은 일반 IPv6 주소를 유지하고 수신자가 해석하도록 완전한 출처 또는 목적지 NSAPA 옵션을 붙였다. 이 기능을 사용하지 않는 노드는 구현할 의무가 없었다. 따라서 옵션의 존재는 발신자가 데이터를 제공했다는 사실만 증명할 뿐, 중간 노드나 목적지 노드가 이를 이해하거나 활성화하거나 처리했다는 증거가 아니었다.

네 번째 방향은 중첩을 뒤집었다. IPv6 주소를 IANA AFI 35와 초기 도메인 식별자(ICP) 아래 20옥텟 NSAPA 안에 넣은 것이다. RFC 1888은 ICP 0을 IPv6에 배정했다. 또한 재귀적 중첩을 금지했다. 한 주소 체계를 다른 체계 안에 반복적으로 넣는 것은RFC 1326에서 논의된 종류의 이상 현상이나 루프를 만들 수 있었다.

이전 맥락은 제안의 범위를 한정하는 데 도움이 된다.RFC 1629는 ATM 위에서의 NSAP 사용을 설명했고,RFC 3513은 나중에 IPv6 주소 아키텍처를 규정했다. 어느 쪽도 RFC 1888 매핑을 배포 증거로 만들지 않는다. 둘은 이 실험을 읽어내는 기준이 되는 인접 구조를 정의한다.

은퇴는 미사용과 명세 오류를 분리했다

9년 뒤RFC 4048은 서로 다른 두 가지 판단을 내렸다. 문서는 IETF가 아는 한 NSAP-inside-IPv6 매핑이 진지하게 사용된 적이 없고 IPv6 구현에서 지원되지 않았다고 말했다. 이는 모든 비공개 구현에 대한 조사가 아니라, 신중하게 출처를 붙인 기관 평가다. 이는 역사(Historic) 지위를 권고하고 기존 NSAP IPv6 프리픽스 할당을 예약(Reserved) 상태로 되돌리는 근거가 되었다.

역방향 IPv6-inside-NSAPA 메커니즘은 최근 관심을 끌었고 ATM 사용 가능성도 거론되었기 때문에 별도로 다루어졌다. 여기서 문제는 겉보기 미사용만이 아니었다. RFC 1888의 6절에는 외부 네임스페이스에 관한 두 가지 오류가 있었다. ICP 필드는 16비트, 즉 2옥텟이지 세 번째 단일 옥텟이 아니었다. 그리고 4자리 십진수 IDI는 제한 없는 이진 정수가 아니라 2옥텟의 BCD(이진화 십진법)로 인코딩되었다.

이 구분은 지나치게 광범위한 결론을 막았다. RFC 4048은 RFC 1888의 모든 매핑 등식이 산술적으로 거짓이라고 말하지 않았다. 한 체계는 사용되지 않은 것으로 보이며, 역방향 절에는 정확한 대체물이 필요하다고 말했다. IANA는 그 대체물이 준비되는 동안 ICP 레지스트리를 보류 상태로 두었다.

RFC 4548이 2006년에 그 대체물을 제공했다. AFI 35에서 십진수 ICP 0은 공개된 IPv6 형식을, ICP 1은 IPv4 형식을 식별한다. 2부터 9999까지의 값은 정의되고 공개된 형식과 IETF 합의가 있을 때만 사용할 수 있다. 현재의IANA OSI NSAPA Numbers 레지스트리는 그 의미를 기록한다. 그 행들은 네임스페이스 할당을 증명할 뿐, 파서나 활성화된 기능, 경로, 패킷을 증명하지 않는다.

RFC 4548은 6절만 대체했다. IPv6 안의 제한형 또는 절단형 NSAPA를 부활시키지 않았다. 이 수리는 주변 실험이 역사(Historic)가 된 뒤에도 좁은 코드 포인트 기능을 보존했다. 그것이 유용한 결말이다. 표준 유지보수는 쓸모없어진 아키텍처가 돌아왔다고 가장하지 않으면서 정당한 네임스페이스 요구를 구할 수 있다.

RFC 1888,RFC 4048및RFC 4548에 대한 RFC Editor 정보 페이지는 각 문서의 지위와 업데이트 관계를 보존한다. 기본 문서들과 함께 이들 수령 사다리를 확립한다. 문서는 계획을 정의할 수 있다. 알고리즘은 바이트를 보존할 수 있다. IANA는 의미를 등록할 수 있다. 소프트웨어는 이를 파싱할 수 있다. 정책은 이를 활성화할 수 있다. 라우팅은 이를 전달할 수 있다. 수신자는 이를 수용할 수 있다. 그리고 관찰은 사용을 확립할 수 있다. 어떤 단계도 다음 단계를 인증하지 않는다.