North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: OMB: IPv6 by June 2008

  • From: Jeroen Massar
  • Date: Fri Jul 01 08:11:13 2005

[reply to Andre below this one]

On Thu, 2005-06-30 at 20:37 -0400, Todd Underwood wrote:
> 
> 
> On Thu, Jun 30, 2005 at 01:21:33PM -0400, Edward Lewis wrote:
> 
> > Having been in the US gov't (too) at the time of GOSIP, there were 
> > three reasons why I never used it much:
> [...]
> > 3) There was no tidbit of information available over the network that 
> > was on a server that spoke only GOSIP and not TCP/IP.  (No compelling 
> > reason.)
> 
> this is telling in this context.
> 
> where is the service that is available only on IPv6? i can't seem to
> find it.  

http://ipv6gate.sixxs.net which allows you to see the silly dancing
turtle, it is swimming actually, but you didn't know as you didn't see
it :)

Oh that thing allows one to see IPv4 sites when having IPv6 only and
seeing IPv6 sites when having IPv4 only:

http://www.kame.net.sixxs.org or http://www.kame.net.ipv6.sixxs.org for
the Dancing Kame when on IPv4, getting the IPv6 site

http://www.google.com.ipv4.sixxs.org for google, who don't do IPv6 yet.

As for the questions "who uses IPv6", I can tell you that that gateway
is making a certain politically-restricted group very happy to be able
to see/read/use various internet sites they are not capable of using
when using their normal IPv4 setup.

> maybe that's because i use the Internet for my daily activities (as
> does everyone else, including people in asia) rather than some
> non-internet, incompatible, no-migration-plan-protocol-based network. 

I am very happy to have been using IPv6 for over the last 5 years to be
able to overcome, just as the above, silly policies which where laid
upon me by goverments and monopolies. read: getting only 1 IP address
while I have way more than 1 IP-addressable endpoint at my home.

> manually configured tunnels forver!  (until we stop caring or come up
> with a real reason to migrate to something else, by which plan maybe
> we can have a migration plan and a better protocol suite with
> multi-homing).  

You mean automatically configured tunnels. Most people don't understand
what tunneling is, they do know how to click a couple of times in a GUI.
google(aiccu) ;)

On Fri, 2005-07-01 at 12:14 +0200, Andre Oppermann wrote: 
> Fred Baker wrote:
> > The point made in the article that Fergie forwarded was that Asia and 
> > Europe are moving to IPv6, whether you agree that they need to or not, 
> > and sooner or later we will have to run it in order to talk with them. 
> 
> Huh, Europe is moving to IPv6?  I must have been asleep at all industry
> meeting in the past few month and years...

Ah, well that explains indeed why you are missing out on it.
Read up at: http://www.sixxs.net/tools/grh/dfp/

> The problem with IPv6 is that it is broken by design and doesn't solve a
> thing that needs to be solved.  In addition various policies around IPv6
> intermix layers that don't want to me mixed.

You still have not explained the "broken by design" stuff. Can you do it once?

As for the policies, those will resolve themselves, at the moment it is
steering into a "announce as few prefixes as possible, but you can announce upto a /48".
Which sounds quite reasonable. The hardware can handle it anyway.

> I'm going out on a limb here but IMO IPv6 would have been a big success
> if it would just have extended the IP header to 64bit addresses and
> rearranged the fields to be well aligned (modulo kicking header checksum
> and some other clarifications).

For various reasons, amongst that feature called autoconfiguration, 128bits
are more appropriate. Actually IPv6 is 64-bits, at least on the routing level.
That the endstretch checks the latter 64 bits where to put it on the l2 link
is something you could just forget for simplicity sake.

> Then directly integrate IPv4 into that
> namespace for a relativly clear and transparent transition path and be
> done with it.

You mean ::192.0.2.1 and ::ffff:192.0.2.1 ?
Any idea how irritating those two are for programmers?
One has a listening server and does a accept() and then a getpeername() to
retrieve where the remote host is, you get an IPv6 address back, which you
suddenly have to be parsing as a IPv4 one, because you wanted to do ACL matches.
Now that is impractical, one can code around it but still.
read http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html for the solution btw.

The transition part is very clear, there are just many options because
there are actually people who have different networks than what you might expect.
The clear way:

 0) we have IPv4 only boxes
 1) add IPv6 stack to the boxes
 2) turn on IPv6 on the network
    - using tunnels where l2 paths don't support it
    - using native where it does support it
 3) upgrade the tools to support IPv6
 4) co-exist IPv4 and IPv6

Nopes, I am not putting in a 'turn off IPv4', that is not going to happen
in the coming couple of decenias.

>   All the other stuff and the different address scopes are
> not only impractical but confuse the average consumer and MCSE admin to
> no end (and those are the people that have to deal with it all the time).

Why are they impractical? The only address scopes you have is:
 - link local, compare it to your l2 mac address, it is mostly the same anyway
 - global unicast, which is the same as IPv4 unicast

Then you also have multicast and ula's. What is so weird here?
I've never found them impractical, did you ever tried to use them?

> return (ENOKITCHENSINK);

If you don't have a kitchensink then you can always go to a restaurant ;)
Fortunately the internet can live and work around missing components.
And when you don't like it, write up a paper how you do think it would
work and call it IPv8 or IPv16, but that was proposed quite some time
ago by somebody who is fortunately gone silent.

Greets,
 Jeroen

PS: preparing food, and devouring it after and during it, is a lot fun,
I suggest you try it one time, so go get your self a kitchensink :)

Attachment: signature.asc
Description: This is a digitally signed message part