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

[Wojciech Dec <[e-mail]>]

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.

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