Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
updates
- rfc-4271 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (25)
Good operational hygiene dictates avoiding long-term use of 'Internal BGP AS Migration' to maintain operational simplicity and reduce reliance on non-standard behavior during ongoing software and configuration lifecycle management. The iBGP migration can be completed in days to months since all routers are under a single administrative entity.
Legacy ASNs and associated External BGP AS Migration mechanisms commonly persist in operational networks for several years or indefinitely because ISPs lack control over customer CE device configurations and cannot coordinate mass simultaneous reconfiguration. Operators must plan for these mechanisms to remain active long-term.
Preserving AS_PATH length during migration is critical because BGP path selection favors shorter AS_PATHs. Artificially lengthening the AS_PATH during migration would cause sudden, undesirable traffic pattern shifts. The three mechanisms (Local AS, No Prepend, Replace Old AS) work together specifically to prevent any AS_PATH lengthening.
The AS migration mechanisms are designed to allow an ISP to change its ASN without coordinating simultaneous changes with potentially tens of thousands of customers. The asymmetric approach lets the ISP migrate internally while customers gradually update their configurations, avoiding mass-outage risk from ASN mismatch.
The 'Internal BGP AS Migration' mechanism was designed because traditional iBGP migration — requiring simultaneous reconfiguration of global ASN and all iBGP neighbor remote-ASN values — is too risky and disruptive in large networks. The new mechanism allows migration over days or weeks with reduced customer disruption, with the only observable disruptions occurring at individual PE maintenance windows.
These mechanisms are local to a given BGP speaker and do not require negotiation with or cooperation of BGP neighbors. Slight variations between vendor implementations exist and will not necessarily be harmonized, since interworking between the variations is not required to accomplish migration goals.
If the 'Local AS' mechanism is used without 'No Prepend Inbound', the AS_PATH seen by remote iBGP peers will contain the legacy ASN (e.g., 64510 64496 instead of 64496), which is an unacceptable lengthening. Both mechanisms must be used together to keep AS_PATH length unchanged internally.
If there are still routers operating under the old ASN, it is possible for them to accept routes that had the old ASN removed from the AS_PATH by 'No Prepend Inbound' as if those routes had not passed through their ASN. This bypasses BGP's normal loop-prevention, potentially causing routing loops. Careful filtering between old-ASN and new-ASN routers is necessary.
Implementations MAY support a flexible model where the eBGP speaker attempts to open the session using either the 'Local AS' or the globally configured ASN. If the session establishes to the globally configured ASN, the AS_PATH modifications described in this document SHOULD NOT be performed, as they are unnecessary.
The 'Internal BGP AS Migration' mechanism preserves the semantics of a regular iBGP session (identical ASNs). BGP attributes transmitted and acceptable operations on attributes received are no different than standard iBGP as defined by RFC 4271 and RFC 4456.
The procedures described for 'Local AS' and 'Internal BGP AS Migration' vary slightly when a locally or globally configured ASN is a 4-octet ASN. Implementors must refer to Section 3 of RFC 6793 for the applicable differences.
A BGP router configured with 'Internal BGP AS Migration' MUST treat UPDATEs sent and received on this session as if it were a natively configured iBGP session, as defined by RFC 4271 and RFC 4456. The BGP attributes and acceptable operations are identical to standard iBGP.
The 'Internal BGP AS Migration' mechanism MUST be configurable on a per-neighbor or per-neighbor-group basis. A BGP speaker configured with it MUST accept BGP OPEN from iBGP peers whose 'My Autonomous System' field contains either the globally configured ASN or the locally configured legacy ASN.
The 'Local AS', 'No Prepend Inbound', and 'Replace Old AS' mechanisms MUST be configurable on a per-neighbor or per-neighbor-group basis to allow for maximum flexibility.
To avoid potential deadlocks when two BGP speakers both configured with 'Internal BGP AS Migration' attempt to establish a session, the speaker SHOULD send BGP OPEN using the globally configured ASN first, and only fall back to the locally configured ASN if the remote neighbor responds with 'Bad Peer AS'.
When 'Local AS' is active, the router SHOULD append the configured 'Local AS' ASN in the AS_PATH attribute before installing the route or advertising the UPDATE to an iBGP neighbor (internal direction). For external direction, it SHOULD first append the globally configured ASN then the 'Local AS' value before advertising to an eBGP neighbor.
When 'No Prepend Inbound' is configured, the BGP router MUST NOT append the 'Local AS' ASN value to the AS_PATH when installing or advertising inbound updates to iBGP neighbors, but MUST still append the globally configured ASN when advertising to other local eBGP neighbors.
When 'Replace Old AS' (outbound) is configured, the BGP speaker MUST NOT append the globally configured ASN to the AS_PATH for outbound BGP UPDATEs toward the eBGP neighbor, and MUST append only the configured 'Local AS' ASN value.
When using 'Local AS', a BGP speaker SHOULD send BGP OPEN messages to configured eBGP peers using the local ASN as the value in 'My Autonomous System', and SHOULD NOT use the globally configured ASN in that field, to prevent the neighbor from generating a 'Bad Peer AS' error.
'Internal BGP AS Migration' allows an iBGP speaker to accept a BGP OPEN with either the legacy ASN or the new permanently retained ASN in 'My Autonomous System'. This permits gradual iBGP session migration without requiring simultaneous reconfiguration of all routers.
'No Prepend Inbound' is an option to the 'Local AS' mechanism that causes the router to not prepend the legacy ASN to the AS_PATH when advertising updates received from CE devices to iBGP neighbors. Without this option, 'Local AS' alone would artificially lengthen the AS_PATH.
'Replace Old AS' is an outbound mechanism that prevents a router from appending the globally configured ASN in outbound BGP UPDATEs toward eBGP neighbors using the 'Local AS' mechanism. Instead, only the old (legacy) AS is prepended, preserving the pre-migration AS_PATH length from the customer's perspective.
The 'Local AS' mechanism allows a BGP router to supersede the globally configured ASN in the 'My Autonomous System' field of the BGP OPEN message with a locally defined AS value for a specific neighbor or group of neighbors. This enables a PE router to establish eBGP sessions toward CE devices still using the legacy ASN after the PE has been moved to a new ASN.
BGP sessions on routers implementing these AS migration mechanisms SHOULD be protected using TCP Authentication Option (RFC 5925) and the Generalized TTL Security Mechanism (RFC 5082) to reduce exposure to session hijacking or spoofing.
The AS migration mechanisms manipulate the AS_PATH attribute to prevent artificial lengthening; however, this manipulation could result in unexpected shifts in traffic patterns and potential congestion if misused. Since these mechanisms are only configurable through router management interfaces, standard security measures should restrict access to those interfaces.