Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC

[Wojciech Dec <[e-mail]>]

On 6 September 2012 15:26, Cameron Byrne <[e-mail]> wrote:

>
> On Sep 6, 2012 1:38 AM, "Wojciech Dec" <[e-mail]> wrote:
> >
> >
> >
> > On 6 September 2012 04:43, Cameron Byrne <[e-mail]> wrote:
> >>
> >> Woj,
> >>
> >> On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <[e-mail]>
> wrote:
> >> > A handful of comments:
> >> >
> >> > 1. Section 5
> >> > It would be useful to indicate how this solution differs from MAP-T
> >> > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or
> >> > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01),
> as well
> >> > as to note the architectural underpinnings of NAT464 of the xlat
> solution
> >> > which it effectively validates.
> >> >
> >>
> >> No, we will not be casting 464XLAT in light of other solutions.  The
> >> WG, AFAIK, concluded this here
> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html
> >
> >
> >  I didn't say that the xlat draft has to describe the MAP, what I did
> propose are listing points that make the xlat solution unique. It is a
> reasonable expectation of a draft from an SDO to at least contextualise to
> the reader as to how it relates to other drafts from that same SDO. This is
> very much in line with the conclusion in the mail you reference. At the
> moment the draft does not clarify that.
> >
>
> This was included before and has beeen removed because those words were
> not timeless or essential to a standards doc. That was thd WG feedback.
>
What was included? Certainly NOT the points i suggested.
If you're seeking for words that are timeless, then I think that the whole
of section 5, entitled "Motivation and Uniqueness" can be deleted.

Overall, it may help if you actually took on board constructive feedback.
The points I proposed indicate what is unique in xlat solution.

>
> >>
> >>
> >> And, AFAIK, MAP-T  is not longer an actively pursued solution.  A coin
> >> was flipped, and the IETF moved on.
> >
> >
> > That is not correct. MAP-T remains an active Softwires WG draft, albeit
> with experimental status which is not definitive.
> > The coin flip, was about one-draft or two drafts, not about MAP-T being
> "abandoned"
> >
> >>
> >>
> >> > In that context the points that IMO could help are:
> >> > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map
> allows
> >> > stateless or stateful NAT64)
> >>
> >> MAP allows stateful sharing of public IPv4 addresses on NAT64?  I am
> >> not sure how that can be given that Softwires does not have a charter
> >> for stateful solutions.  And, AFAIK, the current MAP document does not
> >> reflect any stateful work for sharing public IPv4 addresses.  Doing a
> >> search on draft-ietf-softwire-map-02 shows no references to RFC 6145
> >> and RFC 6146, which are the core of 464XLAT.
> >
> >
> > map draft-02 is the "post coin flip" version for MAP-E. The equivalent
> MAP-T draft is being readied and we'll post it soon, but it will be as per
> http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find
> abundant references to 6145.
> > We have been here before. MAP and XLAT are both NAT464 architectures. A
> MAP CEs jsut like a clat has proven interoperability with a regular
> stateful NAT64 core element. The difference is that the MAP CE requires
> explicit provisioning.
> >
>
> We have been here before, as you noted. If you want text, suggest it. You
> know the difference between the 2, no?
>

Reposting the suggested text & changes:
Section 5
- xlat adopts/assumes exclusively a stateful NAT64 PLAT core
- xlat focuses on deployments where client provisioning of the public IPv4
address is not possible or viable
- An alternative of the last point could be that the solution focuses on
deployments where the client does not require to be informed of the public
IPv4 address, and that default values are assumed.

2. Section 8.2.2
- It would help recasting this section as the "routed" clat mode. I.e the
clat is delegated a prefix for NAT64 usage, with this prefix being routed
i) by the clat device towards the upstream device ii) routed by and not
seen as directly connected by the upstream device.
- NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should
be that NAT44 is used to map several IPv4s to one external IPv4.
- The figure reflects none of that; it shows 1:1 mapping between IPv4 and
IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the
role of NAT44.
- It is not stated/specified what the external IPv4 address should be, or
how it is acquired/picked. This should be defined.
- What is currently also missing from this section is how the clat should
determine that it is to work in "routed" or "host" mode (section 8.3.2). It
is perfectly legitimate to have a PD and not use it for clat.

3. Section 8.3.2
- This section should be recast as xlat (clat) host mode for which the
upstream node considers the clat and the upstream device share an "on-link"
prefix.
- The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile
clarifying that.
- Personally I think that adding ND-proxy is undesirable (as also stated by
others) and harmful (eg for upstream devices such as BNGs). Devices on non
3gpp network should be directed to use the mode in section 8.3.2, which
would eliminate the need to mention proxy-ND at all.

-Woj.

> CB
>
> >
> >>
> >>
> >> > - xlat focuses on deployments where client provisioning of the public
> IPv4
> >> > address is not possible or viable (map requires explicit
> provisioning, xlat
> >> > works on defaults)
> >>
> >> Yes.
> >>
> >> i don't follow the rest of the comments and imagine the discussion
> >> will shift after we release -08 where perhaps these details are
> >> purposefully not specified and left to implementation discretion.
> >
> >
> > AFAIK the WG last call is for draft-08, not for some draft that has yet
> to be written.
> > The comments below, which I kindly ask that they be addressed, focus on
> the key aspect of whether the clat operates on a host or routed mode. The
> draft currently confuses this as operating with NAT44 or without, which is
> totally orthogonal. And no, in my opinion it cannot be left to an
> implementation to decide whether to use this mode or another, as it
> directly leads to the choices of ND_proxy, etc.
> >
> > -Woj.
> >
> >>
> >>
> >> CB
> >>
> >> > - An alternative of the last point could be that the solution focuses
> on
> >> > deployments where the client does not require to be informed of the
> public
> >> > IPv4 address, and that default values are assumed.
> >> >
> >> > 2. Section 8.2.2
> >> > - It would help recasting this section as the "routed" clat mode. I.e
> the
> >> > clat is delegated a prefix for NAT64 usage, with this prefix being
> routed i)
> >> > by the clat device towards the upstream device ii) routed by and not
> seen as
> >> > directly connected by the upstream device.
> >> > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this
> should
> >> > be that NAT44 is used to map several IPv4s to one external IPv4.
> >> > - The figure reflects none of that; it shows 1:1 mapping between IPv4
> and
> >> > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably
> is the
> >> > role of NAT44.
> >> > - It is not stated/specified what the external IPv4 address should
> be, or
> >> > how it is acquired/picked. This should be defined.
> >> > - What is currently also missing from this section is how the clat
> should
> >> > determine that it is to work in "routed" or "host" mode (section
> 8.3.2). It
> >> > is perfectly legitimate to have a PD and not use it for clat.
> >> >
> >> > 3. Section 8.3.2
> >> > - This section should be recast as xlat (clat) host mode for which the
> >> > upstream node considers the clat and the upstream device share an
> "on-link"
> >> > prefix.
> >> > - The ND-proxy appears NOT to be required on 3gpp, so it may be
> worthwhile
> >> > clarifying that.
> >> > - Personally I think that adding ND-proxy is undesirable (as also
> stated by
> >> > others) and harmful (eg for upstream devices such as BNGs). Devices
> on non
> >> > 3gpp network should be directed to use the mode in section 8.3.2,
> which
> >> > would eliminate the need to mention proxy-ND at all.
> >> >
> >> > Regards,
> >> > Woj.
> >> >
> >> >
> >> >
> >> >
> >> > On 2 September 2012 19:09, joel jaeggli <[e-mail]> wrote:
> >> >>
> >> >> Reminder, this WGLC runs through the 5th of September.
> >> >>
> >> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
> >> >>>
> >> >>> This is to open a two week Working Group last Call on
> >> >>>
> >> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
> >> >>>    "464XLAT: Combination of Stateful and Stateless Translation",
> Masataka
> >> >>>    Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
> >> >>>
> >> >>> Please read it now. We are interested in, among other things,
> technical
> >> >>> commentary on the draft and the working group's perception on its
> usefulness
> >> >>> to its target audience.
> >> >>> _______________________________________________
> >> >>> v6ops mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> >>>
> >> >>
> >> >> _______________________________________________
> >> >> v6ops mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/v6ops
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > v6ops mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/v6ops
> >> >
> >
> >
>
>