요약

  • RFC 3021은 /31 프리픽스의 두 값을 모두 호스트 주소로 해석하도록 요구함으로써, 번호가 부여된 IPv4 포인트투포인트 링크에 필요한 주소를 네 개에서 두 개로 줄였습니다.
  • 이 절약은 실제로 양쪽 끝이 존재하는 링크와 양측 구현 지원에 의존했습니다. 프리픽스 자체가 토폴로지, 호환성, 도달 가능성 또는 전달을 증명해 주지는 못했습니다.

2000년 12월 당시 주소 보존은 주로 인터넷 규모에서 논의되고 있었습니다. 할당 정책, 사설 주소 공간, NAT, 그리고 여전히 멀었던 IPv6 전환이 그 대상이었습니다. RFC 3021은 인프라 내부에서 더 작은 지렛대를 찾아냈습니다. 관례적인 /30은 라우터 인터페이스 두 개에 번호를 부여하기 위해 주소 네 개를 소모했습니다. 두 개는 라우터를 식별했고, 전부 0인 호스트 값은 서브넷을 나타냈으며, 전부 1인 값은 그 서브넷의 디렉티드 브로드캐스트 역할을 했습니다. 그러나 포인트투포인트 링크에는 끝점이 둘만 존재할 수 있었습니다. 한쪽 끝이 보낸 모든 패킷은 다른 쪽 끝에 도달했고, 디렉티드 브로드캐스트가 선택할 호스트 집단은 존재하지 않았습니다.

이 RFC는 좁은 재해석을 제안했습니다. 31비트 마스크는 호스트 비트를 하나만 남기므로 가능한 값이 두 개입니다. 이 특수한 종류의 링크에서는 두 값이 모두반드시(MUST)호스트 주소여야 합니다. 기존의 서브넷 형태 값은 한쪽 끝점이 되었고, 기존의 브로드캐스트 형태 값은 다른 쪽 끝점이 되었습니다. 비트 패턴 자체는 바뀌지 않았습니다. 링크의 속성이 그 값들에 적용되는 규칙을 바꾼 것입니다.

이 구분이 바로 그 역사입니다. RFC 3021은 단순한 산술적 최적화가 아니었습니다. 주소 의미를 인터페이스에 대한 증거에 조건부로 만든 것입니다.

주소 두 개가 절약된 것이지, 의문 두 개가 해결된 것은 아니다

회계상의 매력은 분명했습니다. 포인트투포인트 링크 500개를 가진 네트워크는 /30에서는 2,000개의 주소를 쓰는 대신 /31에서는 1,000개를 쓰게 되어, 당시 용어로 클래스 C 규모 블록 네 개에 해당하는 주소를 회수할 수 있었습니다. 넘버링되지 않은(unnumbered) 링크와 달리 각 인터페이스는 관리와 디버깅을 위한 주소를 유지했습니다. PPP 끝점에 무관한 호스트 라우트를 배정하는 방식과 달리, 두 주소는 모두 하나의 평범한 프리픽스 안에 머물렀습니다.

그러나 마스크가 이를 정당화하는 조건을 만들어 낸 것은 아니었습니다. 운영자는 여전히 해당 인터페이스가 포인트투포인트라는 사실을 알아야 했고, 양쪽 장비가 특수 처리를 지원해야 했습니다. RFC 3021은 한쪽 끝만 31비트 프리픽스를 구현하는 경우 링크가 올바르게 동작하지 않을 수 있다고 직접 경고했습니다.

짝에서 상위 주소를 생각해 보십시오. /31에 연결된 호환 라우터는 그 값으로 향하는 패킷을 자신의 로컬 인터페이스로 전달해야 합니다. 더 오래되었거나 호환되지 않는 피어는 같은 값을 여전히 일반 브로드캐스트 규칙으로 분류할 수 있습니다. 설정 텍스트는 일치하지만 실행 중인 해석은 서로 갈라질 수 있습니다.

디렉티드 브로드캐스트가 사라진 것은 남는 값이 없었기 때문이다

/31에는 디렉티드 브로드캐스트를 위해 예약할 세 번째 값이 없습니다. 따라서 RFC 3021은 해당 링크로의 디렉티드 브로드캐스트를 없앴습니다. 브로드캐스트 트래픽이 필요한 곳에서는 제한된 브로드캐스트(limited broadcast)가 계속 사용 가능했습니다. 원격 라우팅에 새로운 전역 규약은 필요하지 않았습니다. 목적지 세그먼트에 직접 연결된 라우터가 해당 주소가 브로드캐스트인지 끝점인지를 결정했습니다.

이 제거에는 보안 부수 효과가 있었습니다. 디렉티드 브로드캐스트 주소가 없는 링크는 스머프(smurf) 시대의 패킷 복제 공격에 그런 표적을 제공하지 않았습니다. RFC 2644가 이미 디렉티드 브로드캐스트를 둘러싼 라우터 기본값을 바꾼 상태였습니다. RFC 3021은 그 특정 메커니즘이 존재할 수 있는 물리 링크의 수를 줄였습니다. 다만 이는 피어 인증, 라우팅 교환 보호, 서비스 거부 위험 제거를 의미하지는 않았습니다.

이 예외는 기존 규칙을 지우지 않고 수정했다

이전의 호스트 및 라우터 요구사항들은 전부 0과 전부 1의 호스트 필드를 특수하게 다루었습니다. RFC 950은 1비트 호스트 필드의 가능성을 언급하면서, 사용 가능한 두 값이 통상 호스트로 쓸 수 없는 이유를 설명했습니다. RFC 3021은 그 이전 의미들이 틀렸다고 선언하지 않았습니다. RFC 1122와 RFC 1812에 범위가 한정된 예외를 추가했습니다. 31비트 마스크를 운용하는 포인트투포인트 링크 위에 발신자나 수신자가 있을 때는 그 값들을 끝점으로서 발신, 수신, 전달할 수 있게 된 것입니다. 다른 링크 유형에서는 기존의 폐기(discard) 또는 브로드캐스트 규칙이 그대로 유지되었습니다.

이 때문에 /31을 한정어 없이 '네트워크 주소와 브로드캐스트 주소를 사용하는 것'이라고 서술해서는 안 됩니다. 이는 운영자가 예약된 의미를 무시한 것이 아니라, 정의된 인터페이스 조건 하에서 그 의미를 바꾼 표준 트랙(standards-track) 변경이었습니다.

라우팅 인접성은 필요한 증거였지, 최종 증명은 아니었다

RFC 3021은 클래스리스(classless) 라우팅 프로토콜이 방해받지 않는다고 밝히고, 최소 세 개의 ISP에서 OSPF, IS-IS, BGP, EIGRP를 대상으로 한 긍정적인 베타 경험을 보고했습니다. 이는 유용한 동시대 증거이지만 한정된 증거입니다. 이는 당시의 보편적 벤더 지원, 현재의 배포 현황, 또는 특정 링크에서의 성공적인 트래픽을 확립하지 않습니다.

라우팅 인접성은 두 컨트롤 플레인이 메시지를 교환했음을 보여줄 수 있습니다. 그것만으로는 각 끝점이 모든 로컬 경로에서 /31의 두 값을 올바르게 처리하는지, 관리 도구가 그 표기를 받아들이는지, 필터가 주소를 보존하는지, 애플리케이션이 유용한 데이터를 수신했는지 증명하지 못합니다. 그 주장들은 각자의 근거를 필요로 합니다.

출처

Lu Heng은 RFC 3021을 작성했거나 승인한 바 없습니다. 그의 에세이는 이 글에서 명시된 분석적 렌즈로 사용되었습니다.