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

[Wojciech Dec <[e-mail]>]

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.



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



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