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

[Cameron Byrne <[e-mail]>]

Thanks Remi. It sounds like all technical issues have been resolved. We
will update the draft for based on the groups feedback.  Thanks again.
On Feb 23, 2012 1:00 AM, "Rémi Després" <[e-mail]> wrote:
>
> Cameron,
>
> Le 2012-02-22 à 19:59, Cameron Byrne a écrit :
>
> > 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.
>
> Even if it does the second, it must do the first because hosts MAY use
SLAAC.
> Right?
>

Yes

> >  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.
>
> The router claims its address, yes, but not 2^(128-96) addresses (more
than 4 billions)
>

Yes

> > I believe
> > you said you are OK with this action as long as the draft is clear on
> > it.
>
> I understand it can work, yes.
>

Great

> I also say that the need for it can easily be avoided.
> For this, just make sure IPv6 addresses that represent IPv4 addresses
are, in hosts that support IPv4 applications, distinguishable from native
addresses.
> The V octet of R24 in
http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 does it.
>

I will study this

> >
> > 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?
>
> If you still find it useful to say that there may be no DNS64, yes, an
explanation would be welcome.

We will add more clarity

> Yet, in view of RFC6144 in which all scenarios have DNS64 where there are
NAT64s, I would personally suggest to avoid dealing with this independent
problem in your draft (a minor point though).
>

ack

> >
> > 3.  Cameron will do a detailed technical review of 4RD-U and submit
> > comments to Softwire.
>
> I do look forward to it.
>
>

Me too

> > 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:
> ...
> >> 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.
>
> AFAIK, having a DNS64 deployed doesn't force all hosts to use it.
> A sentence reminding it would make no harm.
>
>
> > We can add a section that makes the packet flow for operation without
> > a DNS64 clear, would that help?
>
> Same answer as above.
>
>
> >> ...
> >>>>>>>> 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.
>
> Same answer as above.
>
> >>> 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.
>
> As already suggested, the easiest path to get rid of this problem would
be to permit hosts that support IPv4 applications to distinguish native
IPv6 addresses from those that represent IPv4 addresses, even with a single
assigned IPv6 prefix.
> Your comments on this are welcome.
>
>
> >>> 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.
>
> As said, the V octet of 4rd-U brings the benefit of a dedicated /64
without needing to have one.
>
>

This again for detailed review.

Cb

> Regards,
> RD
>