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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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

<no hats>

For general purpose hosts I agree.  I think the 3GPP/RFC 8273 model has some nice simplicity to offer.  Some of the complexity moves to managing host attachment and migration, but perhaps that's something worthy of further IETF study and development.

>
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@xxxxxxxxx]
> Sent: Friday, November 5, 2021 11:13 PM
> To: Stewart Bryant <stewart.bryant@xxxxxxxxx>; Vasilenko Eduard <vasilenko.eduard@xxxxxxxxxx>
> Cc: IETF <ietf@xxxxxxxx>
> 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 <vasilenko.eduard@xxxxxxxxxx <mailto:vasilenko.eduard@xxxxxxxxxx>> 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
>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux