RE: Accurate history [Re: "professional" in an IETF context]

[Vasilenko Eduard <[e-mail]>]

RFC7136 section 5: "In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values."
Sorry, It is not an Architecture, if half of the bits of IPv6 address is left for "whatever you want".
Effectively, the second half of the IPv6 address is metadata that is mandatory to process by all intermediate nodes
even if it is not used
because it is a part of the basic header.
Ed/
-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Monday, November 8, 2021 12:22 AM
To: Vasilenko Eduard <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: IETF <[e-mail]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

On 08-Nov-21 00:00, Vasilenko Eduard wrote:
> If it is the best practice to disable "temporary addresses" (because 
> it is fake privacy anyway)

I didn't say it was best practice. I expect it to be a common practice in enterprise networks, but the reason it's the recommended default for operating systems is so that individuals will benefit from the small amount of privacy it offers.

> Then what is the purpose of waisting (2^64-1)/2^64 of IPv6 addresses space?

We've debated this so often; I can only suggest reading RFC7136 and RFC7421 again, and the whole debate around the abandoned draft-ietf-6man-rfc4291bis. There is no consensus in the IETF for changing the /64 boundary.

> The next reason could be to greatly simplify Address Resolution Protocol (some link parameters still make sense to broadcast).
> 
> Or else, we have to accept that half of the address bits are just the garbage that every node needs to store and process.
> Except for a few bits that are needed on many subnets anyway to organize local connectivity.
> 
> About ARP storm:
> ND has much bigger DoS capabilities because
ARP storms were not DOS attacks; they were bugs built into combining certain IPv4 implementations with spanning tree bridges.

> - 2^64 subnet permits to push the router to find all 2^64 addresses, 
> it could be done even from outside of the subnet
> - temporarily addresses 10x increase the load on the protocol and the 
> same on the log and correlation engine (for LI, forensic, and troubleshooting) It is famous how WiFi degrades on any physical IETFevent because of the huge number of multicasts per second.

Sure. Building a single /64 that big is a very debatable design choice. The principle fix for ARP storms (and other forms of broadcast storms in IPv4) was subnetting. The same should apply to IPv6 network design.

> All of these multicasts would not be needed if MAC would be inside every IPv6 address as it was intended initially.
> It is the best use for these 64bits.

It's said that to make any Internet problem harder, just say "multicast". And it's true. But the real culprit here isn't "multicast", it's "scaling". Subnetting is the right answer and there is no shortage of /64s in the universe.

     Brian

> 
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Friday, November 5, 2021 11:13 PM
> To: Stewart Bryant <[e-mail]>; Vasilenko Eduard 
> <[e-mail]>
> Cc: IETF <[e-mail]>
> Subject: Re: Accurate history [Re: "professional" in an IETF context]
> 
> On 06-Nov-21 01:09, Stewart Bryant wrote:
>>
>>
>>> On 5 Nov 2021, at 11:10, Vasilenko Eduard <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>> What is important: Enterprises have no clear sign of IPv6 adoption.
>>> ND protocol has a heavy influence on this.
>>> Of course, ND is not the only reason. But maybe the biggest one.
>>
>> Indeed, and I have had a consistent complaint from a British security conscious large private sector technology savvy company, that IPv6 is so much harder to secure than IPv4 they have no interest in moving. I think that part of this is the conflict between the privacy that IPv6 offers and their need to know that *every* packet on their network is entitled to be there doing what it is doing.
> 
> 
> You can administratively disable "privacy" (temporary) addresses, but most sites find it safer to perform access control based on MAC addresses. Temporary addresses are intended to confuse the outside world, not the local network operator. They are *intended* to make lawful intercept harder. That's a feature, not a bug. I agree that they also make debugging harder, which may be another reason to disable them.
> 
> Complaining about ND seems odd if sites tolerate ARP. Anybody else remember ARP storms? ND was designed to avoid that risk.
> 
> All these are FUD arguments used in support of operational inertia.
> 
>       Brian
>