[v6ops] Thoughts on draft-byrne-v6ops-clatip-01

["Fred Baker (fred)" <[e-mail]>]

>    DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the B4
>    element.  This memo generalizes that reservation to include other
>    cases where a non-routed IPv4 interface must be numbered in an IPv6
>    transition solution.

idnits whines about “[RFC6333]”, preferring “RFC 6333”.


> 1  Introduction
> 
>    DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the B4
>    element.  This memo generalizes that IANA reservation to include
>    other cases where a non-routed IPv4 interface must be numbered in an
>    IPv6 transition solutions.  IANA shall list 192.0.0.0/29 to be
>    reserved for IPv6 Transitional Technology IPv4 Prefix.  The result is

^reserved as an^?

>    that 192.0.0.0/29 may be used in any system that requires IPv4
>    addresses for backward compatibility with IPv4 communications, but
>    does not emit IPv4 packets "on the wire".
> 
> 2  The Case of 464XLAT
> 
>    464XLAT [RFC6877] describes an architecture for providing IPv4
>    communication over an IPv6-only access network.  One of the methods
>    described in [RFC6877] is for the client side translator (CLAT) to be
>    embedded in the host, such as a smartphone.  In this scenario, the
>    host must have an IPv4 address configured to present to the network
>    stack and for applications to bind sockets.
> 
> 3.  Choosing 192.0.0.0/29
> 
>    To avoid conflicts with any other network that may communicate with
>    the CLAT, a locally unique address must be assigned.

Dumb question. Is there a reason to not use 169.254.0.0/16? I don’t suppose you have a MAC address, but if you can pick a number in 0..31, I should think you could pick a number in 0..65535, and you might even have a source for it.

>    IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333],
>    which is dedicated for DS-lite.  As defined in [RFC6333], this subnet
>    is only present between the B4 and the AFTR and never emits packets
>    from this prefix "on the wire".  464XLAT has the same need for a non-
>    routed IPv4 prefix.  It is most prudent and effective to generalize
>    192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6
>    transition technologies rather than reserving a prefix for every
>    possible solution.
> 
> 4  Security Considerations
> 
>    No new security considerations beyond what is described [RFC6333] and
>    [RFC6877].
> 
> 
> 5  IANA Considerations
> 
>    IANA is directed to generalize the reservation of 192.0.0.0/29 from
>    DS-lite to "IPv6 Transitional Technology IPv4 Prefix".
> 
> 
> 6  References
> 
>  
> 
> 
> Byrne                     Expires July 1, 2014                  [Page 3]
> INTERNET DRAFT          Transitional IPv4 Prefix       December 28, 2013
> 
> 
> 6.1  Normative References
> 
>    [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
>               Stack Lite Broadband Deployments Following IPv4
>               Exhaustion", RFC6333, August 2011.
> 
>    [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
>               Combination of Stateful and Stateless Translation",
>               RFC6877, April 2013.