When firms avoid fibre, it hurts us all.  When fibre is cheap, firms can use it to roll out super-fast broadband to their users, using the sort of technology that facilitates connections tens or hundreds of times faster than a typical UK home enjoys.  It also allows service providers to increase the capacity of their network edge, and to improve the robustness of their network – for instance by building more links between their network points.  Improved robustness also means better business continuity planning options, improving the availability of their services.  This tax kills faster access, and better services.

The fibre tax also worsens the conditions for international networks looking to build into the UK, for instance in order to bring their content and services to the UK market .  This is not a hypothetical risk, it is a game-changer that has destroyed the business cases of several projects that we have been contributed to last year.

This morning, George Osborne was on BBC TV explaining that he saw an advancement in next-gen broadband (based on fibre optic cabling) as a priority. If this is the case, then he must commit to repealing the 21st Century Window Tax. To date, they have only considered repealing the 50p per month tax on telephone lines that has been suggested by the hugely flawed Digital Britain study.

We are just not competitive with this tax.

On Nanog, Owen DeLong and Larry Sheldon were discussing the relative size of the IPv6 address space:

>> 64 bits is enough networks that if each network was an almond M&M,
>> you would be able to fill all of the great lakes with M&Ms before you
>> ran out of /64s.
> Did somebody once say something like that about Class C addresses?

Well, this seemed like a challenge for Maths, and the answer is:

No. There are only 2,097,152 Class C networks.

Assuming all M&Ms are spheroids of uniform oblate nature, radius major axis=6mm, minor axis=3mm. Volume is (4/3)Pi (Major²) Minor

They will be poured into a great lake of your choice, and we will assume random close packing (agitation mechanisms are probably best discussed off-list) and a (generous, but this Wikipedia article insists) void fraction of 32%.

Volume of m&m = 0.452cm³, occupies 0.665cm³.

Lake Erie is 484km³ – See: http://www.epa.gov/glnpo/factsheet.html

1 km³ = 1,000,000,000,000,000 cm³

484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 m&ms needed to
fill this lake.

There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount
of ipv6 address space is exponentially larger still – I have just looked at 2000::/3 in these maths.

THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.

Can we please now just go ahead and roll out some ipv6 services?

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!

Would domain name users who are concerned about the accuracy of data served pay extra for the ability to sign their DNS zone ?  A handful of people in the room raised their hand in agreement, but the overwhelming majority of operators did not.

His argument was that this compared well with SSL certification authorities who sell certificates that suggest that visitors to a website are interacting with a validated entity, and the technology guarantees privacy between the visitor and the website.  It’s this technology which makes buying and selling online safe.

However, I think that DNSSEC has different aims altogether – simply to guarantee that DNS data is not changed en-route between the authoratative server, through the caches, all the way to users.  Therefore there are significant attack mitigation reasons to deploy DNSSEC, so I hope that operators will begin trials (we are doing so), and that the pace of trials will quicken as the root zone will be signed this year.

If DNSSEC is deployed as designed, then temporary and brief mistakes will not be imported into DNS caches, users will not fall foul to tampered data in caches, and we all receive an authenticated/secure channel for distributing DNS data inside an organisation.

The argument that Dr. Schweiger used is that DNSSEC adds an operational and technical burden to registries (extra communication with registrars, more complex software, additional CPU and bandwidth requirements).

I hope that my colleagues in other organisations agree that there are significant infrastructure advantages to freely allowing DNSSEC to grow, and that Moore’s Law, automation, and the fact that DNS registries normally find it simple to peer widely with ISP networks will offset the needs to consider the commercial signing model.

• Stop the inflow of new data
• mysqldump the database to a .sql file
• Bin the junk innodb data files
• Edit my.cnf to create files of a spec that I wanted, start mysql
• Import the data.

I decided to create 500 data files of 100MB.  When MySQL started, it ignored the config I had set in my.cnf and loaded the innodb defaults – 5MB log files and an ibdata file of 10MB which could autoextend.

It turns out that if the innodb_data_file_path line is too long then the innodb section is ignored and the defaults will prevail.  I changed the plan to create 200 files of 250MB, which made for much smaller config, and the innodb settings loaded just fine.

If you want a perl one liner to generate the innodb_data_file_path, I used:

perl -e ‘$i=1; do { $padded = sprintf(“%03d”, $i); print “ibdata$padded:250M;”; $i++; } until ($i eq 200)’;

trials:/usr/src/openssh-5.1p1# ssh hextreeme -l netadmin

Keyboard-interactive authentication

Enter password for netadmin:

channel 0: open failed: resource shortage: Channel open failed

The bug is described in Debian bug 495917, and it also prevents connection to some NetScreen firewalls.  I have this bug with Debian 4 (openssh-client 4.3p2-9etch3) and Debian 5 (openssh-client 1:5.1p1-5).

If anyone else is experiencing the same bug and needs a quick fix, then you can download my Debian packages which replace openssh-client.  You of course need to hold the packages if you don’t want them overwriting by a security fix.

• Debian 4 openssh-client_4.3p2-9etch3_i386.deb
• Debian 5 openssh-client_5.1p1-5_i386.deb

By using this software you agree to hassle both the debian-ssh team and extreme to sort their stuff out!

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.

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.

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