핵심 요약

  • RFC 1930은 자율 시스템을 회사 이름이나 라우터 수가 아니라 하나의 명확한 라우팅 정책으로 정의했습니다.
  • 1994년 RIPE 모델은 이미 관리 정보와 기술 정보를 분리하고 있었고, 1996년의 모범 사례는 독립 ASN 추가가 언제 라우팅상 의미를 갖는지 명확히 했습니다.

분석

조직이 라우터와 네트워크 블록을 보유하고, ISP로부터 연결을 구매하더라도 자체 자율 시스템 번호가 필요하지 않을 수 있습니다. 이것이 RFC 1930의 직관에 반하는 아이디어입니다. 1996년 3월 당시 IETF의 모범 사례는 ASN을 인터넷에 연결된 모든 조직의 배지로 취급하지 않았습니다. 대신 자율 시스템을 하나 이상의 주체가 하나의 명확히 정의된 라우팅 정책에 따라 운영하는 IP 프리픽스 집합으로 정의했습니다. 다른 네트워크들이 그 정책을 구별할 필요가 있을 때 비로소 번호가 유용해집니다.

이 결과는 단일 ISP에 의존하는 고객에게서 분명히 드러납니다. 고객의 경로가 ISP의 정책을 따른다면, RFC 1930에 따르면 별도 AS 생성은 보통 불필요하며, 고객의 프리픽스는 ISP의 AS 안에 남을 수 있습니다. 반면 여러 ISP에 동시 접속하는 사이트는 자신의 선호와 정책을 그들 사이에서 표현해야 할 때 상황이 달라집니다. 쟁점은 케이블, 라우터, 계약의 수가 아니라, 다른 네트워크로 향하는 광고가 피어들의 정책과 다른 정책을 나타내는지 여부입니다.

등록 절차에서도 이 구분이 나타나기 시작했습니다. 1994년 3월 1일자 RIPE-109는 AS 신청을 관리 부분과 기술 부분으로 나눴습니다. 관리 부분은 필수였고, 기술 세부사항은 신청 시점에 불완전할 수 있었으며 RIPE는 이후 송신을 권고했습니다. 이 양식에는 운영자가 피어들로부터 수용하는 경로와 그들에게 광고하는 경로를 기술하는 AS 오브젝트와as-in,as-out문이 포함되어 있었습니다. RFC 1930은 자신의 광범위한 지침이 RIPE 지역 문서 위에 구축되었다고 명시적으로 언급합니다.

이 문서는 용어만 바로잡은 것이 아니라 분류 오류를 다루었습니다. 전통적인 AS 정의는 단일 기술 관리와 공유 내부 프로토콜에 결부되어 있었습니다. 그러나 하나의 시스템은 다른 네트워크 앞에서 일관된 라우팅 계획을 유지하면서 여러 내부 프로토콜과 서로 다른 메트릭을 사용할 수 있습니다. 반대로 한 회사 안에 상이한 라우팅 정책이 공존할 수도 있습니다. 기준선은 조직 구조나 장비 목록이 아니라 다른 네트워크가 보는 정책입니다.

정의의 정확성이 중요했던 이유는 번호 공간이 유한하기 때문입니다. RFC 1930은 당시 이 공간을 16비트로 기술했고, 저자들은 약 5,100개의 번호가 할당되었으며 1996년에 실제로 글로벌 라우팅에 참여한 번호는 600개 미만이라고 밝혔습니다. 이는 현재 통계가 아니라 역사적 수치입니다. 문서는 AS를 단순히 일상적인 관리 절차라는 이유로 생성하는 것을 경고했고, 64512부터 65535까지의 번호를 사적 사용으로 지정했습니다. 그리고 2007년, RFC 4893은 호환 메커니즘을 갖춘 BGP의 4옥텟 번호로의 점진적 전환을 마련했으며, 이후 RFC 6793이 그를 대체했습니다.

이는 단순한 번호 부족 이야기가 아니라, 번호가 무엇을 특정해야 하는지에 대한 이야기입니다. ASN은 공개 레지스트리나 BGP 경로에서 라우팅 정책의 경계를 나타낼 수 있지만, 그것만으로 누가 모든 라우터를 운영하는지, 어떤 경로가 수용되었는지, 서비스가 어디에서 제공되는지 증명하지 못합니다. 신청 양식, 프로토콜, 네트워크 관찰은 서로 다른 기록입니다. 이들을 혼동하면 유용한 식별자가 입증할 수 없는 주장의 증거로 변질됩니다.

출처