Re: I-D Action: draft-carpenter-6man-lap-00.txt

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

On 19/06/2018 11:07, Mark Smith wrote:
> On Fri, 15 Jun 2018 at 06:21, Fernando Gont <[e-mail]> wrote:
> 
>> On 06/14/2018 10:24 PM, Mark Smith wrote:
>>>     > Nick, while I agree with you, you are basically making Lorenzo's
>>>     point,
>>>     > this just degrades into a rehash of RFC4291-bis.>
>>>     > So, would someone from Lorenzo's camp please propose language that
>>>     > rationalizes RFC6164 with the 64-bit IIDs of RFC4291.
>>>
>>>     Rationale: Folks realized that there are reasons for which you might
>> do
>>>     LAP != 64. -- which is not a surprise, since the rationale for the
>>>     specific "64" value is simply "historical reasons".
>>>
>>>
>>> And proven simplicity, proven by other protocols developed in the 1980s,
>>> and deployed in the 1990s.
>>>
>>> IPv4 was a terrible protocol to understand and deploy compared to IPX
>>> and AppleTalk. They just worked. (My first protocol was IPX, when
>>> leaning IPv4 the fundamental question I wondered was "Why is this so
>>> hard and complicated?" Then I taught it. That took 5 attempts before I
>>> fully felt happy with how I'd taught and explained IPv4 addressing - and
>>> that didn't even cover CIDR.)
>>
>> People usually ask the same question about IPv6. Example: compare ARP +
>> DHCP with ND + combo(SLAAC/DHCPv6)
>>
>>
> No where near as complicated as IPv4 Classful / subnet/ variable length
> subnet / CIDR addressing.
> 
> People could ask the same reason why there are 7 layers in the OSI
> reference model, rather than just one. The answer is the same.
> 
> Besides, you don't *need* to use subnet sizes != 64. If you lie /64,
>> nobody will force you to do something else.
>>
>>
> There's a lot of things we don't need.
> 
> We didn't "need" ARP, we could have manually loaded each host with static
> MAC address to IP address mapping tables.
> 
> We didn't need DHCPv4 or BOOTP/RARP either. All those settings were
> possible to set manually on each host too.
> 
> We don't "need" dishwashers or washing machines, we could have continued to
> manually wash our dishes and clothes.
> 
> Many of our technologies are fundamentally optional, however they make our
> life simpler and cheaper and that is why we design, build and use them.
> 
> In IPv4 we needed variable length edge subnets/prefixes (and Classes and
> all the other things that preceded CIDR) to continue to be able to use IPv4
> within its fundamental constraint of 32 bit addresses. We don't need them
> in IPv6.

Not as far as we know, today, which is why nobody has suggested changing
the default from /64. Not having a very good crystal ball, I don't
know what people might need 50 years from now. 
 
>>> Those 1980s protocols' usability, supportability and deployability
>>> levels are the ones I expect IPv6 to meet and exceed, not IPv4's.
>>
>> With fixed length IID's, host willing to extend the network further and
>> further will be forced to do NAT.
>>
>>
> If any host can't get an IPv6 address from the network (and more than one
> per BCP204), then the IPv6 deployment and IPv6 network is broken,

That isn't something the IETF can control, unfortunately.

> because
> the fundamental reason for IPv6 - many many more addresses than IPv4 -
> isn't being achieved. Continue to use IPv4(+NAT), or give up and tell the
> user the network is broken.
> 
> We need to stop trying to reduce IPv6's functionality to IPv4's 

That's caricaturing the idea of increasing IPv6's flexibility.

> to suit
> those who don't really want to learn to think in IPv6 (by recreating
> address scarcity when it isn't necessary, that is creating artificial
> address scarcity).

If ISPs do that, they'll suffer the consequences.

   Brian