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

[Maoke <[e-mail]>]

hi Woj,

+1 on your comment 1.
2012/9/6 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.
>

i am not sure but have another observation: 464xlat, using existing
mechanism of RFC6145/6146 and address format of RFC6052, is used in within
the same address planning autonomous system with the same prefix for the
RFC6052 usage; while MAP can work in a "MAP domain" across over different
prefixes even belonging to different autonomous systems with the cost of
distributing rules among involved nodes.

- maoke


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