요약

  • RFC 4012는 기존import,export,default속성을 IPv4 유니캐스트 체계 그대로 유지하면서, 주소 패밀리를 인식하는 정책을 위한mp-*속성을 추가했습니다.
  • 이 새로운 속성에서 선택적 AFI 절이 생략되면 IPv4/IPv6 유니캐스트와 멀티캐스트 전체를 아우르는any를 뜻하며, “패밀리 미지정”을 의미하지 않습니다.

비어 있던 AFI는 빈 필드가 아니었다

afi절이 없는mp-import를 마주한 독자라면 해당 문장에 패밀리 범위가 없다고 추정할 수 있습니다. RFC 4012는 정반대의 선택을 했습니다. 생략된 절은 IPv4 유니캐스트, IPv4 멀티캐스트, IPv6 유니캐스트, IPv6 멀티캐스트를 모두 포괄하는 정의된 범위인any로 해석됩니다. 즉, 빠진 단어 하나가 하나의 규칙을 담고 있는 것입니다. 이는 각 파서나 운영자가 임의로 추측하라는 초대장이 아닙니다.

이 기본값은 새로운mp-*속성에만 적용됩니다. 오래된import,export,default속성은 확립된 IPv4 유니캐스트 의미를 그대로 유지합니다. 그结果, RFC 4012는 두 종류의 모호성을 동시에 피했습니다. 기존 레코드가 조용히 재해석되지 않고, AFI가 없는 새 멀티프로토콜 표현도 의미상 비어 있도록 방치되지 않습니다. 검토자에게 첫 번째 질문은 단순히 “어떤 정책 텍스트가 뒤따르는가?”가 아니라 “나머지를 읽기 전에 문법이 어떤 범위를 부여했는가?”입니다.

구(舊) 어휘에는 패밀리 경계가 있었다

1999년에 발표된 RFC 2622는 IPv4 유니캐스트 라우팅을 위한 라우팅 정책 명세 언어(RPSL)를 정의했습니다. 익숙한import,export,default속성은 운영자가 자율 시스템(AS)이 경로를 어떻게 교환할지 기술하는 수단이었습니다. 2005년 RFC 4012는 호환성을 유지하고 변경의 범위를 제한하면서 IPv6 및 멀티캐스트 정책을 위해 이 모델을 확장했습니다.RFC 2622RFC 4012

이름이 중요했던 이유는, 구식 파서가 구식 속성에서 새 패밀리를 안전하게 추론할 수 없기 때문입니다. 그래서 RFC 4012는 기존 속성의 IPv4 유니캐스트 의미를 유지하고mp-import,mp-export,mp-default를 추가했습니다.afi절은ipv4.unicast,ipv4.multicast,ipv6.unicast,ipv6.multicast등 정의된 범위를 지정할 수 있었습니다.mp-*속성이 이 선택적 절을 생략하면, 명세는 네 패밀리 전체를 아우르는 넓은any범위를 부여했습니다. 이는 정책 표현을 읽는 규칙이지, 라우터가 네 패밀리를 모두 지원하거나 적용한다는 증거가 아닙니다.RFC 4012, 2.1~2.5절

이것은 모든 네트워크가 같은 방식으로 멀티프로토콜이 되었다는 주장이 아니라 신중한 확장이었습니다. 이 언어는 범용 IPv4 유니캐스트 어휘로는 깔끔하게 표현할 수 없는 정책을 레지스트리가 구분할 수 있게 해 주었고, 동시에 기존 레코드와 구현이 이전 의미를 유지할 여지도 남겼습니다.

RPSLng는 범위를 결합(compose)하기도 합니다.ipv4와ipv6는 각각 해당 버전의 유니캐스트와 멀티캐스트를 모두 포괄하고,any.unicast와any.multicast는 두 버전에 걸쳐 한 트래픽 유형을 포괄하며,any는 네 기본 조합 전체의 합집합입니다. 이 문법이 간결한 이유는 이런 합집합에 이름이 붙어 있기 때문이지, 그 범위가 암묵적이어서가 아닙니다.

같은 AFI 약어가 서로 다른 계층을 가리킨다

RFC 4012는route6클래스도 추가하지만, 그 객체 키와 변경 권한 부여는 선택적 AFI 규칙과 별개이며, 그 권한 부여 문제는 RFC 2725가 다룹니다. 이는 경계 맥락일 뿐 이 글의 또 다른 논지가 아닙니다.RFC 4012, 3절RFC 2725

BGP 역시 AFI/SAFI 라벨을 사용하지만, RFC 4760은 이를 UPDATE 메시지의 네트워크 계층 도달 가능성 및 넥스트홉 필드에 붙입니다. RFC 4012의 선택적 AFI는 RPSL 정책 표현의 범위를 한정합니다. 공유 어휘가 있다고 두 문장이 서로 바꿔 쓸 수 있는 것은 아니며, 경로 선택과 이웃별 광고는 RFC 4271의 런타임 프로세스에 속합니다.RFC 4271RFC 4760

이름 붙은 AFI 합집합이 문법을 조합 가능하게 만들었다

가장 쉬운 역사적 요약은 “RPSL이 IPv6을 배웠다”입니다. 더 정확히는, RFC 4012가 정책의 주소 패밀리 범위를 표현 가능하게 만들고 버전과 트래픽 유형에 걸친 합집합에 이름을 붙였다는 것입니다. 이는 언어 설계에 대한 서술이지, 네트워크들이 두 버전을 같은 방식으로 다루기 시작했다는 뜻이 아닙니다.

이런 정밀성이 유용한 이유는 주소 패밀리가 서로 바꿔 쓸 수 있는 라벨이 아니기 때문입니다. 하나의 네트워크는 IPv4와 IPv6에 대해 서로 다른 피어, 필터, 넥스트홉, 도달 가능성, 운영 결정을 가질 수 있습니다.any에 적용되는 문장은ipv6.unicast를 명시한 문장보다 넓으며, 이 구분은 레코드 안에 담겨야 합니다. 그래도 운영자가 무엇을 수용하거나 광고할지에 대한 별도의 결정은 사라지지 않습니다.

이후의 BGP 정책 작업은 시간적 대비를 제공합니다. 2017년에 발표된 RFC 8212는 명시적인 EBGP import·export 정책을 요구하지만, 이는 BGP 동작을 다루는 것이며 RFC 4012가 RPSL에서 생략된 AFI를 해석하는 방식을 바꾸지 않습니다.RFC 8212

명세는 범위를 정했고, 구현이 그것을 실행에 옮겼다

Lu Heng의 노트 65와 64는 이 설계 선택에 대한 편집적 렌즈를 제공합니다. 즉, 공유 명세는 독립적인 파서들이 같은 텍스트에서 같은 범위를 도출할 수 있을 때 유용하다는 것입니다. 이는 RFC 4012의 저자나 그 동기에 대한 주장이 아닙니다.any기본값은 결정론적인 공통 독해를 제공하며, 그 넓은 범위가 자신의 정책과 맞는지, 시스템이 무엇을 실행할지는 개별 운영자가 여전히 결정합니다.노트 65노트 64

이 확장에서 가장 영향력 큰 부분은 아마 쓰이지 않은 절의 가치일 것입니다.mp-*표현에서 AFI가 없다는 것은 문장을 좁히거나 판단을 유보하는 것이 아니라, 이름 붙은 합집합any를 호출하는 것입니다. 따라서 RFC 4012는 단순히 IPv6 어휘를 추가한 데 그치지 않고, 범위를 조합 가능하게 만들고 생략을 결정론적으로 만들면서 기존 IPv4 유니캐스트 계약을 그대로 지켰습니다.

이 표준들은 채택률, 데이터베이스 완전성 지표, 특정 운영자 구성, 경로 누출(route leak), IPv6 배포 결과 중 어떤 것도 확립하지 않습니다. 지지되는 결론은 더 좁습니다. RFC 4012는 RPSL 정책 표현의 범위를 더 정밀하고 결정론적으로 만들었다는 것입니다.

1차 출처