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

[Ian Peter]

Meanwhile from an article by Loki Jorgensen I get the following table of
implementation issues for IPv6


    * Relatively easy
          o Implementing dual stacks in LAN and WAN
          o Enabling IPv6 in operating systems
          o Setting up essential IPv6 services, e.g. DNS, SMTP, NTP
          o Setting up IPv6 in certain key services such as HTTP
    * Moderately hard
          o Composing an effective address/domain deployment
          o Operating a dual stack network
          o Multicasting
    * Very difficult
          o Security infrastructure such as firewalls, proxies, VPNs, etc.
          o DHCP
          o Dealing with incomplete and broken implementations
          o Promoting adaptation at the social layer
          o Soliciting vendor support




Ian Peter
Ian Peter and Associates Pty Ltd
PO Box 10670 Adelaide St  Brisbane 4000
Australia
Tel (+614) 1966 7772 or (+612) 6687 0773
www.ianpeter.com
www.internetmark2.org
www.nethistory.info
 

> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com]
> Sent: 28 February 2008 20:01
> To: governance at lists.cpsr.org; Ian Peter
> Cc: Thomas Narten
> Subject: Re: [governance] Why we need IPv6 and why you should care
> 
> 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
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.1/1299 - Release Date:
> 26/02/2008 09:08
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.21.1/1303 - Release Date: 28/02/2008
12:14
 

____________________________________________________________
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