re: [RRG] What does incremental deployment mean

[Xu Xiaohu <xuxh@huawei.com>]

> > The private addresses behind the NAT box are not suitable to be used as
> > identifier. However, these independent IPv4 address spaces can be used
as
> > locator spaces as long as each private address space can be
distinguished
> by
> > some means, such as globally unique locator space ID or the public IPv4
+
> > locally unique locator space ID.
> 
> I don't think we want to set up yet another ID space and registry (see
next
> comment). I did just realise, reading draft-despres-v6ops-apbp-00.txt,
> that when you're behind an IPv4 NAT, your transport ID is in fact
> uniquely defined by {publicIPv4address, translatedPortNumber} - the
> only problem being that this is known to the NAT and the other end,
> but not to the "victim" of the NAT. Your network ID is uniquely defined
> by {publicIPv4address, privateIPv4address} although nested NATs make
> this more complicated.

Let me clarify the idea of independent locator spaces. There are two
approaches to identify each locator space: 

The first one is to assign a globally unique LD ID to each locator space,
the LD ID is similar to AS no, but the LD ID is hierarchical and
aggregatable, e.g IPv4 address. This idea is borrowed from ENCAPS. However,
the AD ID in ENCAPS can not be aggregated since "the source and destination
addresses in the new header (I will call it the AD-Header from here on)
represent the source and destination Ads". That is to say, ENCAPS uses one
and only one tunnel between source and destination AD. In my idea of HRA, I
use segment-by-segment tunnels between adjacent LDBRs. LDBR implement LD
ID/prefix based routing, the internal IPv4 address within each locator
domain seems to be used as link-layer address.

The other one is to assign a local-scope unique ID to each private address
space behind a NAT box, the combination of the public IPv4 address of the
NAT box and the above ID will be used to distinguish each private address
space behind a NAT box. The latter approach looks like BGP/MPLS L3VPN and
there needs a core IPv4 network which is attached with a lot of private
address spaces. Once nested NAT is deployed, each successive NAT boxes will
need to implement ID->local locator mapping. This is the idea of IPNL.
However, IPNL uses FQDN as identifier.

> > Then we can introduce a pure identifier
> > namespace, such as IPv6 or CGA address.
> 
> Indeed. Not using IPv6 as the globally unique address space would be
> perverse in fact, since there is a complete registry and DNS support
> for it already.

Agree.

> > In this way, most of the routers,
> > especially those in the site network, do not need to be upgrade to IPv6,
> 
> Yes, but that upgrade is not an issue anyway - it's going to happen
> as hardware replacement occurs.

My opinion is the replacement of site/enterprise networks will be much
slower than that of the carrier or ISP networks. Perhaps the enterprises
prefer upgrading their hosts other than upgrading their site networks.

> > and
> > the routing scalability issue and address depletion issue are solved
> > simultaneously. Of course, this requires some small change in hosts.
> 
> Well, changes that require application software upgrades are the hardest
> of all. I don't see how to hide a change of ID space from applications.

Since we introduce IPv6/CGA address as a pure identifier, the locator change
will be transparent to applications. So only host stacks but not
applications need to be upgraded based on the assumption that most of host
applications are IPv6-friendly.

> > Is this approach more acceptable for site network owners compared with
the
> > v6 EID over v4 RLOC LISP approach? It's easy for carrier to upgrade
their
> > routers to IPv6, but it will be much hard for the site network to do
this.
> >
> > What's the better NAT solution in your mind?
> 
> draft-despres-v6ops-apbp-00.txt is too new for me to be sure,
> but I think it gets rid of NAT64, and that is the best solution
> of all.

There are still some questions left for this APDP approach, including but
not limited to:
1) How can the IPv4-only hosts connect to the apbp-enabled hosts?  Let's
consider p2p model but not limited to client-server model.
2) How the apdp servers coordinate with each other for the failover purpose
since the apdp server needs to store states? Let's consider the IPv6
transition together with the popular phenomenon of multi-homing.

Best wishes,
Xiaohu XU




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg