Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

[Rémi Després <[e-mail]>]

Cameron,
It seems we are close to common understanding.
More below. 

Le 2012-02-21 à 20:34, Cameron Byrne a écrit :
...
> On Tue, Feb 21, 2012 at 10:42 AM, Rémi Després <[e-mail]> wrote:
...
>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?
>> 
>> An answer to this?
>> 
> 
> Sorry i missed this earlier.
> 
> In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64
> and NAT64 must be coupled to replace NAT-PT functions.
> 
> But, RFC6146 and RFC6147 stand on their own.  There is no explicit
> coupling required or shared state between NAT64 and DNS64 for them to
> perform their atomic functions.  Meaning, any conforming packet
> (Pref64+32bit IPv4 destination address) may be received by an RFC6146
> stateful NAT64 and be translated.  A properly configured CLAT that
> knows the Pref64 may received IPv4 packets and translate them via
> RFC6145 to a PLAT without any queries or interactions with the DNS64.

I don't think a NAT64 that wouldn't work for IPv6-only hosts is a scenario that needs to be mentioned, especially since it contradicts an existing RFC.
IMHO, stating that, with a CE architecture like that of the 464XLAT draft, a stateless CE can work with a stateful NAT64 is enough.
Adding that it can work without DNS64 is AFAIK at best unnecessary, at worst confusing.
That could advantageously be deleted (IMHO). 
 
...
>>>>>> Why, then, say "In the best case, the CLAT will have a dedicated /64"
>>>>>> 
>>>>> 
>>>>> It just seems cleaner to me to have a dedicated /64 if it is
>>>>> available.  Operationally, aside from the NDP claiming the /96, there
>>>>> is no difference to have dedicated or not dedicated.
>>>> 
>>>> Understood, but:
>>>> - Claiming a /96 on a link seems new to me (is there an existing reference?)
>>> 
>>> It does not need to claim the /96 as a whole.  The CLAT will do NDP
>>> with the idea that each /128 in the /96 is owned by the CLAT as a
>>> virtual address.
>> 
>> Was understood.
>> 
>>> I have seen this behavior in NAT-PT deployments, but i do not see it
>>> specifically declared in the NAT-PT RFC.
>> 
>> Right, it seems to be new material as far as IETF is concerned.
>> 
> 
> NDP for a host address should not be new material.  

Nothing is new in your proposal for hosts, right, but NDP operation IS modified in CE routers. 

> As i mentioned
> before, we can treat each address in the /96 as a host address on the
> CLAT, and the interactions are normal for NDP host addresses.

Understood. 
The fact that this is new in the router CE is not a problem AFAIAC, but provided new pieces of design are clearly identified.

> Alternatively, we may view the CLAT in terms of proxy NDP
> http://tools.ietf.org/html/rfc4861#section-7.2.8

Doesn't this require support of RFC3810 (Multicast Listener Discovery Version 2 (MLDv2) for IPv6)?
That could be part of the specification, but would AFAIK would be a constraint. 

> The CLAT is willing to accept packet destine to the /96 on behalf of
> the IPv4 internet, and the NDP actions are defined as existing Proxy
> NDP.
> 
> Thoughts on one verse the other?

My thought is that BOTH can be AVOIDED.
It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs from all valid native IPv6 prefixes.
This is easy to have, and is part of the 4rd-U proposal.
The architecture you propose can easily benefit from it, simply by adding its scenario as a particular one of the 4rd-U general scheme. 

>> I think I understand your motivations, and hope you can understand those of draft-ietf-softwire-stateless-4v6-motivation.
>> 
> 
> Yes, and thanks again for your careful review and attention to the 464XLAT draft

I confirm that IMHO your draft brings quite useful new material.

If you can take time to look at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03, my hope is that you will understand that coordination between its contents and that of your draft should be useful.

Regards,
RD 




> 
> CB
> 
>> Regards,
>> RD
>> 
>> 
>>