Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

[Rémi Després <[e-mail]>]

Hi Joel,

Thanks for your comments.
More below.

Le 2012-02-19 à 17:37, Joel jaeggli a écrit :

> So, when I read  464xlat what I see is a stack of existing RFCs used in
> a specific fashion which the draft describes. I don't see any new
> standards work.

As answered to Cameron, the fact is that there are some new specification pieces, with SHOULDs and MAYs, e.g.:
"In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive translation traffic. Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP so that no other nodes on the /64 may use the lowest /96." 

> There is comentary on the v6ops list from the map-t about deriving the
> prefix of the core nat-64 translator in a consistent fashion across
> draft, there is perhaps work to be done there though it is likely that
> behave is the place for that, e.g.
> (http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05)
> 
> On 2/19/12 06:29 , Rémi Després wrote:
> 
> <snip>
> 
>> (4) Softwire's charter has "Developments for stateless legacy IPv4
>> carried over IPv6". 464XLAT introduces in user devices a  new
>> stateless behavior, but one that is based on private IPv4 addresses
>> like DS-lite, and one that uses IPv4 packet formats like those of
>> MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues
>> to be the right WG to pursue this work.
> 
> softwires charter also says:
> 
>  IPv4/IPv6 translation mechanisms, new addressing schemes, and block
>  address assignments are out of scope
> 
> which ought to rule out pretty much anything that has employs an rfc
> 6146 translator.

Well, there is indeed ambiguity here because it also says:
"- develop a solution motivation document to be published as an RFC 
- develop a protocol specification response to the solution motivation document".
The MAP-T proposed solution is based on double RFC6145 translation, and 4rd-U uses some pieces that are specified only in RFC6145. 


>> To conclude, a rectification of the situation would be to: - cancel
>> the ietf-v6ops-464xlat draft - continue to work on the Softwire
>> 464XLAT, in relationship with other stateless user-device solutions
>> (hopefully with an updated draft version reflecting recent additions
>> made in the v6ops draft)
> 
> I'm not particularly wedded to the idea of it being in v6ops. I am
> interested in seeing it get a fair hearing,

I share this interest in fair hearing.
Actually, that's why what it specifies should better be discussed where there is current work on stateless CPEs (hosts and/or routers) that do IPv4 via IPv6, i.e. in Softwire.
  
> the lack of novelty has some
> relevance in an operational context.

I do share the view that using existing specifications to avoid reinventing the wheel is always good, but the fact is that there is some novelty in the 464XLAT specification.

Regards,
RD