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

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

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