[IPv6]Re: Analysis of Ungleich ULA Registry

[Kyle Rose <[e-mail]>]

On Thu, May 23, 2024 at 4:42 PM Brian E Carpenter <
[e-mail]> wrote:

> On 23-May-24 15:25, Lorenzo Colitti wrote:
> > On Thu, May 23, 2024 at 11:36 AM Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Right. If I want to use fd00:bec0::/32 (BEC being my initials), I
> certainly can, and it will disturb nobody.
> >
> >
> > I believe Jen presented some data a few years ago on what prefixes are
> in use, based on backscatter. I don't have the link right now, but I
> remember that what emerged from the data is that people did not commonly
> use their initials. They commonly used fd00:: or fd01::. In other words,
> the chance of collision for human-picked ULA prefixes is very much larger
> than for randomly-assigned prefixes.
> >
> > To use your words... will it "disturb" anyone to pick fd00::? I don't
> know. Networks that picked fd00:: will be disturbed if they ever
> interconnect with other networks that picked fd00::. Do you thik they are
> more likely to try to fix this using renumbering, or via NAT or NPTv6? I'd
> say the latter. If they do that, they will disturb application developers
> and users.
> >
> > Is it "foolish" to pick fd00::? Well, I would say yes. But the people
> who picked it didn't think it was. Or maybe they just didn't know.
> >
> > I don't have an issue when people make unwise or broken deployment
> choices. I just don't like it when people make unwise or broken deployment
> choices, and app developers and users end up paying the price. That's not
> fair.
>
> I completely agree.
>

For the record, so do I; but there's only so much we in the standards
community can do. You can lead a horse to water, yadda yadda yadda. If
someone is intent on violating the spec when it *very clearly indicates*
why something should be done in a particular way, I don't see how there's
anything further we can do to prevent that bad outcome. Thankfully, in this
case the stakes are simply lower because it doesn't have global effect
unlike, say, greedy congestion control algorithms.

Kyle