Since January 1st, a few key milestones have passed, indicating how urgent the IPv4 rundown problem has become. Firms that rely on internet connectivity must take urgent action in light of the events:

• The allocation last week of two further /8s (blocks of IPv4 addresses with the same number before the first dot) to APNIC mean that for the first time, less than just ten percent of the IPv4 unallocated pool is available to be assigned.  At current utilisation rates, this pool will be exhausted in only 600 days.  Of course, the internet could stop growing, but all signs point away from this…
• The allocation of 1.0.0.0/8 is the assignment of the first really ‘dirty’ block of addresses, signalling that we really are in the run-down period.  Bad network design decisions in the past have meant that networks have ‘borrowed’ the use of addresses starting 1. for ‘internal use only’ or special applications on their network.  This means that organisations assigned address space starting ‘1′ may well have partial connectivity even though they are rightfully assigned the space.  Examples are the braindead hotspot operators who take addresses like 1.1.1.1 to trigger hotspot logout, but a handful of examples appear across this address range.
• RIPE NCC, the organisation who assign addresses to networks in and around Europe have this month implemented their ‘run down’ policy which will mean that organisations requesting space will only be able to cater for their growth requirements for a very short amount of time.  This is to evenly spread the inevitable misery across the ISP community.

RIPE members should thoroughly audit their address space so that they can ensure that their records are accurate, because RIPE are more likely to ensure that address space is assigned to your end users in line with the community’s policies.  ISPs and services providers who need help can contact me for further information or specific assistance.

Organisations who rely on internet connectivity for their products should ensure their providers have an IPv6 migration plan in place.  Otherwise end-to-end connectivity for your home or office is unlikely to be something you can enjoy looking beyond the runout period.  Companies hosting network services, for example a website, should enquire what their host’s IPv6 plans are, and start to enable their services via v6.

There is real traction to ensure v6 support appears in both the hardware and services you need to connect to the internet.  It is easier today than before to find help making your services available via v6.  The alternatives – patchy connectivity via nested stacks of ipv4 islands, or no more end-to-end connectivity (so that your internet service is a walled garden), have much worse consequencies than learning to roll v6.

Engineers know the facts by now and have no excuse.  For more information, see the RIPE NCC’s information site, ipv6actnow.

The slides show that the new route-servers perform splendidly well compared with traditional Quagga based MLPs, also that route-servers are now free of ‘first generation code’ bugs, and also that they handle your prefixes transparently – as you would expect.

Interestingly, BIRD and OpenBGPd behave identically ‘on the wire’ so IXPs are encouraged to use multi-vendor MLP on their platform for increased reliability and stability.  The new breed of route-server code is dependable and tested, so networks that would like to connect should draw confidence from this testing, and IXPs wishing to roll out MLP services should feel confident in the software tested.

Happy peering!

The messages are clear and simple.  Working now to get ready for the IPv6 transition will be less expensive and lower risk than waiting for IPv4 starvation to hurt.  I interviewed some key enterprises about their specific grumbles but the great news is that most are transitional and already people are working on fixing them.

Before boxing it up, I did some research though – the iPhone Battery life information on the Apple site explained that my experiences should have been different, I should have seen “5 hours of talk time on 3G, 5 hours of Internet use on 3G, 6 hours of Internet use on Wi-Fi, 7 hours of video playback, or 24 hours of audio playback and up to 300 hours of standby time” (from Apple site).  The mistake I had made was to assume I could charge it from the USB port on my computer, since the cable supplied with the phone is a usb to iPhone cable.  A few weeks of exclusive charge on this cable means that you are guaranteed to have poor battery performance, whereas charging from the mains on the supplied adapter leads to better performance.  I wish someone had pointed that out to me explicitly.

Empirically, I also found that reducing screen brightness was the most effective way of preserving battery life when the phone is in use, and turning off bluetooth and 3g is the best way to preserve life when you are using it infrequently.

It covers :

• Provisioning tools/notes
• SNMP
• NetFlow notes
• Scripting notes

Some history in very brief terms – all networks on the internet that participate in BGP need a number to identify themselves.  On the public internet, this number normally needs to be globally unique.  The number can be between 1 and 65,535, and we have close to 50,000 of these numbers in use.  To grow past this number, the BGP standard needs to be modified.  The modification is described in a document called rfc4893, and this document was accepted by the community last May.

The first incarnations of router software that support these large AS numbers is now circulating. Due to flaws in the standards that exist in January 2009, if you install one, you may become disconnected from the internet.

Why? Some more background, first: BGP allows for large networks to configure ‘hints’ in their router configuration, by dividing their network into several small networks (confederations).  The information about the ‘virtual’ divisions of the network should be removed from the BGP messages which are sent to other networks, but if a network supports large ASN in some parts, and not in others, the routers in the legacy part of the network may not know to test the ‘large number’ section of a BGP message for the presence of an internal confederation ID.  The standard tries to take this into account by explicitly forbidding that confederation ID be passed between networks in the asn4 part of the BGP message.

However, should this occur by accident, what are the effects?  Well, elsewhere in the Large ASN standard, it states that the connection between two networks should be severed if Confederation ASN appear to be leaked in the ASN4 part of the BGP message.  This means that networks which do not understand large ASN can forward a broken message to a network which does understand large ASN.  At which point the network which does understand large ASN should tear down the session.

Since this message can be delivered over a transit session, this means the receiving ISP loses their connection to the internet via that ISP.  If it learns the router over every ISP, then the network can lose its connection to the internet entirely.

The message that I reported was leaking in December is still leaking.  AS196629 (AS3.21 in legacy asdot notation) is announcing to AS35320, who are not stripping their confederation information from the large-asn section of BGP messages.  If you learn the prefix via AS196629’s other transit, AS6886, then you are fine.  If you learn the prefix via AS35320, you are (today) receiving a broken message.

We tested out how Cisco IOS is coping with this broken message using the first generation of code for the cisco 7200 router that understands ASN4.  We peered the router to NetSumo’s research and development network, AS15653.  Cisco honours the standard/rfc, and breaks the session.  Since it learns the dirty message on the transit session, the router disconnected our test network from the internet entirely :

• *Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up
• *Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062) 3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH
• *Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP Notification sent
• *Jan 16 11:30:02.595: %BGP-3-NOTIFICATION: sent to neighbor 193.239.32.2 3/1 (update malformed) 27 bytes E0111803 030000FE 140000FE 180000FE 26 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0050 0200 0000 3540 0101 0240 020C 0205 3D25 2114 89F8 5BA0 5BA0 4003 04C1 EF20 02E0 1118 0303 0000 FE14 0000 FE18 0000 FE26 0202 0003 0015 0000 5BA0 175B CFDA

If you work in this field, I implore you to read the more thorough analysis on the nanog list, and participate in the discussion to work out how we should correct the standard, to allow routers to behave differently when a dirty message is received.  If we do not, then there is a simple, easy to understand, and easy to implement mechanism to break the internet, as soon as networks upgrade to the current version of their routing software.

There is a feature that requires agents to press # when they are ready to speak to a caller.  Since we forward calls to agents via their mobiles, rather than auto-answer calls in a desk environment, we disabled that feature with ackcall=no in agent.conf.

After upgrading to 1.4.22 we see this configuration is nolonger honoured.  Diffing chan_agent.c between version 1.4.21 and 22 shows a new section of code saying (in English) that ‘if there is no per-channel override specified in the dialplan, default the configured variable’ (line 2048).  I looked at where the default was read from the config file and it looks like a lot of different chunks of chan_agent want to set the ackcall default!

The bug shows up in the asterisk console as :

– Agent/xxx is ringing
– SIP/voip-out-081e5a88 is making progress passing it to Local/447xxxxxxxxx@uk_all-a667,2
– SIP/voip-out-081e5a88 answered Local/447xxxxxxxxx@uk_all-a667,2
– Local/447xxxxxxxxx@uk_all-a667,1 answered, waiting for ‘#’ to acknowledge

The workaround is that the only safe place to set the default ackcall behaviour is for each channel in the dialplan.  If you want to disable the ‘waiting for ‘#’ to acknowledge’ behaviour, configure your dialplan as such :

exten => 1701,1,Answer()
exten => 1701,n,Set(AGENTACKCALL=no)
exten => 1701,n,Queue(noc|r|||40)
exten => 1701,n,Voicemail(xxxxx)
exten => 1701,n,Hangup

Lee’s premise is that “Certainly Skype is not a walled garden. All things being relative, it’s certainly not overly closed either.”  Lee claims that the accusations of closeness are unfair, because they are levied by commentators who advocate SIP based addressing and dialing rather than any other system.

This is not my premise.  I claim that Skype is closed because calls are signalled and completed using protocols that are entirely secret as a matter of policy.  Skype’s founder presented at Spring VON 2007 and stated that if Skype did not keep their protocols entirely secret, then Skype would be full of spam and attack like email is.  I think this is a poisonous claim, telephone networks have been interconnecting around the world since telephony was conceived.  By not allowing telecoms firms to interconnect between the skype namespace and other networks, Skype have prevented openness to develop and maintain a monopoly position. That’s perfectly acceptable business, but it is not in the slightest bit open.

Randy Bush googled Walled Garden for a recent presentation and found this cartoon.  I like this definition because it’s correct.  Is Skype a Walled Garden ?  Lee says a Walled Garden is a commercial restriction, for example, “sharing of ringtones via Bluetooth, using WiFi from a PDA, having access to all Web sites“.  I think that only allowing interconnection with the purchase of an upgrade like SkypeOut is a restrictive or practice that suggests Skype is a Walled Garden.  Worst of all a call between two VoIP networks using this method requires default PSTN routing, which harms signal quality, and prevents the expansion of next-generation services such as Wideband/High Definition audio.

The meshing of networks, whether they are traditional voice or IP networks, leads to higher audio quality and increased reliability.  Keeping telephony systems and protocols secret in order to prevent meshing may well be a viable business model, but it is not an open business model.

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.

• 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.