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

[Maoke <[e-mail]>]

Cameron,
2012/9/6 Cameron Byrne <[e-mail]>

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

And, AFAIK, MAP-T  is not longer an actively pursued solution.  A coin
> was flipped, and the IETF moved on.
>

i agree that 464xlat document doesn't need to compare with any other
solutions. however, i guess you also support Woj's effort of sharing the
understanding. and AFAIK, MAP-T, will be still the softwire WG document
even the status might be experimental. further, in the MAP deployment draft
that i am participating, we are obliged to include the understandings in
order that the operators reading the deployment guidance may get a clear
big picture of the relationship among all the stuffs in the solution space.

i would like to share another point: maybe some people think the about one
year effort of making MAP-T and -E a unified work is vain, maybe some think
we should to do the coin toss one year ago, i don't agree. the effort of
unification made out a common address mapping algorithm and the unified
format, enabling operators change their mode of transport once they
understand somewhere the double translation, compatible with single
translation, is needed in their system architecture.

such an understanding on the necessity of translation, AFAIK, is also
significant to those who would like to deploy 464xlat. ;-)

- maoke


>
> > 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.
>
> > - 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.
>
> 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
> >
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>