[afnog] 32 bit ASN

[Mark Tinka]

On Tuesday, January 25, 2011 04:30:11 pm Geert Jan de Groot 
wrote:

> Your peers do not need to upgrade, though upgrading is
> advisable. To non-32-bit capable BGP speakers, you will
> look like AS 23456. That works, and works well, except
> that all 32-bit ASN speakers will look like AS23456 and
> hence the peer cannot set policy based on AS path.

So GJ is right here, your upstream doesn't need to 
"understand" 4-byte ASN's for this to work, but it is 
advisable that they do.

One reason is because in earlier vendor code that 
implemented 4-byte ASN's, a vulnerability was present where 
a malformed BGP update or a super-long 4-byte ASN AS_PATH 
could bring down an upstream router. In fact, I think we 
(AfNOG) ended up inadvertently doing this during our Cairo 
workshop/meeting in 2009 :-). GJ can tell you all about 
that, and then some.

So I'd suggest checking with your provider on whether 
they'll have issues supporting you, as a matter of course.

On the other hand, not supporting native processing of 4-
byte ASN's complicates AS tracking and AS_PATH-based 
filtering/routing policy, as all AS's then look the same.

> Note that there are various different ways to write down
> 32-bits ASN numbers, like AS327685, AS5.5. Consensus is
> to use the first format (see RFC5396), though you may
> see other formats in older documentation or in some
> early implementations.

Yes, most major vendors have now defaulted to "as-plain" 
representations of 4-byte ASN's, as opposed to "as-dot". You 
can still enable "as-dot", but why injure yourself :-)?

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20110126/333148b8/attachment.pgp>