[governance] Why we need IPv6 and why you should care

[McTim]

On Wed, Feb 27, 2008 at 11:50 PM, Ian Peter <ian.peter at ianpeter.com> wrote:
> OK, so I can get clear about where we are at.
>
>  Thomas clarified (and Avri agreed) we won't get rid of NATs with IPv6.

Not immediately, no, but in the long term, probably.

So
>  the architecture remains IPv4+NATs+IPv6+IPv6NATS+dualstack. (that's not
>  exactly what the founding fathers envisaged in the early 1990s when they
>  began working on this...)
>
>  The single solitary reason why we would introduce this architectural dilemma
>  is to obtain a larger address pool,

No, that's just the immediate benefit.

 because the current one might on current
>  usage patterns run out in a decade or so.


~2 years, ~3 tops.

Getting rid of the scourge of
>  NATs, although it was originally a large part of the justification for IPv6,
>  now has to be understood as an end to end pipe dream.
>

See now, NATs aren't a "scourge". Lots of folks like them, as they can
be very useful.  It's a holy war, one in which I am agnostic.

>  Other important statements from Thomas in later messages include
>
>  >When the free pool is exhausted, people will still be able to obtain
>  >addresses
>
>  >No one wants to go first, because the cost/benefit argument favors delay.
>
>  >We will only abandon IPv4 if the cost of maintaining it exceeds the cost of
>  >moving to IPv6.
>
>
>  >The reason IPv6 has not been deployed is entirely economic. A week to
>  non->existant business case.
>
>  (All of which I agree with, except the latter. There are substantial
>  technical issues in deployment currently as well)
>

While it's not "easy", it's certainly possible. Many many folk have done so.

>  Irrespective, these factors suggest there will be extreme difficulty, if not
>  impossibility, in rolling out IPv6. That's the reality we have to face.

Again, it's not impossible.  Many networks have done it.  Maybe Adam
can tell us more about the Japanese and Korean networks that have near
ubiquitous IPv6 connectivity (for mobile devices as well).

>
>  But - and this is a serious question - if we are retaining NATs anyway, and
>  accept them as part of the architecture and use them efficiently, can't we
>  solve the address problem without IPv6?
>

Maybe, in the short term, probably not for the long term.

>  Then there is mobility. Thomas wrote

<snip>

Let me go back to what you wrote before on mobility:

>But does it work anyway within IPv6, which, like its >predecessor, was not
>designed for mobility?

IIUC, v6 WAS designed with mobility in mind.


>Isn't one of the unresolved technical issues with
>IPv6 mobility and multihoming?

Yes.

Doesn't multihoming mean that >if I change
>away from my home base (as one tends to do with a mobile >phone) the IPv6
>address will have to change, i.e when a node changes its point >of attachment
>to the Internet, its address becomes topologically incorrect?

Multihoming is when a network has more than one link to the Internet.
Usually, but not always using multiple links to a single IP address
block.  You can do it with a link load balancer, and a variety of
other ways as well.

What you are referring to seems to be IPv6 mobility, which you can
easily Google for.

>
<snip>
>
>  But as this discussion has continued, it seems that, NATs or not, IP won't
>  handle this vision in its current state anyway? IPv6 may enable it by making
>  more numbers available providing we can figure the rest out, but in the
>  meantime if I move back and forth between IPv4 and IPv6 networks (as one
>  might in a coexistence situation) isn't the situation vastly more complex
>  than it is now for routing?

No.  The networks are going to be routed, whether or not you are on
them.  Maybe I have missed your meaning?

Doesn't IPv4/Ipv6 co-existence make mobility
>  more difficult?

maybe, but not insoluble.

-- 
Cheers,

McTim
$ whois -h whois.afrinic.net mctim
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance