요약

  • RFC 3330은 산재해 있던 특수 용도 IPv4 블록들을 하나로 모아, 수치상 비슷한 주소라도 호스트·발신지·수신지·포워딩·누출 규칙이 완전히 다를 수 있음을 명시적으로 만들었다.
  • 그 표는 역사적 스냅샷이었지 영구적인 보안 오라클이 아니었다. 후속 RFC들과 실시간 IANA 레지스트리는 분류를 다차원적이고 버전화된 것이며 더 구체적인 항목의 영향을 받는 것으로 만들었다.

하나의 번호 공간에 여러 종류의 장소가 담겨 있었다

평범한 할당은 공개 라우팅을 통해 도달하는 호스트를 식별할 수 있다. 그러나 127/8은 호스트 내부로 돌아오도록 되어 있다. RFC 1918 사적 공간은 관리상 내부망에 속한다. IPv4 링크 로컬 주소는 평범한 구성이 불가능할 때 하나의 링크에서만 사용된다. 문서화 및 벤치마크 범위는 예제와 통제된 테스트가 실제 목적지를 빌려 쓰지 않도록 존재한다. 멀티캐스트와 제한적 브로드캐스트는 또 다른 포워딩 규칙을 따른다.

RFC 3330 이전에는 이러한 의미들이 개별 RFC와 할당 번호 기록에 흩어져 있었다. 이 문서는 그것들을 하나의 시야로 모았다. 또한 IANA의 표준 지원 할당과 지역 인터넷 레지스트리(RIR)에 할당되는 평범한 공간을 구분했다. 그 결과는 편리한 표 이상이었다. 평면적인 수치 공간 위에 얹힌 초기 운영용 타입 체계였다.

그 타입들은 서로 교환 불가능했다. 루프백 목적지는 절대 그 기계 밖으로 나가서는 안 된다. 외부 인터페이스에서 관찰된 사적 발신지는 내부 출처의 증거로 신뢰해서는 안 된다. 문서화 주소는 도달 가능한 서비스 의존성이 아니라 문서와 구성 예제 속에 있어야 한다. 벤치마크 주소는 생산 포워딩이 아니라 격리된 테스트 방법 안에 있어야 한다.

RFC 3330의 보안 절은 신뢰 경계를 명시했다. 인터넷은 특수 주소의 악용을 자체적으로 막지 않는다. 운영자가 10/8에서 온 모든 패킷이 내부에서 왔다고 가정한다면, 경계 장비가 그 가정을 강제해야 한다. 주소는 정책 입력이지 출처 인증서가 아니다. 사적 공간을 담고 있는 패킷 캡처는 어떤 비트가 관찰되었는지를 증명할 뿐, 패킷이 어디서 만들어졌는지를 증명하지 않는다.

‘특수’는 결코 단일한 속성이 아니었다

단일 불리언 값은 메커니즘을 잃는다. 어떤 주소는 발신지로는 유효하나 수신지로는 아닐 수 있고, 링크에서는 사용 가능하나 포워딩 불가능할 수 있으며, 제한된 도메인 안에서는 포워딩되지만 전역적으로 도달 불가능할 수 있고, 프로토콜 자체가 의미를 부여하도록 예약되어 있을 수도 있다. 따라서 라우터, 호스트, 방화벽, 문서 검사기, 테스트 하네스는 같은 프리픽스에 대해 서로 다른 질문을 던진다.

RFC 3330은 이러한 구분을 산문으로 표현했다. 후속 문서들은 그것을 더 형식화했다. RFC 5735는 2002년 스냅샷을 대체하고 목록을 갱신했다. 그 다음 RFC 6890이 유지 관리되는 IPv4 및 IPv6 특수 용도 주소 레지스트리를 만들었다. 각 항목은 발신지 유효성, 수신지 유효성, 포워딩 가능성, 전역 도달 가능성, 프로토콜에 의한 예약 등 별도의 운영 속성을 담는다.

RFC 8190은 이후 전역 도달 가능성을 명확히 했다. 이는 의도된 운영 속성이며, 어떤 경로도 광고되지 않을 것이라거나 어떤 패킷도 누출되지 않을 것이라는 주장이 아니다. 이는 인시던트 분석에서 중요하다. 공개 컬렉터에서 전역적으로 도달 불가능한 것으로 알려진 프리픽스를 발견하는 것은 누출, 필터 실패, 스푸핑 또는 측정 오류를 보여줄 수 있지만, 관찰만으로 레지스트리 속성을 다시 쓰지는 않는다.

분류에는 최장 프리픽스 논리도 필요하다. 넓은 블록은 서로 다른 동작을 가진 더 좁은 할당을 포함할 수 있다. 첫 번째로 일치하는 넓은 범주만 확인하면 잘못된 발신지 또는 포워딩 정책을 낳을 수 있다. 근거 영수증은 정확한 최장 일치 항목과 결정에 사용된 각 속성을 명시해야 한다.

표가 바뀐 이유는 네트워크가 바뀌었기 때문이다

RFC 3330에는 특수 지위가 끝나가던 블록이나 나중에 처리가 달라진 블록도 포함되어 있었다. 그것은 오류가 아니라 한 순간을 기록한 것이었다. 위험은 2002년의 스냅샷이 소프트웨어, 보안 보고서 또는 컴플라이언스 규칙에 영구히 심어질 때 시작된다.

그 후 RFC 5737은 원래 TEST-NET 블록만이 아니라 세 개의 문서화 프리픽스를 예약했다. RFC 3927은 IPv4 링크 로컬 동작을 완전히 기술했다. RFC 6890은 산문형 스냅샷을 유지 관리용 레지스트리로 대체했다. 따라서 오늘날의 운영 출처는 실시간 IANA IPv4 특수 용도 주소 레지스트리이며, RFC 3330은 그 목록이 어떻게 형성되었는지에 대한 역사적 근거로 남는다.

버전은 양방향으로 중요하다. 현대의 레지스트리를 과거에 투영하여 2002년의 운영자가 나중의 속성에 구속되었다고 주장할 수 없다. 오래된 RFC를 미래에 투영하여 오늘의 패킷을 분류할 수도 없다. 방어 가능한 진술은 관찰 시각, 레지스트리 스냅샷, 정확한 프리픽스, 결정 필드를 기록한다.

할당 절차는 또한 기술적 요구사항을 일반적인 주소 정책과 분리했다. RFC가 표준화 과정을 위해 특수한 IPv4 블록을 필요로 할 때, 크기와 프리픽스 길이 같은 기술적 필요를 명시해야 했다. IANA는 RIR들과 협의하여 출판 무렵 할당을 마련했다. RFC 3330은 그 관행을 기술했을 뿐, 모든 실험에 영구 예약을 부여하거나 스스로 새 할당 규칙을 만든 것은 아니다.

레지스트리 항목은 스스로를 강제하지 않았다

그 목록은 구현자에게 블록이 어떻게 동작하도록 의도되었는지 알려줄 수 있었다. 그러나 모든 호스트가 무효한 발신지를 거부하게 만들거나, 모든 경계 필터가 누출을 폐기하게 만들거나, 모든 벤더가 내장 목록을 갱신하게 만들 수는 없었다. 레지스트리의 의도와 관찰된 동작 사이의 거리는 운영 표면이다.

사적 주소는 스푸핑이나 설정 오류로 공개적으로 나타날 수 있다. 루프백 값은 로컬 API 관례로 로그에 나타날 수 있다. 문서화 주소는 복사된 예제에서 빠져나올 수 있다. 벤치마크 트래픽은 생산 텔레메트리를 오염시킬 수 있다. 각 사건은 단순한 조회 라벨이 아니라 패킷 방향, 인터페이스, 캡슐화, 변환 상태, 강제 결과를 필요로 한다.

그래서 RFC 3330의 지속된 역사는 유명한 프리픽스의 암기가 아니다. 전역적으로 공유되는 식별자 공간은 정밀하고 유지 관리되는 의미를 가진 예외가 필요하다는 발견이다. 주소 값, 레지스트리 타입, 강제 조치, 관찰된 결과는 서로 다른 네 가지 영수증이다. 이를 하나로 합치면 유용한 목록이 출처나 도달 가능성에 대한 거짓 진술이 된다.

출처