Re: [RRG] What does incremental deployment mean

[Brian E Carpenter <[e-mail]>]

On 2008-04-09 20:37, Xu Xiaohu wrote:
> 
>> -----邮件原件-----
>> 发件人: Brian E Carpenter [mailto:[e-mail]]
>> 发送时间: 2008年4月9日 6:56
>> 收件人: Xu Xiaohu
>> 抄送: 'Randall Atkinson'; 'David R Oran'; [e-mail]
>> 主题: Re: [RRG] What does incremental deployment mean
>>
>> On 2008-04-01 23:13, Xu Xiaohu wrote:
>>>> Earlier, Dave Oran wrote:
>>>> % So I can imagine it being reasonable to handle host changes on about
>>>> % half of these. At best. And certainly not with a flag day just inside
>>>> % my little orandom.net domain.
>>>>
>>>> From your summary, it sounds like any router changes are also very far
>>>> from being a given.
>>> It seems that using multiple independent IPv4 address spaces in an
>>> id/locator split solution to address the IPv4 address depletion issue is
>>> reasonable.
>> That's exactly what NAT does. We're trying to do better,
>> I believe.
> 
> Hi Brian,
> 
> My thought is:
> 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.

> 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.

> 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.

> 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.
> 
> 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.

    Brian
> 
> Best wishes,
> Xiaohu XU
> 
> 
> 


--
to unsubscribe send a message to [e-mail] 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