D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Your ISP - and IPv6

 

hi martijn,

On Fri, 5 Jul 2013, Martijn Grooten wrote:
On Fri, Jul 5, 2013 at 10:30 PM, wes wrote:
the crux seems to lie here:

The specifications [for IPv6] could have defined a functionally
equivalent public IPv6 address for each public IPv4 address,
embedding the IPv4 address space into the IPv6 address space; but
they didn't.

this design decision is utterly baffling to me.

I really fail to see how this would have made a difference.

in the piece itself, it is argued that by failing to define such an
equivalence, the IPv6 protocol doomed itself to lackluster adoption.

i did not quote all relevant details of the argument, but only what i
saw as its basis.

If a device (like a router) doesn't know about IPv6, it can't "fall
back to IPv4", as it doesn't know how this falling back would work.
So it would need to be reprogrammed to understand this falling back.

yes, reprogramming would have been required regardless.  i do not
think that is the point of bernstein's piece.  neither does bernstein:

[ also from http://cr.yp.to/djbdns/ipv6mess.html ]
(One commentator characterizes my page as saying that ``it takes a
massive amount of work to convert all applications over to ipv6.''
He's completely missing the point. Even if all the programming were
done, public IPv6 addresses still wouldn't be useful. Why not?
Because they wouldn't be able to talk to most of the Internet. Why
not? Because most administrators on the Internet wouldn't have
bothered setting up their own public IPv6 addresses.)

it is claimed that if an embedding from IPv4 to IPv6 had been defined
(ie, if IPv6 had been designed as an extension of IPv4), then
development and deployment of software alone could get you a working
implementation of IPv6.

that is, given such an embedding, then with no more than software
development/deployment, devices A and B could communicate over IPv6
without A and B (and all devices in between) *also* making individual
arrangements to obtain IPv6 addresses.  so long as those devices
without IPv6 addresses already had IPv4 addresses, their IPv4
addresses would map into IPv6 space.

instead, not only must software be deployed on each device, but
addresses for each must be applied for and obtained as well.  software
only need be written once, to be applicable to all devices of a given
type, whereas petitioning for addresses is not so efficient.

widespread, mandatory duplication of work results in widespread
failure to adopt the protocol.

(miredo, which you nicely described in a different branch of this
thread, looks like a workaround developed to permit users to avoid
precisely this extra work.)

but perhaps my understanding of the argument is an oversimplification.
if so, i would like to know what i've missed.

IPv6 is a different protocol. It's not just IPv4 with longer addresses.

right.  the IPv6 bestowed upon us does not extend IPv4, as it happens.

and so i wonder, assuming there were practical considerations for this
decision, what were they?  what made it so impractical to define a
correspondence between IPv4 and some subset of IPv6, given that such a
correspondence would have greatly facilitated the adoption of IPv6?

pertinent references appreciated.

-wes


On Fri, 5 Jul 2013, Martijn Grooten wrote:

On Fri, Jul 5, 2013 at 10:30 PM, wes wrote:
the crux seems to lie here:

The specifications [for IPv6] could have defined a functionally
equivalent public IPv6 address for each public IPv4 address,
embedding the IPv4 address space into the IPv6 address space; but
they didn't.

this design decision is utterly baffling to me.

I really fail to see how this would have made a difference.

If a device (like a router) doesn't know about IPv6, it can't "fall
back to IPv4", as it doesn't know how this falling back would work. So
it would need to be reprogrammed to understand this falling back.

IPv6 is a different protocol. It's not just IPv4 with longer addresses.

Martijn.

--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq


--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq