IPv6 Track at NANOG
Greetings from Philadelphia! I am presenting as part of the IPv6 at NANOG46 (click here for info of how to watch) at 9:30PM UK time today, or download the IPv6 for Enterprises presentation here, or see information about the other speakers here..
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.
Published in categories: The 'net, bgp, ecommerce, ipv6, networking, peering, telecoms
IPv4 Run-out policies in Europe
There are a few policy suggestions pushing their way through the RIPE policy development process which discuss how the final remaining IPv4 addresses should be given to end users in the European region.
They all show that the effects of scarsity of IP addresses will be felt before the final few addresses become assigned to end users. All consumers of addresses will feel constrained, which means all businesses trading online, whether they are a traditional ISP, a growing e-commerce shop, or a datacentre/hosting firm. The policies under consideration are :
- 2008-06 - Both new and existing organisations requesting IPV4 addresses shall be given addresses only to support transitioning technologies (i.e. infrastructure services which enable access to IPv6 addressed resources.) They will only be given one block of IPv4 addresses, and this shall be the smallest possible range of addresses as decided by the community at large. This is the only range of addresses which shall be given to the end user, even if their needs justify more.
- 2009-03 - From summer 2010, any organisation shall only be given enough new addresses to cater for anticipated need for nine months. By summer 2011, this will change to three months. Organisations (registries and end users) MUST have used more than half of their address space within six months of assignment or allocation.
- 2009-04 - Organisations must demonstrate that they are implementing an IPv6 transition policy (RFC5211) in order to be given IPv4 addresses. Allocations from the RIPE NCC will be /27 (32 addresses for the entire registry, e.g. ISP)
This also means that the effects of black market trading in address space will be seen before the ‘anticipated’ IPv4 dry date in 2011. There are no magic bullets, you (and your customers, suppliers, and partners) need deep pockets, decades worth of existing resources, or an ipv6 transition plan. The only sensible option is to plan your v6 deployment today.
Published in categories: The 'net, bgp, ipv6, networking, non-tech
18 months? And google are nimble?
Google recently announced that they’d done a front-to-back implementation of IPv6, using engineers’ spare time, in 18 months. Cue well over 100 comments on slashdot claiming that this goes to show how hard implementing any sort of v6 service is at all, given it takes a company known for hiring smart people as long as 18 months.
I decided to put the timetable to the test. On Wednesday at 2:30PM uk time, I applied for a /32. One hour later, we were allocated 2a02:c30::/32. I straight away assigned a /48 for our network infrastruture, and another for our production hosting lan, another for our development hosting lan. From these /48s, several /64s were reserved, one for router loopbacks, another for point to point links, more for individual hosting applications. An hour later, this was implemented on our network - routers had loopbacks, and a v6 IGP was up and running, and working. I filed a ticket with our upstreams, and the first announcement was turned up minutes later - check BGPlay for exact times. Around 2 hours after making our application to RIPE, we were participants on the IPv6 internet.
Now this is not a front-to-back implementation, but in just two hours we had something to hand over to our systems teams for testing and training. If you rely on the internet for your business, this is the stage you need to get to urgently. In fact, by close of play Wednesday, some of our simpler services were already running dual stack, and additionally we are now running Dual-stack for DNS - Nominet having the simplest method for adding ipv6 glue.
Full disclosure: In reality our v6 rollout started months ago, by monitoring advice on operational mailing lists, attending v6 seminars, and in fact we had been engaged in the rollout of ipv6 on several customer networks to date, so this rollout was not frightening for us.
We are now in the position that we can integrate IPv6 addressing as part of every configuration refresh or maintenance on our services, so that v6 is rolled out in a controlled, monitored, and careful manner. By moving now, we have bought ourselves time - a luxury, and firms waiting longer to start their v6 rollout will have a harder time, with the whole migration feeling like a ‘y2k bug’.
Published in categories: The 'net, bgp, ecommerce, ipv6, networking
Escaping a pipe inside xargs
I’ve got a nasty dose of bashfail this morning. I had a bash one-liner which generated a list of strings. I needed to iterate over that list in xargs, but the command in xargs was itself a dirty multi-command one-liner :
crazy | stuff | xargs -i {} this {} | that {} (with this and that expanded by xargs, not the shell)
I solved it by generating the command in xargs using ‘echo’, and then passing that into the shell. Example :
crazy | stuff | xargs -i {} echo ” this {} | that {} ” | sh
Is this the cleanest way of doing it ? This works fine, but loses readability points !
Published in categories: Uncategorized
iPhone battery life
The iPhone is the best portable computer I have ever owned, in every regard but one - the battery life for me was shockingly bad. When it reached the point where I could not go a full day without charge, I decided that I would have to return the device, because it was not useful as a phone if it could not make and receive calls all day without juice.
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.
Published in categories: Uncategorized, iphone, non-tech, telecoms
IPv6 Tooling talk
At 3pm I’ll deliver this lightning talk to the LINX IPv6 Specialist Techical Workshop 2009 on IPv6 Tooling.
It covers :
- Provisioning tools/notes
- SNMP
- NetFlow notes
- Scripting notes
Published in categories: The 'net, ipv6, networking, telecoms
The internet is still broken, guys…
I complained on December 10th 2008 that The Internet was broken for 4-byte ASN speakers. Rob Shakir, Jonathan Oddy, and I have been researching in detail the mechanism by which a faulty announcement by an end-site network in the Ukraine was able to break BGP (the protocol that glues different networks on the internet together, one of the most significant building blocks of the internet) for hosts that supported ASN4 - the evolution of the protocol to support ‘large’ AS numbers (unique network IDs).
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.
Published in categories: The 'net, bgp, networking, peering, telecoms
Preventing Mailman annoyances
Inspired by TheHodge’s “After you install Wordpress” article, I made a note of the things I did to configure a Mailman mailing list, after creating it. Much of this is to make the look-and-feel replicate how I used to run Majordomo lists.
Firstly, I like the Bounce handling and web-interface to Mailman, so this is why I don’t just run Majordomo for lists any more. Its worth pointing this out, in case you wonder why I still use tool B, even though I have to do lots of work to make it work like tool A !
After running newlist, I recommend the following configuration changes (defaults which are changed assume you are running the Debian packaged Mailman) :
- General Options - make the administrators email address a role account that you will not subscribe to the mailing list. This is basically so that if you bounce an administration message from Mailman, due to your spam filters or an error, Mailman wont decide to unsubscribe you from the mailing list! I have had this happen to me before when I used to hand-check spam directed at uknot.
- Decapitalise public name of the list - to make it look neater, and more like the output of the ‘lists’ command in majordomo. Don’t forget to decapitalise the subject line tag if you do this. I also tend to make the subject line tag very small so that on little displays, it’s still possible to scan a folder and read threads of interest on subject alone.
- Disable monthly reminders - they are really annoying to your subscribers, and Debian’s default position is disabled, but some implementations do not disable subscription reminders.
- My users get confused by the Filter out duplicate messages to list members option. When a list subscriber is cc:d to a list post, users tend to expect to see a copy of the mail in their inbox, and their mailing list archive. I turn the filter off so that this happens.
- I tend to enable the Should administrator get notices of subscribes and unsubscribes option, so that I can track whether promoting a list in a certain place has worked!
- In “Non Digest options”, if I am migrating for a Majordomo list, I empty the box for message footer, and also tend to remove it when its a geek mailing list, as to most high volume mail readers, its obvious when an email has been posted to a mailing list, because its filtered into the correct mailbox ! For low volume lists that are intended for low volume mail readers, the footer might be useful.
- Check the reply to option, so that mailing lists that are intended to promote on-list discussion have a header that directs conversation back to the list, and mailing lists that will yield a high proportion of off-list mail do not have this header.
- Be slightly annoyed with me that the only English option in ‘Language Options’ is English (USA) when there is no English (UK).
Happy list-administration!
And you may find the following lists interesting to your work :
- mailop, for those who work in the field of mail systems administration.
- experts, for those who work in expert e-commerce roles.
- uknof, for those who work in network engineering roles, or systems/ISP environments.
Published in categories: Sys Admin, The 'net, ecommerce, non-tech
