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

From: Ross Chandler <[email-masked]>
Date: Thu, 1 May 2014 09:12:33 +0100

On 30 Apr 2014, at 23:48, Fred Baker (fred) <[email-masked]> wrote:
>> 
>> 
>> 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.

Operationally if I saw an address from 169.254.0.0/16 for the clatd I might think it was in a transition state waiting to get another address assigned instead of it.

Ross

---

From: Owen DeLong <[email-masked]>
Date: Thu, 1 May 2014 15:31:40 -0700

On Apr 30, 2014, at 10:30 PM, joel jaeggli <[email-masked]> wrote:

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

Yes, but unlike RFC-1918, we came to our senses and deprecated site-local.

ULA came later as a result of pressure from people who loved their NAT. Sad, really, that the problem was not addressed through education instead of better RIR policies for global unicast.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Thu, 01 May 2014 15:51:40 -0700

> ULA came later as a result of pressure from people who loved their NAT. Sad, really, that the problem was not addressed through education instead of better RIR policies for global unicast.

fec0::/10 was reserved way back in rfc 1884

3879 and 4193 are contemporaneous activities. meany people on this list
were present for them.

The fact that we did a bad job at something 20 years ago doesn't mean
the problem that we were attempting to address went away.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 1 May 2014 20:57:57 -0700

> the problem that we were attempting to address went away.

I agree… People wanting to do NAT rather than learn how to do things better without it is an education problem which continues to persist to this day.

Owen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 3 May 2014 17:47:46 -0700 (PDT)

----- Original Message -----
> From: Owen DeLong <[email-masked]>
> To: joel jaeggli <[email-masked]>
> Cc: V6 Ops List <[email-masked]>; "Byrne, Cameron" <[email-masked]>
> Sent: Friday, 2 May 2014 8:31 AM
> Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01
> 
> 
> ULA came later as a result of pressure from people who loved their NAT. 

That's not correct. As I remember it ULAs were a solution to the drawbacks of site-locals (the discussions of both took topics place in mid to late 2002). Site-locals were deprecated because ULAs had been defined to take their place. The main attribute of ULAs - the random ID component - is there to eliminate the ambiguity that site-locals had, which would have caused people to deploy NAT when interconnecting two different site-local domains. There were other reasons site-locals were deprecated:

Deprecating Site Local Addresses
https://tools.ietf.org/rfc/rfc3879.txt

(which can also be used a good guide to the drawbacks of RFC1918s) 

> Sad, 
> really, that the problem was not addressed through education instead of better 
> RIR policies for global unicast.
> 

I'm pretty sure the people involved in the ULA/site-local discussions well and truly know about global addressing and its benefits and drawbacks. 

Your assertion seems to be that global only addressing would make NAT non-existent and that ULAs will ensure it does. People have chosen to deploy NAT/NAPT in IPv4 networks to attempt to solve more than just the lack of public IPv4 addresses problem. Plentiful and relatively cheap global IPv6 addresses won't address these other needs. Work such as RFC4864 or DHCPv6-PD will.

Regards,
Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 May 2014 13:41:38 +1200

> Your assertion seems to be that global only addressing would make NAT non-existent and that ULAs will ensure it does. People have chosen to deploy NAT/NAPT in IPv4 networks to attempt to solve more…

Actually, one of the use cases for ULAs is to avoid the need for NATs
in the case that two enterprise networks that have insisted on private
addressing merge, or for some other reason need to route directly between
their private address spaces.

Spare me the argument about not needing private addressing at all, because
some enterprise network managers simply want it and aren't interested
in the counter-arguments.

   Brian

---

From: Ca By <[email-masked]>
Date: Sat, 3 May 2014 20:25:40 -0700

Folks,

Feel free to start a new thread to talk about ULA vs the world.  I
don't believe it is relate to draft-byrne-v6ops-clatip-01

Regards,

Cameron

On Sat, May 3, 2014 at 6:41 PM, Brian E Carpenter
<[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Sun, 4 May 2014 01:04:12 -0700

> in the counter-arguments.

Thank you for proving my case that at least to some extent, determined ignorance is a driving factor for ULA.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Sun, 04 May 2014 07:14:29 -0500

I Think we can consider this discussion closed.

discussion of the draft is fine.

the ipv6 addressing architecture is not something we need to re-litigate
to discuss it.

Thanks
joel