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

[Brian E Carpenter <[e-mail]>]

On 04/05/2014 12:47, Mark ZZZ Smith wrote:
> 
> 
> 
> ----- Original Message -----
>> From: Owen DeLong <[e-mail]>
>> To: joel jaeggli <[e-mail]>
>> Cc: V6 Ops List <[e-mail]>; "Byrne, Cameron" <[e-mail]>
>> Sent: Friday, 2 May 2014 8:31 AM
>> Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01
>>
>>
>> On Apr 30, 2014, at 10:30 PM, joel jaeggli <[e-mail]> wrote:
>>
>>>  On 4/30/14, 7:55 PM, Lorenzo Colitti wrote:
>>>>  On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) <[e-mail]
>>>>  <mailto:[e-mail]>> 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. 
> 
> 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.

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