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

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 30 Apr 2014 22:48:54 +0000

>    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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 May 2014 07:56:57 +0900

On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) <[email-masked]> wrote:

> Dumb question. Is there a reason to not use 169.254.0.0/16?
>

Yes. 169.254.0.0/16 is link-local, which implies no off-link connectivity
and no Internet connectivity. If your only IPv4 address is in that range,
applications might well assume that there is no off-link connectivity.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 30 Apr 2014 23:24:38 +0000

On Apr 30, 2014, at 3:56 PM, Lorenzo Colitti <[email-masked]> wrote:

> Yes. 169.254.0.0/16 is link-local, which implies no off-link connectivity and no Internet connectivity. If your only IPv4 address is in that range, applications might well assume that there is no off-link connectivity.

Ask me someday what thoughts go through my mind about applications making inferences from network layer addresses. Hey, 192.168.0.0/16 is for networks that don’t connect to the Internet. You want proof? From RFC 1918, the motivation is

   With the proliferation of TCP/IP technology worldwide, including
   outside the Internet itself, an increasing number of non-connected
   enterprises use this technology and its addressing capabilities for
   sole intra-enterprise communications, without any intention to ever
   directly connect to other enterprises or the Internet itself.

And, in the past two weeks, I have received 471 emails (this particular one on [email-masked]) that contain lines like

Received: from <name> ([169.254.2.21]) by
 <name>  ([169.254.2.21]) with mapi id
 15.00.0929.001; Wed, 30 Apr 2014 19:08:41 +0000

But anyway...

and 192.0.0.0/29 is...?

I’m not sure I’m up to rocking boats here. It just seems like they have equivalent characteristics. Before we ship the document somewhere, it seems like a reasonable question.

---

From: "TheIpv6guy ." <[email-masked]>
Date: Wed, 30 Apr 2014 17:02:12 -0700

On Apr 30, 2014 4:24 PM, "Fred Baker (fred)" <[email-masked]> wrote:
> > Yes. 169.254.0.0/16 is link-local, which implies no off-link
connectivity and no Internet connectivity. If your only IPv4 address is in
that range, applications might well assume that there is no off-link
connectivity.
>
> Ask me someday what thoughts go through my mind about applications making
inferences from network layer addresses. Hey, 192.168.0.0/16 is for
networks that don’t connect to the Internet. You want proof? From RFC 1918,
the motivation is
> And, in the past two weeks, I have received 471 emails (this particular
one on [email-masked]) that contain lines like
> I’m not sure I’m up to rocking boats here. It just seems like they have
equivalent characteristics. Before we ship the document somewhere, it seems
like a reasonable question.

It is a reasonable question.

https://tools.ietf.org/html/rfc3927#section-2.6

There is defined the limitations of the ipv4 link local addresses. This
includes that the addresses may not be forwarded and all offlink
communication requires an ARP.

In practice, neither of these MUSTs can be implemented since the CLAT
generally must "forward" this packet to an rfc6145 function using a
"default route" , within a host.  Also, as Lorenzo noted, applications may
gleen "no connectivity" from the 169.254 address

192.0.0.0/29 is a globally routable address it works well here, this is
know in production (7 million nodes deployed as such in my network).

I believe it is more natural to generalize the use of 192.0.0.0/29 as
defined in rfc6333 rather than cause a conflict / violation  to rfc3927.

At the end of the day, this draft is simply stating that the b4 ipv4
function defined in rfc6333 has utility beyond ds-lite, and therefore the
usage of the address should be generalized.

CB

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 May 2014 11:55:06 +0900

On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) <[email-masked]> wrote:

> inferences from network layer addresses.
>

The wording in RFC 3927 is much stronger. For example, it states multiple
times that packets sourced from 169.254/16 MUST NOT be forwarded, and that
they MUST NOT ever be sent to any router for forwarding. I think it's
perfectly reasonable for an app (or even an OS!) to assume that such
addresses have no connectivity.

> Hey, 192.168.0.0/16 is for networks that don’t connect to the Internet.
> You want proof? From RFC 1918, the motivation is
>

Funny, that's what the proponents of ULA-only networks say too - "no, this
network will NEVER connect to the Internet, ever!!11" I suspect they do so
because they know that saying "we want to use NAT to connect this network
to the Internet like we do in IPv4" is going to result in strong opinions
and removal of support for the use case. But that's off-topic here.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 30 Apr 2014 22:30:34 -0700

On 4/30/14, 7:55 PM, Lorenzo Colitti wrote:
> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Ask me someday what thoughts go through my mind about applications
>     making inferences from network layer addresses.
> 
> 
> The wording in RFC 3927 is much stronger. For example, it states
> multiple times that packets sourced from 169.254/16 MUST NOT be
> forwarded, and that they MUST NOT ever be sent to any router for
> forwarding. I think it's perfectly reasonable for an app (or even an
> OS!) to assume that such addresses have no connectivity.
>  
> 
>     Hey, 192.168.0.0/16 <http://192.168.0.0/16>is for networks that
>     don’t connect to the Internet. You want proof? From RFC 1918, the
>     motivation is
> 
> Funny, that's what the proponents of ULA-only networks say too - "no,
> this network will NEVER connect to the Internet, ever!!11" I suspect
> they do so because they know that saying "we want to use NAT to connect
> this network to the Internet like we do in IPv4" is going to result in
> strong opinions and removal of support for the use case. But that's
> off-topic here.

site-local unicast in ipv6  and rfc 1918 are relatively contemporaneous
ideas...

I don't thing the pressures that produce such solutions are particularly
new in fact it's pretty easy to assert that they co-evolved.