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

On Apr 30, 2014 4:24 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
>
> On Apr 30, 2014, at 3:56 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> > On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) <fred@cisco.com>
wrote:
> > >    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?
> >
> > 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 perpass@ietf.org) 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.
>

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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>