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

[Cameron Byrne <[e-mail]>]

On Wed, Feb 22, 2012 at 2:40 AM, Rémi Després <[e-mail]> wrote:
> Cameron,
> It seems we are close to common understanding.
> More below.
>

Yes, I do believe that is the case.

Once again, thanks for your time in reviewing this work.

 If i may summarize your remaining technical concerns:

1.  The CLAT will claim the /96 on the LAN via NDP or by marking the
/96 as used in the local DHCPv6 server of the CLAT.   In the case of
non-DHCPv6 LAN clients, I believe this is normal NDP action for a
router to claim it's addresses to avoid address conflict. I believe
you said you are OK with this action as long as the draft is clear on
it.

2. You believe the scenario for operation without the DNS64 is
confusing in its current form. We can add a section that explicitly
explains this scenario vs DNS64 scenario, is that ok?

3.  Cameron will do a detailed technical review of 4RD-U and submit
comments to Softwire.

More in line


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

We'd like to keep it, since DNS64 is not always available or fit for a
given network.  Others have submitted feedback on list that they
believe it is important for hosts to be able to use the DNS server of
their choice, not the provider DNS64.

We can add a section that makes the packet flow for operation without
a DNS64 clear, would that help?


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

To be clear, you are OK with the NDP action on the CE?  We can add
language to make it more clear in the draft.

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

I am open to discussion on the right path forward for this.

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

Yes, in the draft, we state a dedicated /64 for the purpose of
translation is best.  But, we also recognize that is not always
available, such is the case for mobile networks.

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

I will do this, but first my time is prioritized in resolving
technical issues of 464XLAT

CB

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