hi, Ray,

Good to see a synthetic comment on the draft.
more comments inline.

2012-09-05 07:24, Ray Hunter :

> I have read this draft and lurked the on-list discussion.
> 
> Comments based on version 07 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07
> 
> Following all IMVVHO [I'm no XLAT expert]
> 
> 1) The need for 464XLAT is clear.

Agreed.

> 2) The basic 464xlat architecture is sound and certainly worthy of advancement and further refinement.
> The authors have done a great job on what is a very tricky problem.

Same view.

> 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons:
> Firstly ND Proxy is an experimental protocol, whereas the draft is aiming to become BCP.

+1

> Secondly, ND Proxy has inadequate loop detection, prevention and mitigation, for it to be reliably deployed in tethered networks consisting of multiple devices.  If 464XLAT is going to be effective, it will need to be incorporated into CPE devices. Section 4.1.3.3 of 4389 is a potential source of oscillation, instability, unpredictable behaviour, and provides a DoS vector, if 464XLAT were to be widely incorporated into consumer devices. [Authors claim multiple device working is out of scope, but this situation will likely happen in home use) ]
> 
> 4) Section 8.3.2 does not adequately deprecate single /64 working, which I consider harmful (as per BCP157).

- I see no reason why, if technically feasible (as is the case AFAIK), a node being delegated a /64 would be forbidden to use it on an IPv6 link, and simultaneously for private IPv4 using 464XLAT.

- BCP157 ?

> 5) Assignment of a single special-purpose IANA IID is problematic for 2 reasons.
> 
> I don't consider the document complies with the spirit of justifying the Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in that the argumentation for assignment is very opaque, and the use-case is not completely defined e.g. the IID SHOULD NOT be used for L2 addressing by the CLAT.

Pros and cons of CLAT reserved IID can be clarified as much as needed for experts to base their conclusions.

Actually, extending reservation to one IID range per RFC1918 private-IPv4 prefix permits a very substantial simplification of the draft. With it, the original spirit of a trivial combination of a stateless RFC 6145 in CLATs and stateful RFC 6146 in PLATs can be restored by: 
- suppressing the need for a variant with 464XLAT-specific IPv6 prefix, and one without
- suppressing the need for one variant without NAT44 and one with NAT44
- permitting safe operation in CLAT nodes that are delegated /64s 

Here is an example of what the simplified draft might look like if the approach is accepted. 

> There is no detection or protection for cascaded CLATs, where if the IPv6 address is assigned using the Modified EUI-64 identifier to a downstream CLAT, this will clash with the upstream CLAT if it has also used the Modified EUI-64 identifier to create its IPv6 address. Avoiding duplicate addresses was the base justification for assigning the Modified EUI-64 identifier. [The authors say this configuration is out of scope, but this situation will likely happen in home use.]

Authors aren't alone to note that CLATs won't be cascaded.:
- CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream (=> not cascadable)
- Trying to cascade would mean adding a PLAT function in a CLAT node, but this requires a public IPv4 range in the CLAT node, which is contrary to 464XLAT assumptions.


> Judging by the existing discussion on the WG, I don't think any of these problems are insoluble.

Agreed, but with apparently a different approach.

Regards,
RD


> 
> regards,
> RayH
> 
> 
> joel jaeggli 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
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops