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

[Cameron Byrne <[e-mail]>]

On Wed, Feb 22, 2012 at 10:12 AM, Rajiv Asati (rajiva) <[e-mail]> wrote:
> Hi Remi,
>
>> Compliance with the 464XLAT draft requires specific code that none of the
>> referenced RFCs specifies.
>> This code is to prevent other LAN hosts not only to avoid the router's
>> address, as usual, BUT all addresses starting with the chosen /95.
>
> Well, the code is nothing special, since it is part of typical NDP/DAD to prohibit a LAN host from using router's addresses (say).
>

Yes.  This is clear, and this behavior has been demonstrated in
commercial NAT-PT systems.

> However, the valid point you have is that if the LAN host duplicated the same address as that of the router (/96 based addresses, say), then the LAN host would be deprived of the address (and possibly global IPv6 connectivity).
>

It will not be deprived, it will be made aware via NDP that that
address is in use therefore it must select another address.

As described in the draft, the CLAT may also serve as a DHCPv6 server
and therefore will avoid the situation entirely for DHCPv6 clients
since the CLAT is capable and aware that the /96 is already in use.

> Of course, if there is no host in the LAN, then this problem is moot. Perhaps, 464XLAT deployment assumes the lack of LAN hosts.
>

No, we definitely make it clear in the draft that LAN hosts are in scope.

CB
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: Rémi Després [mailto:[e-mail]]
>> Sent: Wednesday, February 22, 2012 10:04 AM
>> To: Rajiv Asati (rajiva)
>> Cc: Cameron Byrne; v6ops WG; Russell Housley
>> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe
>> an ietf-v6ops I.D.
>>
>>
>> Le 2012-02-22 à 15:10, Rajiv Asati (rajiva) a écrit :
>>
>> >>> Alternatively, we may view the CLAT in terms of proxy NDP
>> >
>> > I think that pNDP is unnecessary. NDP is good enough here.
>> >
>> > Also, when we move to using DHCP-PD, then NDP on WAN int will not be
>> necessary either.
>> >
>> >>> 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.
>> >
>> > Remi, what is modified in your view?
>>
>> Compliance with the 464XLAT draft requires specific code that none of the
>> referenced RFCs specifies.
>> This code is to prevent other LAN hosts not only to avoid the router's
>> address, as usual, BUT all addresses starting with the chosen /95.
>>
>> Cheers,
>> RD
>>
>>
>> >
>> > Cheers,
>> > Rajiv
>> >
>> >
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of
>> >> Rémi Després
>> >> Sent: Wednesday, February 22, 2012 5:40 AM
>> >> To: Cameron Byrne
>> >> Cc: v6ops WG; Russell Housley
>> >> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not
>> tobe an
>> >> ietf-v6ops I.D.
>> >>
>> >> 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
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>