my web 0.2 website

Internet broken for ASN32 speakers today.

Not trying to point fingers or name-and-shame, just to raise the profile of a nasty little bug handling breaches of RFC4893.  This post is basically shaped from a message I posted to nanog earlier.

AS196629 (3.21 in asdot) announce 91.207.218.0/23.  Experienced eyes will notice that this is quite a large as number.  It’s a ‘new’ 4-byte ASN.  When an OpenBGPd speaker with 4-Byte ASN support receives the update for this message, the session is torn down with the daemon logging a ‘fatal error’. Why?
OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893.  When processing the UPDATE for 91.207.218.0/23 it sees :

91.207.218.0/23
Path Attributes – Origin: Incomplete
Flags: 0×40 (Well-known, Transitive, Complete)
Origin: Incomplete (2)
AS_PATH: xx xx 35320 23456 (13 bytes)
AS4_PATH: (65044 65057) 196629 (7 bytes)

See the confederation ASNs in the AS4_PATH ?  Thats forbidden :

To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. RFC 4893.

The RFC does not suggest how to handle AS4_PATH violations, but if the bad path is learned on every upstream, this will cause a network with obgpd edges to disconnect from the internet…. Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down.  This isn’t a great fix.
The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination.

From a software point of view, I want to see a configurable option to reject the route but keep the session, reject the route and drop the session, accept the route but log/send trap, etc.

In any case we need to publish the arrangement that has led to this mistake so that other networks using the same toolset to originate prefixes can avoid the same situation happening.  I have made contact with an engineer at the NOC who are investigating.

2011 – An addressing odyssey. Preparing enterprise for IPv6.

Yesterday I gave a talk to Sheffield GeekUp on preparing enterprises for IPv6 [download].  The premise of the talk was :

• IPv4 addresses are scarse, and at current consumption rates, the IANA pool of free v4 addresses will be gone at the start of 2011.
• This starts a “Post IPv4 world” where the IPv4 internet continues to function as before (certainly initially), but obtaining new addresses becomes harder and expensive.  This inhibits expansion of existing firms, and new entrants to the market.
• Address trading is likely to lead to a larger routing table, meaning that failure-recovery times increase, and the risk of blackholes on the internet increases.
• Large broadband providers may not have enough v4 addresses to give one address per customer.  This means protocol translation techniques need to be used, which break the end to end model.  We rely on the end to end model when innovating new services on the internet.
• If services and consumers gradually roll v4 and v6 (dual stack), the negative impact of markets for addresses, routing problems, and translation can be mitigated.
• Service providers are enabling v6 in the core.  Enterprises need to move next in order to get the world v6 ready.

The advice I gave was :

• Today’s market leaders are already learning v6 lessons in their labs, (e.g. ipv6.google.com).  They are doing this to help them retain market leadership.  If you want to retain your market position, start labbing your applications and service provision with v6.
• Write a policy stating all new purchases of infrastructure and services need to be from providers with v6 support, or a well defined v6 road map.  In other words, make v6 a “life cycle upgrade”.
• Share information, and learn information from your industry peers.
• I also listed some advice to developers with regard to v4 and v6 differences.
• I then delivered a very quick primer to those who have not seen v6 deployed before.

My hope is that this talk is improved upon and delivered internationally to enterprises.