With the world
passing 10% IPv6 penetration over the weekend,
we see the same old debates coming up again; people claiming IPv6 will
never happen (despite several years now of exponential growth!),
and that if they had only designed it differently, it would have been
all over by now.
In particular, people like to point to a
2002 3 article by D. J. Bernstein,
complete with rants about how Google would never set up useless IPv6
addresses (and then they did that in 2007 I was involved). It's difficult
to understand
exactly what the article proposes since it's heavy on
calling people idiots and light on actual implementation details (as opposed
to when DJB's gotten involved in other fields; e.g. thanks to him we now have
elliptical curve crypto that doesn't suck, even if the
reference implementation was sort of a pain to build), but I will try to
go through it nevertheless and show how I cannot find any way it would work
well in practice.
One thing first, though: Sorry, guys, the ship has sailed. Whatever genius
solution DJB may have thought up that I'm missing, and whatever IPv6's
shortcomings (they're certainly there), IPv6 is what we have. By now, you can not
expect anything else to arise and take over the momentum; we will either live
with IPv6 or die with IPv4.
So, let's see what DJB says. As far as I can see, his primary call is for
a version of IPv6 where the address space is an extension of the IPv4
space. For sake of discussion, let's call that IPv4+ , although it would
share a number of properties with IPv6. In particular, his proposal requires
changing the OS and other software on every single end host out there,
just as IPv6; he readily admits that and outlines how it's done in rough
terms (change all structs, change all configuration files, change all
databases, change all OS APIs, etc.). From what I can see, he also readily
admits that IPv4 and IPv4+ hosts cannot talk to each other, or more clearly,
we cannot start using the extended address space before almost everybody
has IPv4+ capable software. (E.g., quote: Once these software upgrades have been
done on practically every Internet computer, we'll have reached the magic
moment: people can start relying on public IPv6 addresses as replacements for
public IPv4 addresses. )
So, exactly how does the IPv4 address space fit into the IPv4+ address space?
The article doesn't really say anything about this, but I can imagine only
two strategies: Build the IPv4+ space
around the IPv4 space (ie., the IPv4
space occupies a little corner of the IPv4+ space, similar to how v4-mapped
addresses are used within software but not on the wire today, to let
applications do unified treatment of IPv4 addresses as a sort of special IPv6
address), or build it as a
hierarchical extension.
Let's look at the former first; one IPv4 address gives you one IPv4+ addresses.
Somehow this seems to give you all the disadvantages of IPv4
and all the
disadvantages of IPv6. The ISP is not supposed to give you any more IPv4+
addresses (or at least DJB doesn't want to contact his ISP about more also
saying that the fact that automatic address distribution does not change his
argument), so if you have one, you're stuck with one. So you still need NAT.
(DJB talks about proxies , but I guess that the way things evolved, this
either actually means NAT, or it talks about the practice of
application-level proxies such as Squid or SOCKS proxies to reach the
Internet, which really isn't commonplace anymore, so I'll assume for the sake
of discussion it means NAT.)
However, we already
do NAT. The IPv4 crunch happened
despite ubiquitous
NAT everywhere; we're actually pretty empty. So we will need to hand out
IPv4+ addresses at the very least to new deployments, and also probably
reconfigure every site that wants to expand and is out of IPv4 addresses.
( Site here could mean any organizational unit, such as if your neighborhood
gets too many new subscribers for your ISP's local addressing scheme to have
enough addresses for you.)
A much more difficult problem is that we now need to route these addresses on
the wire. Ironically, the least clear part of DJB's plan is step 1, saying
we will extend the format of IP packets to allow 16-byte addresses ; how
exactly will this happen? For this scheme, I can only assume some sort of
IPv4 option that says the stuff in the dstaddr field is just the start and
doesn't make sense as an IPv4 address on its own; here are the remaining 12 bytes
to complete the IPv4+ address . But now your routers need to understand that
format, so you cannot do with only upgrading the end hosts; you also need to
upgrade every single router out there, not just the end hosts. (Note that
many of these do routing in hardware, so you can't just upgrade the software
and call it a day.) And until that's done, you're exactly in the same
situation as with IPv4/IPv6 today; it's incompatible.
I do believe this option is what DJB talks about. However, I fail to see
exactly how it is much better than the IPv6 we got ourselves into; you still
need to upgrade all software on the planet and all routers on the planet.
The benefit is supposedly that a company or user that doesn't care can just
keep doing nothing, but they
do need to care, since they need to upgrade
100% of their stuff to understand IPv4+ before we can start even deploying it
alongside IPv4 (in contrast with IPv6, where we now have lots of experience
in running production networks). The
single benefit is that they won't have
to renumber until they need to grow, at which point they need to anyway.
However, let me also discuss the other possible interpretation, namely that
of the IPv4+ address space being an extension of IPv4, ie. if you have
1.2.3.4 in IPv4, you have 1.2.3.4.x.x.x.x or similar in IPv4+. (DJB's article
mentions 128-bit addresses and not 64-bit, though; we'll get to that in a
moment.) People keep bringing this up, too; it's occasionally been called
BangIP (probably jokingly, as in
this April Fool's joke) due to
the similarity with how explicit mail routing would work before SMTP became
commonplace. I'll use that name, even though others have been proposed.
The main advantage of BangIP is that you can keep your Internet core routing
infrastructure. One way or the other, they will keep seeing IPv4 addresses
and IPv4 packets; you need no new peering arrangements etc.. The exact
details are unclear, though; I've seen people suggest GRE tunneling, ignoring
problems they have through NAT, and I've seen suggestions of IPv4 options
for source/destination addresses, also ignoring that someting as innocious
as setting the ECN bits has been known to break middleboxes left and right.
But let's assume you can pull that off, because your middlebox will almost
certainly need to be the point that decapsulates BangIP anyway and converts
it to IPv4 on the inside, presumably with a 10.0.0.0/8 address space so that
your internal routing can keep using IPv4 without an IPv4+ forklift upgrade.
(Note that you now lose the supposed security benefit of NAT, by the way,
although you could probably encrypt the address.) Of course, your
hosts
will need to support IPv4+ still, and you will need some way of communicating
that you are on the inside of the BangIP boundary. And you will need to know
what the inside is, so that when you communicate on this side, you'll send
IPv4 and not IPv4+. (For a home network with no routing, you could probably
even just do IPv4+ on the inside, although I can imagine complications.)
But like I wrote above, experience has shown us that 32 extra bits isn't
enough. One layer of NAT isn't doing it, we need two. You could imagine
the inter-block routability of BangIP helping a fair bit here (e.g.,
a company with too many machines for 10.0.0.0/8 could probably easily
get more addresses for more external IPv4 addresses, yielding 10.0.0.0/8
blocks), but ultimately, it is a problem that you chop the Internet off
in two distinct halves that work very differently. My ISP will probably
want to use BangIP for itself, meaning I'm on the outside of the core; how
many of those extra bits will they allocate for me? Any at all?
Having multiple levels of bang sounds like pain; effectively we're creating
a variable-length address. Does anyone ever want that? From experience, when
we're creating protocols with variable-length addresses, people just tend to
use the maximum level anyway, so why not design it with 128-bit to begin
with? (The original IP protocol proposals actually had variable-length
addresses, by the way.) So we can create our 32/96 BangIP , where the first
32 bits are for the existing public Internet, and then every IPv4 address
gives you a 2^96 addresses to play with. (In a sense, it reminds me of 6to4,
which never worked very well and is now thankfully dead.)
However, this makes the inside/outside-core problem even worse. I now need
two very different wire protocols coexisting on the Internet; IPv4+ (which
looks like regular IPv4 to the core) for the core, and a sort of
IPv4+-for-the-outside (similar to IPv6) outside it.
If I build a company network, I need to
make sure all of my routers are IPv4+-for-the-outside and talk that, while if I build the
Internet core, I need to make sure all of my connections are IPv4 since
I have no guarantee that I will be routable on the Internet otherwise.
Furthermore, I have a fixed prefix that I cannot really get out of, defined
by my IPv4 address(es). This is called hierarchical routing , and the IPv6
world gave it up relatively early despite it sounding like a great idea at
first, because it makes multihoming a complete pain: If I have an address
1.2.3.4 from ISP A and 5.6.7.8 from ISP B, which one do I use as the first
32 bits of my IPv4+ network if I want it routable on the public Internet?
You could argue that the solution for me is to get an IPv4 PI netblock
(supposedly a /24, since we're not changing the Internet core), but we're
already out of those, which is why we started this thing to begin with.
Furthermore, if the IPv4/IPv4+ boundary is above my immediate connection
to the Internet (say, ISP A doesn't have an IPv4 address, just IPv4+),
I'm pretty hosed; I cannot announce an IPv4 netblock in BGP. The fact that
the Internet runs on largely the same protocol everywhere is a very nice
thing; in contrast, what is described here really
would be a mess!
So, well. I honestly don't think it's as easy to just do extension instead of
alternative when it comes to the address spaces. We'll just need to deal
with the pain and realize that upgrading the equipment and software is the
larger part of the job anyway, and we'll need to do that no matter what
solution we go with.
Congrats on reaching 10%! Now get to work with the remaining 90%.
Debian LTS
December was the eighth month I contributed to Debian LTS under the
Freexian umbrella. It was a bit of a funny month since most of the
time most open CVEs were already taken care of by other team members
(which is nice) but it resulted in me not releasing a single DLA which
feels weird.
Nevertheless in total I spent nine hours working on:
During the last weeks I finally got my hands dirty with IPv6. A comment on my blog and an email informed me that my server (hosting this blog) is not reachable via IPv6, albeit it has an IPv6 address. That said, I tried to get that running and fell into several holes, due to firewalls, my home provider not doing IPv6, and not the least due to my own ignorance of IPv6.
Fortunately, with the help of some good souls and the technical support I finally got IPv6 connectivity on both my server, as well as at home, up.
Server
So my server is still running wheezy, which is a bit old, but upgrading with lots of hand-installed stuff is a bit a pain. The network interface was configured via a static IPv4 address, and no traces of IPv6 for now. Simple minded as I am, I assumed that this is the problem and started playing around with all kind of IPv6 configurations in the interfaces file, from using dhcp, and static configuration. The static configuration somehow worked out, but I never got a proper default route set. So I was really puzzled.
In addition, at home I don t have IPv6, my provider is not distributing IPv6, so I couldn t test it (but on this a bit later). Fortunately, the good soul from the Netherland Filip B., did a lot of testing and also send permanent suggestions and analysis of the IPv6 situation, I am very much indebted to him.
Anyway, his last advice about the problem with the default route was contacting the technical support of my provider, who within a very short time sent me an answer which made it clear to me: My firewall was blocking some ports that are necessary for IPv6 route autonegotiation.
As firewall I use 
Modern versions of Linux and MythTV enable infrared remote controls without
the need for 
Which gadgets does Bond bring to Switzerland?
Time for freedom
How would you live for a day or a weekend or an entire holiday without your mobile phone? There are many small frustrations you may experience but the biggest one and the indirect cause of many other problems you will experience may be the inability to tell the time.
Many people today have 
In January 2014 the open-vm-tools package was orphaned and I took the chance to take over the maintenance.
Unfortunately the package is still not 100% in the shape I d like to see it, but I m getting closer.
I have to say Thank You for a lot of good bug reports, especially for those use cases which are
hard to test/reproduce for me (running Debian in a Windows-based VMware Workstation Player for example .).
At 
At 
A while back I wrote about some issues with converting
a two-disk RAID system to a one-disk system, but just to recap:
I woke up this morning and realized that for the first time since
Here is my monthly update covering a large part of what I have been doing in the free software world (
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
Amb el cor compungit, Debian lamenta la p rdua d'Ian Murdock, ferm
partidari del programari lliure i de codi obert, pare, fill i l'"ian"
a Debian.
L'Ian va comen ar el projecte Debian l'agost de 1993, i va publicar les
primeres versions m s tard el mateix any. Debian es convertiria en el
sistema operatiu universal pel m n, que funciona en tot tipus de
dispositius, des de sistemes encastats fins a l'estaci especial.
L'Ian es va centrar en crear una distribuci i una cultura de comunitat
que fessin el correcte, ticament o t cnica. Publicar quan estigui a
punt i la ferma posici sobre la llibertat de programari s n les regles
d'or en el m n del programari lliure i de codi obert.
La seva devoci per fer el correcte va guiar la seva feina, tant a
Debian com els seg ents anys, sempre treball per assolir el millor
futur possible.
El somni de l'Ian est viu, la comunitat de Debian continua
incre blement activa, amb milers de desenvolupadors que treballen
innumerables hores per proporcionar un sistema operatiu segur i fiable.
Els pensaments de la comunitat de Debian s n amb la fam lia de l'Ian en
aquests moments tant durs.
La seva fam lia ens ha demanat privacitat en aquests moments dif cils i
volem respectar-ho. Des de Debian i des de la comunitat de Linux en
general podem enviar mostres de condol a in-memoriam-ian@debian.org;
seran guardades i arxivades.