Кратко
- RFC 1930 определил автономную систему через единую, чётко заданную политику маршрутизации, а не название компании или количество маршрутизаторов.
- Форма RIPE 1994 года уже разделяла административные и технические сведения; рекомендация 1996 года пояснила, когда отдельный ASN добавляет смысл маршрутизации.
Анализ
Когда сеть подключена к двум провайдерам, важно не число её маршрутизаторов, а какие маршруты она объявляет каждому соседу и по какой политике. Эти объявления помогают другим сетям решать, принимать ли путь и куда направлять трафик. RFC 1930 объясняет, зачем для этого нужен номер автономной системы: в марте 1996 года рекомендация IETF определила AS как группу IP-префиксов с единой, чётко заданной политикой маршрутизации. ASN нужен, когда соседним сетям требуется отличить эту политику.
Для клиента с одним провайдером это практическое различие. Если его маршруты следуют политике провайдера, отдельная AS обычно не требуется: RFC 1930 допускает включить его префиксы в систему провайдера. Иначе устроена многосвязная сеть, которой нужно показать собственные предпочтения между несколькими операторами. Решает не количество кабелей, маршрутизаторов или договоров, а то, должна ли внешняя сеть видеть отдельную политику в объявлениях маршрутов.
Заявочная процедура уже отражала эту границу. RIPE-109 от 1 марта 1994 года делил заявку на AS на административную и техническую части. Первая была обязательной; технические сведения разрешалось не указывать полностью при подаче, хотя RIPE просил дослать их позже. В форме был объект AS с выражениями as-in и as-out: ими описывали, какие маршруты оператор принимает от соседей и какие объявляет им. RFC 1930 прямо указывает, что более широкие рекомендации выросли из этого регионального документа RIPE.
Документ исправлял не только терминологию, но и категориальную ошибку. Классическое определение связывало AS с единой технической администрацией и общим внутренним протоколом. RFC 1930 пояснил, что одна система может использовать несколько внутренних протоколов и метрик, сохраняя связный план маршрутизации для внешних сетей. И наоборот, внутри одной компании могут действовать разные политики. Граница проходит по политике, видимой соседям, а не по оргструктуре или списку оборудования.
Точность имела значение и потому, что пространство номеров было конечным. В RFC 1930 оно описано как 16-битное; авторы приводят около 5 100 выделенных номеров и менее 600 активно маршрутизируемых в глобальном Интернете на 1996 год. Это исторические цифры документа, не современные подсчёты. RFC предостерегал от выдачи AS «по привычке» и резервировал 64512–65535 для частного использования. В 2007 году RFC 4893 ввёл постепенный переход BGP к четырёхоктетным ASN с механизмами совместимости; позднее его сменил RFC 6793.
Эта история не сводится к исчерпанию номеров. Она о том, что именно номер должен обозначать. ASN может маркировать границу политики в публичной записи или пути BGP, но сам по себе не доказывает, кто управляет каждым маршрутизатором, принят ли маршрут и где доступна услуга. Заявка, протокол и наблюдение сети — разные доказательства. Если их смешать, полезный идентификатор превращается в утверждение, которого он подтвердить не может.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
