How BGP Uses Conversion or Truncation For Compatibility
A BGP session uses an initial handshake to determine the identity of its neighbour. To allow a "new" version of BGP to speak to an "old" version of BGP it presents itself as the 16-bit AS 23456 in the initial handshake and includes a 32-bit capability advertisement.
If the neighbour is also a "new" BGP it will pick up this capability and use the extended length AS number and proceed as normal. If the neighbour is an "old" BGP, the "old" BGP speaker will believe its speaking to AS 23456. In this case the "new" BGP will pick up that it has an "old" neighbour and make some changes to the way BGP operates.
When the "new" BGP speaker sends a BGP UPDATE to the "old" BGP it uses a combination of translation and tunnelling to transform the AS Path from a sequence of 32-bit values to a sequence of 16-bit values. For translation, each AS is truncated to a 16-bit value. If the 32-bit AS value was less than 65536 then the leading zeros are stripped off and the equivalent 16-bit value is used.
Otherwise the 16-bit value 23456 is used in its place. This creates an equivalent 16-bit AS path of the same length as the 32-bit version. For tunnelling, the original 32-bit AS path is placed in an opaque community attribute.
This update will traverse the "old" BGP world as normal. The 16-bit AS path will be augmented with each transit AS and the opaque community attribute will be unaltered.
When passing a routing update from the 16-bit "old" BGP world back into the 32-bit "new" BGP world, then the opposite transformation is applied. All the AS numbers in the AS Path attribute are expanded to the equivalent 32-bit values by adding the leading 16 zero bits to the AS number value.
If there is the appropriate opaque community attribute present, then all instances of AS 23456 can be converted back to their 32-bit values. If nothing untoward has happened the "new" 32-bit BGP world sees an accurately re-constructed 32-bit AS PATH, preserving both AS path length metrics and BGP's routing loop detection capability.
This assumes that nothing "unusual" has happened as the BGP UPDATE message traversed the 16-bit "old" BGP world. The opaque community attribute may have been dropped, or some form of proxy aggregation in the 16-bit world has garbled the AS path so the reverse substitution can't be performed.
Even this, however, is not a fatal condition. Even without the substitution the AS PATH length metric is preserved and routing loop detection can still be performed - if in a slightly degraded fashion.
If BGP encounters something unexpected in the translation back from the "old" to the "new" world, then the only casualty is speed of routing convergence, where it may take a number of additional AS hops for a potential routing loop to be detected and removed.
So, even if you do absolutely nothing in your 16-bit "old" BGP routing domain, Internet-wide routing will still work, and reachability information will still be propagated in useful forms. Nothing will 'break'. But there are some things to check, and maybe alter, in the larger environment of your operational support framework.
Next: Tweaking "Old" World Domains
Edited from an analysis by APNIC Chief Scientist, Geoff Huston.