LWN: Comments on "The last IPv4 address blocks allocated"

IPv6 destroys privacy, by default

nix — Fri, 18 Feb 2011 12:46:30 +0000

Oh, yes, your servers listen on a static IP, that is in the DNS. But those same machines make outbound connections using randomly-generated or MAC-specific IPs which are quite different from the server address.

IPv6 destroys privacy, by default

nix — Fri, 18 Feb 2011 12:44:06 +0000

Randomized address support has been in Linux for several kernel releases, at least. :)

The last IPv4 address blocks allocated

nix — Fri, 18 Feb 2011 12:40:05 +0000

Not only do you have 'an IPv6 address', but if the private browsing extensions are turned on, you have one or more addresses in DNS for your servers, a primary address, sometimes a tentative address, and often one or more deprecated addresses, all changing smoothly and silently behind your back as time passes.

DHCP has nothing on this.

The last IPv4 address blocks allocated

foom — Fri, 11 Feb 2011 22:41:25 +0000

> 2. Single stack - less confusing to deploy, less to go wrong, more continuity.

But disadvantages: not yet deployed anywhere, or even designed and developed.

> 3. Familiar configuration - just use dot notation with one more dot, familiar interpretation of high order 32 bits remains the same. E.g, multicast continues to work the same as it always did, no new daemons to install

Yet still different and incompatible with IPv4, and different from IPv6 (which is already supported in most software). Multicast in IPv6 doesn't require a daemon. (unless you mean a routing daemon? In which case you'd need to make a modified one for your IPv4+.)

> 4. More efficient - addresses less than half the size means less cache pressure, more efficient packet filtering

I cannot believe that the efficiency of handling 64bit vs 128bit addr sizes really matters today.

> 5. Unobtrusive - IPv4+ could be quietly installed with zero visible configuration changes

Untrue. You need to add support for the extended IP address format. And you'd need to add filter rules for the extended addresses.

> 6. Potentially no tunnel required - stateless

IPv6-6to4 is also stateless and requires no tunnel. Just an extra packet header on the front. (That has somewhat more overhead per packet than an IP option, yes.)

I think you'd be better off designing your fallback plan based on continuing to use IPv4 routing with IPv6-6to4 on the edges. The advantages you've come up with so far for your new scheme just don't seem to me to make up for the head start IPv6-6to4 already has in software development and deployment. You can achieve your goals with existing deployed software. It mainly just needs some marketing.

(But then, I think native IPv6 *will* start to have real deployment in the next couple of years, so we won't actually need to use the fallback plan of using IPv4 everywhere except the edges. It's late, but there is now actual movement.)

The last IPv4 address blocks allocated

daniel — Fri, 11 Feb 2011 21:49:31 +0000

<quote>if an IP option were popular, and generally was in a fixed place in the packet (e.g. the first option) the router vendors would soon enough manage to keep such packets in the fast-path.</quote>

Exactly my thought. Another thing: I seriously doubt that "slow path" is all that slow these days, but we shall see.

IPv6 destroys privacy, by default

paulj — Fri, 11 Feb 2011 10:30:14 +0000

You can't have privacy and persistence of identity, across interactions with 3rd parties you want to remain private to. These are fundamentally contradictory properties.

The last IPv4 address blocks allocated

daniel — Thu, 10 Feb 2011 19:00:13 +0000

<quote>But what would be the advantage over using 6to4?</quote>

1. Backward compatibility - an IPv4 packet is also an IPv4+ packet
2. Single stack - less confusing to deploy, less to go wrong, more continuity.
3. Familiar configuration - just use dot notation with one more dot, familiar interpretation of high order 32 bits remains the same. E.g, multicast continues to work the same as it always did, no new daemons to install
4. More efficient - addresses less than half the size means less cache pressure, more efficient packet filtering
5. Unobtrusive - IPv4+ could be quietly installed with zero visible configuration changes
6. Potentially no tunnel required - stateless

I am not completely sure about the last one, which would be a biggy. The others are pretty obvious. It's hard to understate the importance of backward compatibility, continuity, familiarity and unobtrusiveness. In some theoretical sense these may be uninteresting but in the real world they can be the difference between success and failure.

IPv6 destroys privacy, by default

dlang — Thu, 10 Feb 2011 17:52:50 +0000

if you have a static address in one place that's one thing.

but if your address can identify you uniquely no matter if you are at home, at work, at starbucks, etc that's significantly worse.

in the IPv4 world it's the equivalent of saying that any IP address ending in .4 is your machine, no matter what network it's on

I realize the IPv6 spec doesn't require you to do it this way, but it does suggest basing it on your MAC address, and at least two major implementations do it this way.

it was a bad enough problem that they wrote a RFC for 'privacy extensions' to IPv6, and that's where they suggest changing the IP address periodically.

IPv6 destroys privacy, by default

RobSeace — Thu, 10 Feb 2011 11:33:04 +0000

How is this any worse than someone who has a static IP? Or, even dynamic IPs can be quite long-lived sometimes... I guess I just don't see how it's such a big privacy threat...

But, there's no requirement to use MAC addresses to build the host portion of the IPv6 address; that's just a handy method you can use if you like... Plus, on many OS's (including Linux), you can change your MAC easily, so you can pretend to be any type of hardware you want to spoof, if that's what you're worried about...

The whole notion of randomly changing IPs seems backwards to me... Sure, you can do it (you've got 64 bits to play with!), but with IPv6, I at least want a static IP, so I can run servers and people can get to them...

IPv6 destroys privacy, by default

neilbrown — Thu, 10 Feb 2011 11:28:42 +0000

> binding a cookie to the local address would cause all sorts of grief

Yep... you want one policy for site you trust (lwn.net) and one for sites you don't. Definitely a browser issue.

> unfortunately it appears that at least two of the Major OSs available (Linux and OS/X are mentioned explicitly in the ;login article) both do about the worst possible thing.

Well, "worst" in terms of privacy, but maybe best in terms of simplicity. Different people have different needs. If you want the privacy option on Linux, try "echo 2 > /proc/sys/net/ipv6/conf/all/use_tempaddr" - you might then need to reconfigure the interface. That gives you the "generate a random address and prefer it for outgoing connections" functionality. A new one is regenerated every 24 hours and old ones are discarded after 7 days (according to the doco)

So it is a simple configuration step away from being a substantial improvement in terms of privacy.

IPv6 destroys privacy, by default

dlang — Thu, 10 Feb 2011 09:25:56 +0000

binding a cookie to the local address would cause all sorts of grief

among them the fact that every time the address changed you would have to login again, but it would also mean that tracking that the user _wants_ to happen would break (for example, I _like_ the fact that I don't have to login to LWN every time my IP address changes, especially if I am using a cell card in a poor location)

it's unfortunate that this issue is still the topic of academic research (resulting in the article that I read)

I fully understand that the IPv6 design allows for OSs to do something different and better, but unfortunately it appears that at least two of the Major OSs available (Linux and OS/X are mentioned explicitly in the ;login article) both do about the worst possible thing.

The last IPv4 address blocks allocated

paulj — Thu, 10 Feb 2011 07:10:52 +0000

Ah, missed that. :) Yes, that's pretty explicit.

Definitely been instructive. It does seem as a conclusion of it that it'd be a really good idea to encourage much greater deployment of 6to4. E.g. anyone who wants IPv6 connectivity should perhaps be encouraged to also enable 6to4, ISPs should be encouraged to try to setup 6to4 relay services for their networks - even if they also provide native v6, and service providers to list 6to4 addresses, etc.

If you find that document, let me know. ;) Iljitsch van Beijnum's "Running IPv6" book is a nice read and quite practical, fwiw.

IPv6 destroys privacy, by default

neilbrown — Thu, 10 Feb 2011 06:54:30 +0000

Yes, the default is unfortunate in these privacy-threatened days.

> 1. every time your IP address changes you break all existing connections that you have.

RFC4941, Section 2, point 2:

> Deprecated address can continue to be used for already
> established connections, but are not used to initiate new
> connections.

> 2. if you happen to be logged in to some site that has a session cookie (even a short-term, for this login only type), that cookie will persist from your old address to the new address, allowing that site (and any advertisers working with them) to track that you moved from one address to the next

I think this is really a browser issue. Browsers seem to be getting better an managing cookies, and binding cookies to local network addresses would be a reasonable privacy option I would think.

> 3. as you move from one network to the next, you still don't have your address change, so they can do limited tracking (say home to office) on a routine basis.

RFC4941, section 3, end of point 4.

> A node highly concerned about privacy MAY use different interface
> identifiers on different prefixes, resulting in a set of global
> addresses that cannot be easily tied to each other. For example
> a node MAY create different interface identifiers I1, I2, and I3
> for use with different prefixes P1, P2, and P3 on the same
> interface.

Thanks for raising these - there are real issues with privacy, but it seems the IPv6 working group is well aware of them and is moving forward. I suspect we will have randomised address support in Linux before too long.

The last IPv4 address blocks allocated

daniel — Thu, 10 Feb 2011 06:00:39 +0000

Is there actually a link to the quote? There is always the possibility he was misquoted.

In any case, obsessing about who said what about what is less than useful. Progress in understanding is much more useful. For me there are a few takeaways from the thread:

1. I need to configure 6to4 and see how that works for me. The debian IPv6 wiki is the starting point for this.

2. I am not alone in the experience of being shouted down for even considering a fallback plan.

3. There seems to be some support for the idea of an extended address IPv4 scheme implemented at the edges of the existing IPv4 network.

I sincerely hope that IPv6 succeeds in saving the world from the twin daemons of address exhaustion and nonglobally routeable addresses. However at this juncture I perceive significant risk that it may not, and that it makes sense to consider alternatives. I do not think it makes sense to wait until failure is a fact to begin doing something about it. The converse, that some alternative experiments were tried and proved to be unnecessary in the face of widespread IPv6 adoption, does no harm. And should an alternative approach somehow actually displace IPv6 (however unlikely that might be) then that likewise would do no harm: the better approach would have prevailed.

The freedom for anyone to operate a server on the internet is too important to be left to chance. Any approach that could possibly preserve that freedom needs to be investigated seriously, and without delay.

The last IPv4 address blocks allocated

dlang — Thu, 10 Feb 2011 05:31:04 +0000

there are a number of IP options that are commonly used, I don't think that just the presence of any option pushes things to the slow path.

but this is a valid concern to test the impact (and I also agree with you that if this does become common, new routers will handle it in the fast path pretty quickly)

in this case, we are talking about an option that the routers would not have to act on, so they should be able to just act as if it's not there.

The last IPv4 address blocks allocated

dlang — Thu, 10 Feb 2011 05:28:27 +0000

this could make every (linux based) access point a 6to4 gateway pretty easily.

I haven't dug into the 6to4 protocol, but how do the various 6to4 devices find each other?

IPv6 destroys privacy, by default

dlang — Thu, 10 Feb 2011 05:26:06 +0000

speaking of problems in IPv6, I just got the latest edition of ;login and it points out one of these problems

if you use the 'recommended' autoconfiguration approach and are using linux or OS/X then the advertisers don't need cookies or anything like that to track you around the Internet, the last 48 bits of your IPv6 address are going to be your MAC address, which is supposed to be unique, and therefor no matter what network you are on, the advertisers can track you uniquely.

according to the article, since the MAC is used directly, people you connect to can even tell the type of hardware you are using (and since Apple is a distinct type of hardware with it's own MAC address range, you can tell by the IP address if it's a Apple device or not)

and the IPv6 RFC to fix this? it specifies an algorithm that changes your IP address periodically. this has a couple of problems

1. every time your IP address changes you break all existing connections that you have.

2. if you happen to be logged in to some site that has a session cookie (even a short-term, for this login only type), that cookie will persist from your old address to the new address, allowing that site (and any advertisers working with them) to track that you moved from one address to the next

3. as you move from one network to the next, you still don't have your address change, so they can do limited tracking (say home to office) on a routine basis.

the suggested rate of changing your IP address is once every 24 hours.

The last IPv4 address blocks allocated

neilbrown — Thu, 10 Feb 2011 03:20:19 +0000

> " a single physical host must be able to act as if it were
> several distinct hosts to the extent of using several distinct
> internet addresses. "

Thanks. I stand corrected. In fact, a little further down it says:

> That is, provision must be made for a host to have several physical
> interfaces to the network with each having several logical internet
> addresses.

which makes it even more explicit.

Maybe it is just me, but I have never thought about IPv4 addressing this way, and the tools I had to use never encouraged it.

Conversely IPv6 seems to encourage it and I find this changes my thinking about addresses. I was considering the question earlier this week of whether I should aim for 6to4 or a freenet6.net tunnel to get IPv6 connectivity. Now it is obvious that it is not a question of 'either/or'. It can make perfect sense to have both (or it would if I could find a way to de-configure router broadcasts when a tunnel disappears).

Thanks for the conversation btw, I've found it quite instructive.

My current thoughts on IPv6 are that it could do with a better publicist. It really is different to IPv4 and educating the techy world about those differences and how to make best use of IPv6 would go a long way I think... Or does such education exist and I missed it somehow? Is there some "best practice" documents on how to configure a home, an enterprise, an ISP?
I can easily imagine the smaller home-router manufacturers being confused by all the IPv6 options (do I use 6in4 or Toredo or 6rd, do I provide dhcpv6? How do I make this all transparent to the user?). If there were a definitive guide there might be more capable hardware???

The last IPv4 address blocks allocated

neilbrown — Thu, 10 Feb 2011 02:52:44 +0000

> Vint Cerf still referring to IPv4 today as an "experiment" is delusional, maybe that is a better word than clueless.

Where you present when he made that statement?

I was and it did not come across as a firm statement about the way things are today. Clearly it is more than an experiment now.

My understanding was that he was referring to the time when he made the decision to use 32bits for the address field. At that time, IPv4 was considered by him (and probably others) as an experiment. When he called IPv4 "experimental" he was referring to that time.

So you might be able to make a case that he was "naive" (but then, aren't we all sometimes), but there is no basis for saying he is "delusional".

He also said "the experiment is over" (or words to that effect). I took this as a combination of tongue-in-cheek, wishful thinking, and irony.
It could even be taken to mean "IPv4 is no longer experimental". I don't think that was the only thing he meant, but it could certainly be one of them. In that case it would seem you and he are in agreement.

The last IPv4 address blocks allocated

paulj — Thu, 10 Feb 2011 02:19:08 +0000

IP options must be passed on in forwarded packets. However, the presence of IP options may cause the packet to go through a slow-path in routers (e.g. punted out from the hardware to be handled by software). Because of this, some argue IP options can never be generally used (may be other reasons I've forgotten ;) ). I think that argument is silly though: if an IP option were popular, and generally was in a fixed place in the packet (e.g. the first option) the router vendors would soon enough manage to keep such packets in the fast-path.

The last IPv4 address blocks allocated

foom — Thu, 10 Feb 2011 02:13:34 +0000

But what would be the advantage over using 6to4? If you're going to argue that IPv6 is gonna fail, using *just* the 6to4 part of IPv6 and ignoring wide-scale native IPv6 routing entirely seems like it would be a fine implementation of your extended-IPv4 idea -- one already universally implemented!

The last IPv4 address blocks allocated

paulj — Thu, 10 Feb 2011 01:55:22 +0000

What you're seeing is just an artifact of ifconfig and the use of BSD backwards-compat APIs for configuring interfaces, (instead of the more Linuxy netlink). Try this instead:

ip address add 192.168.x.y/24 dev eth0

Note that this address is invisible to ifconfig (as it doesn't have a "label eth0:X" argument), but visible with 'ip' and quite useable.

Some other Unixen do indeed require that every IP address have an interface associated with it. But this is just a *logical*, internal book-keeping thing - mostly an artifact of hacking multiple-addresses onto code that wasn't originally designed for it, in order to maintain backwards compatibility with old userspace interfaces. E.g. in Solaris each address has to have an ipif - iirc the first ipif is special and links to a master interface structure, and the interface state is replicated across the ipif's. All very icky, and it's all because of backwards-compatibility. Further, *all* these interfaces are *IP* specific interface structures - not really physical. To really figure out the physical interface state you need to use a different API, which queries different state. They started fixing this somewhat (at least in terms of user-space tools, see dladm)...

However, assumptions in traditional Unix interfaces != protocol requirements. A requirements of "1 IP per physical interface" is most definitely NOT in the RFCs. E.g. RFC791 contains the following language (and note it covers a host with a single interface):

" a single physical host must be able to act as if it were
several distinct hosts to the extent of using several distinct
internet addresses. "

And RFC1122 describes "strong" and "weak" host models. In the latter case a host does not per se have a strong binding between IP addresses and physical interfaces. Linux, Solaris, etc implement this model.

Re RFC3584: I'd missed that the SAS RFC also specified a destination sorting procedure. Ta! Note the last of example of 10.2 though - non-6to4 is preferred, where both src and dst hosts have both. This is configurable with GNU libc via /etc/gai.conf (from a recent comment on LWN).

The problem with multiness is that clients are really poor at probing for reachability. Often they try sequentially. So if they happen to try your least-reliable addresses/connectivity first, the client may get a poor user-experience (I read something recently about Apple making some OS-X apps - the browser? - try v4 and v6 connections in parallel instead, to avoid any perceived hangs due to v6 being enabled). Because of this, many sites will only advertise a set of relatively equally reliable addresses, for clients to rendezvous with. They don't want the risk of listing a less reliable address (where the unreliability may be on the client's side obviously).

Better client behaviour at probing for reachability, in parallel, would be good. However, if a client has v4, native-v6 and 6to4 connectivity, and a service has 2 of each of the same, then that's quite a few combinations - 2x IPv4 paths, 8x IPv6 possibilities, potentially 10 paths to try probe. Some of those paths may not be distinct, remaining ones may converge: do we really want clients to send potentially 10x or more numbers of packets to setup a connection? These are the issues the likes of Shim6 has had to deal with anyway.

As for renumbering, I'm not sure it's much easier with IPv6, sadly. ;) RA and prefix-delegation make things /slightly/ less painful. It's still quite a manual job though.

The last IPv4 address blocks allocated

daniel — Thu, 10 Feb 2011 01:51:33 +0000

I do not really think that I am using "his" IPv4. I think it is really more Bob Kahn's, and I think that Bob Kahn is the person who really should be referred to as the father of the internet. Vint Cerf would appear to be a late joiner of the project and a relatively minor contributor who later somehow became commonly regarded as having a larger role than he really did. If I am wrong about that I would love to be corrected, however the paper trail supports this view.

http://en.wikipedia.org/wiki/Robert_E._Kahn

Vint Cerf still referring to IPv4 today as an "experiment" is delusional, maybe that is a better word than clueless.

The last IPv4 address blocks allocated

daniel — Thu, 10 Feb 2011 01:39:28 +0000

Ah. The port space kind of works for address space mitigation but it would be awfully nice to leave it alone if possible. So I am looking at a couple of different kinds of "if possible". One idea is to re-purpose a formerly defined but now deprecated IPv4 header option field, #8 (satnet). This provides a 16 bit "stream ID" which has not had any practical purpose for a long time, if it ever did.

RFC 791 has this to say about options in general: "The options may appear or not in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation"

http://www.ietf.org/rfc/rfc791.txt

It seems to me that a literal reading means that a router MUST faithfully pass on any options it receives. The next question is, does this actually happen in practice? If it does, it would be great help in implementing a nice extended IPv4 that where software only has to be changed at the edges where we, as in Linux devs, are in control.

The only way to know what that sea of routers does today with a satnet option field is to try it, and the easiest way to try it is a kernel hack. There are certainly other ways to do this experiment but for me patching the kernel is the most direct route.

The last IPv4 address blocks allocated

dlang — Thu, 10 Feb 2011 01:22:10 +0000

I'm sure that people thought the same thing about IPv4 when it was initially designed, before it got extensive use.

I'm sure that once IPv6 gets in use for a while and starts getting extended, it will end up just as crufty (not counting the built-in cruft of things that are already identified as over or under designed)

The last IPv4 address blocks allocated

jtc — Thu, 10 Feb 2011 01:12:24 +0000

"I'm always impressed how the IPv6 weenies manage to come up with these content free arguments to prove that IPv6 is perfect. Well its not, and you are too rude to discuss anything with so forget it."

Speaking of being content-free, your posts here are much poorer in content and details backing up your arguments then RobSeace, the person you're arguing with.

(I know this entry is late, but I couldn't help pointing out an obvious case of hypocrisy.)

The last IPv4 address blocks allocated

dlang — Thu, 10 Feb 2011 00:58:10 +0000

it's not just the linux IPv4, the same thing is possible on AIX and Solaris

as for DHCPv6, I thought the DHCP purists were claiming that DHCP isn't needed with IPb6 because everything just autoconfigures and that DHCPv6 is a corruption of the pure elegance that is IPv6 (Ok, I'm exaggerating here, but not by much)

beyond that, I think the difference between the 'hacked up IPv4 support for multiple addresses' and the 'designed in IPv6 support for multiple addresses' is more cosmetic than anything else.

The last IPv4 address blocks allocated

nix — Thu, 10 Feb 2011 00:46:31 +0000

Quite. One thing that's plain about IPv6 is that the whole thing is very well designed. Parts of it may be overdesigned (e.g. bitstrings and A6 records) and parts underdesigned (we need something better than PTRs, or IPv6's easy address mobility will be less useful than it might be) but the whole fits together really, really well.

The last IPv4 address blocks allocated

neilbrown — Thu, 10 Feb 2011 00:39:18 +0000

So you are saying that the current Linux implementation of IPv4 allows multiple addresses to be configured per interface. I'm sure you are right, but that is different from saying that IPv4 (as a whole) allows multiple addresses per interface.

I'm sure if you went back and looked at the relevant RFCs you would find the language assumes 1-1 and probably explicitly states it.

For example, the DHCP (v4) rfc talks about the client getting "its address" from the DHCP server. Singular address.
By contrast, the DHCPv6 RFC repeatedly talks about "addresses" (plural) of the client (which may be found through auto-config or may be found through DHCP).

So in the DHCP part of the the whole IP ecosystem at least, IPv4 does not support multiple addresses per interface, while IPv6 explicitly does.

The last IPv4 address blocks allocated

dlang — Wed, 09 Feb 2011 23:41:32 +0000

I fully expect the ISPs to disable the mobility of the IPv6 addresses.

it won't happen immediatly, but as soon as the crooks start advertising IP addresses that belong to other companies, therefor routing traffic to their site instead of the real site, the ISPs will start locking down accepting IPv6 broadcasts just like they currently lock down accepting BGP broadcasts.

The last IPv4 address blocks allocated

dlang — Wed, 09 Feb 2011 23:39:14 +0000

IPv4 can have more than one IP address per interface.

however ifconfig does not, but if you use the ip command you can assign multiple IPv4 addresses to a single interface.

The last IPv4 address blocks allocated

neilbrown — Wed, 09 Feb 2011 23:23:24 +0000

> IPv4 can have multiple addresses/interfaces

Nope. IPv4 is one address per interface.
In Linux (and other OSes presumably) you can create several virtual interfaces that map to the same physical interface (eth0, eth0:1, eth0:2 ...)
but there is still one address per interface.

You and tell because when you set the address of an interface:
......ifconfig interfacename address
it removes the old address. In IPv6 you cannot even say that. You say:
......ifconfig interfacename inet6 add address
which adds an address without deleting any old address.

This is more of a mind-set issue than a practical implementation issue.
I think the IPv6 mindset is very different to the IPv4 mindset. Sometimes a difference of degree is so big it becomes a difference of kind.

> getaddrinfo sorting (is there a standard for that now? cool).

RFC3484. I don't know if it is a 'standard' as such, but yes - that is what I was referring to.

> Or are you arguing all hosts should have both 6to4 and v6?

Yes. And IPv4 (NAT'ed if necessary).

> Why bother with the non-v6 part at all then though?
(I think you mean non-6to4 part)

Eggs and baskets?
Pure IPv6 is the best long-term strategy I think. But it is a difficult short-term strategy.
Conversely 6to4 is an easy short-term strategy, but it is imperfect as a long-term strategy.
I think it makes sense to adopt multiple strategies, and IPv6 seems to have been explicitly designed to allow this.

One of the really nice things about IPv6 is that it seems to make it quite painless to transition a site from one address range to another.

You simply connect the new address range and hove your routers send out router advertisements for it. The clients will then pick it up, choose an address, and will have an address on both old and new.
After initial testing you change the preference in the broadcast so that clients start preferring the new addresses.

Then update the DNS for any hosts that really need to be in the DNS, and wait for that to propagate around the world.

Then a week or so later you unplug the old route and you have achieved a fairly smooth transition.

So it seems easy to run with multiple forms of connectivity, and to phase out old ones that are past their usefulness quite smoothly.

It is almost like we should be thinking "multi-stack" rather than "dual-stack"

The last IPv4 address blocks allocated

bronson — Wed, 09 Feb 2011 23:10:08 +0000

So Vint Cerf is beyond clueless but you love his IPv4? Are you even trying to make a coherent argument anymore?

The last IPv4 address blocks allocated

paulj — Wed, 09 Feb 2011 22:52:27 +0000

The port identifier space of UDP and TCP. I.e. ever greater use of NAT. Today, NAT in ISP settings is used to compress 1 customer network down to 1 public, ISP-assigned address. That will change to compressing multiple customers networks down to 1 address, the port space being press-ganged into service as a customer identifier - as ISPs more and more make use of NAT on their side. Some ISPs already do (some cable ISPs, some industry specific service providers, mobile phone networks, etc).

The last IPv4 address blocks allocated

paulj — Wed, 09 Feb 2011 22:36:10 +0000

IPv4 can have multiple addresses/interfaces. However, whether those addresses are associated with one interface, with interfaces on one machine, or with multiple machines doesn't really matter for routing.

What standard are you thinking of btw? Source-address selection? getaddrinfo sorting (is there a standard for that now? cool). But how will that help hosts only on 6to4 connect to hosts only on general v6 and vice-versa? Or are you arguing all hosts should have both 6to4 and v6? Why bother with the non-v6 part at all then though?

I agree 6to4 could perhaps work quite well if it was nearly ubiquitously deployed - but so far *it isn't*. I'd join you in encouraging its wider deployment, if that's your point. However, at the same time the small amount of v6 deployment that is going on is using general v6-space, which is creating these detour-routing problems, which is what makes the next few v6 deployers wary of relying on 6to4. ;)

Things could still change though, of course.

Dual stack

daniel — Wed, 09 Feb 2011 22:10:56 +0000

"That is not quite true - they can run on the same kernel at the same time and communicate back and forth without 32 bit code requiring any special awareness of 64-bit code, and vice versa. To much greater advantage, the 64 bit capability does not require virtually everyone else in the world to upgrade as well to have any marginal benefits."

Exactly. If AMD had done things the IPv6 way then you would need to run 32 bit and 64 bit code on separate cores (dual stacks). Instead, they decided that nearly all 32 bit instructions would execute properly in 64 bit mode. Indeed, so so nearly all 16 bit instructions and all 8 bit instructions, as a result of a design philosophy consciously employed by intel in the 8080 -> 8086 transition and again with 286 -> 386.

Extending the analogy to packet protocols, the very first design rule should have been that an IPv4 packet is also a valid IPv6 packet. Then define some sane extension to extend the address width. In kernel the implementation is just an elaboration of the standard address handling.

The practical result: no dual stack. Big difference.

What the IPv6 committee ended up with is disturbingly analogous to Itanium.

The last IPv4 address blocks allocated

daniel — Wed, 09 Feb 2011 21:50:29 +0000

Positively rational compared to claiming IPv4 is an experiment that's over.

Sent via my IPv4 experiment

The last IPv4 address blocks allocated

daniel — Wed, 09 Feb 2011 21:10:55 +0000

<quote>for the IP protocols anyone cares about, there's an extra 16 bits of identifier space on each side that still can be squeezed out...</quote>

Which 16 bits were you thinking of?

The last IPv4 address blocks allocated

daniel — Wed, 09 Feb 2011 21:04:55 +0000

"given these constraints, this is the best design possible"

I believe that IPv6 was not the best design possible under the given constraints, far from it. But don't believe me, believe the uptake numbers.

A better design would preserve backward compatibility with IPv4. It is not too late to contemplate such a better design.

The last IPv4 address blocks allocated

neilbrown — Wed, 09 Feb 2011 20:52:23 +0000

> IPv6 *services*, as things stand, will in general NOT be built on the 6to4 subset of the IPv6 address space because of the paucity of 6to4 relay services and the often poor routing between 6to4 space and the rest of the IPv6 space.

Certainly they wouldn't be likely to be built *only* on 6to4 addresses. But IPv6 doesn't have the "one address per interface" concept that IPv4 has and I think it is important to drop the mindset of having "an address" and think about what "addresses" you should have.

So a service that wanted to be well connected would have an IPv4 address (if possible), a 6to4 address, a global IPv6 address, and of course a link-local address. It might make sense to have a Teredo address too. As addresses are so cheap in IPv6 it makes sense to use several if that improves your connectivity.

A standards-compliant client will then use whichever address it's local addresses are the best match for.