Subject: Re: [arch-d] On identifiers: what is virtual and what isglobal(wasRe: thou...

From: "Ian Peter" <[email-masked]>
Date: Tue, 28 Nov 2006 06:21:22 +1100

Interestingly there is a related discussion currently on the GENI mailing
list - here is an excerpt

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

-----Original Message-----
From: Medhi, Deep [mailto:[email-masked]] 
Sent: 25 November 2006 02:37
To: [email-masked]
Subject: RE: [Discuss] Net Result of GENI

>  John Leong wrote:
> > Jon Turner wrote:
> > Again, the reasons for the non-deployment of IPv6 have little to do 
> > with technology. They have to do with the fact that no one make a 
> > profit next quarter by investing in a move to IPv6. It has 
> to happen 
> > universally before it's much use to anyone, and in a system 
> with such 
> > diverse ownership as the Internet, universal agreement is 
> hard to come 
> > by.
> 
> Not completely sure about the above.
> 
> An example of a technology that get adopted very quickly and 
> widely even though it may not have have gained universal 
> agreement (particularly from the E2E purists) is, ironically, 
> the nemisis of IPV6 - NAT.
> 

While NAT has provided relief in the IPv4 address space and "delayed"
the need for IPv6, I believe, there is more to it. Note that IPv6 was
designed with a hierarchical addressing structure (sort of similar to
E.164 addressing for telephony), which can be simply stated as a
"provider-dependent" model (using "provider" to mean a  country or an
ISP, and so on). The difficulty with this approach is that it doesn't
easily allow multi-homing; that is, if you get an IPv6 address block
from an RIR, you cannot home to two different providers. Multihoming has
become a necessity for customers for diversity etc; it that works quite
well in IPv4 because at 'net-id' level IPv4 address can be thought of as
based on flat addressing. A related benefit of IPv4 address block (IP
prefix), even without multihoming, is that if as a customer you don't
like your provider, you can change your provider *without* having to
renumber your network/devices; this isn't possible in the
provider-dependent IPv6 addressing. IMO, the provider-dependent issue is
one of the key reasons for the 'non-popularity' of IPv6 address
deployment.

A question then is: can IPv6 addressing be made provider-INdependent?
Since IPv6 address space is so large, this is possible by carving out a
subset. Tony Hain, I believe, is the first one to  propose IPv6
provider-independent addressing based on lat-long, several years ago
(please, see the updated draft
http://tools.ietf.org/wg/ipv6/draft-hain-ipv6-pi-addr-use-10.txt). So,
perhaps, this could make barrier-to-entry easier for IPv6 addressing, if
this proposal (or similar one) is widely accepted.

Secondly, the mobile world has essentially made it a requirement to use
IPv6 (check out 3GPP, IMS). That is, the mobile services are already
going toward IPv6 addressing--here the provider deploys IPv6 addressing;
the end user lives on E.164 (certainly, SIP-based approach).

Thirdly, another need for IPv6 is when 10-net (NAT) cannot provide
enough address space. In fact, Comcast (a cable provider in US) is
already facing that as their estimate says that each household needs
several addresses for different devices such as (cable modem, set-top
boxes etc) and they don't have enough space if their business continues
to grow --- they have temporarily borrowed IPv4 public address block,
73-net (i.e., 73.0.0.0/8) as a stop gap measure. But their plan is to
deploy IPv6 address (and run Integrate IS-IS for routing within their
nationwide intra-domain network).  That is, a business need does require
moving to IPv6. Here provider-dependency suites fine. (see Alain
Durand's presentation from NANOG, June'06:
http://www.nanog.org/mtg-0606/durand.html).

I'm not saying that IPv6 is the end thing; but 'needs' do require us to
look at addressing beyond IPv4. Yet, provider-independency remains a key
barrier-to-entry for IPv6.

A quick comment about E.164. Although E.164 is a hierarchical addressing
format, it has been able to essentially get rid of the 'netmask'
problem; note that for E.164, the netmask can be thought of  at the
country code level, area code (city code level, a term commonly used
outside US), and at the central office level---the netmask traditionally
used for routing. This has been made somewhat possible by the
requirement for number portability---either geographic or
non-geographic. Note that number portability is analogous to
provider-independence, certainly number portability is more at the end
user level. In essence, the number portability has forced the E.164
address space to become "elevated" to more of a name. In other words, it
might be possible to get away from netmasking as used in E.164 by
introducing a level of indirection (i.e., elevating to naming)---this
however puts a tremendous burden (need?) on having efficient lookup
algorithms/processes, for example, for the notion of 'all call query'
etc (see RFC3482 for a discussion on number portability in PSTN).

Finally, it seems that different addressing will have to live together
in today's and tomorrow's networks. I couldn't have said it better than
Jon Turner when he wrote in an earlir mail:
"We need to move beyond a system in which progress requires universal
agreement. We don't require universal agreement in any other technology
domain. There is no longer any reason to require it in networking
either."

Regards,
  
 -- Deep Medhi

_______________________________________________
Discuss mailing list
[email-masked]
https://lists.geni.net/mailman/listinfo/discuss

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.14/548 - Release Date: 23/11/2006

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.16/552 - Release Date: 26/11/2006

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss