Re: WG Last Call for for draft-ietf-6man-rfc6874bis

[David Farmer <[e-mail]>]

On Sat, Jun 18, 2022 at 17:16 Brian E Carpenter <[e-mail]>
wrote:

> 1) While this is an interesting issue, I'm not convinced by David's
> suggestion to add it here as an appendix. I fear that it would distract as
> much as it would help.


I’ll buy that, but;

2) For older home routers, the installation instructions told me something
> like "type 10.1.1.1 into your browser" (I'm looking at the instructions for
> a D-Link purchased in 2007). But my current  home router simply provides
> "fritz.box" in local DNS. For IPv4, that resolves to 192.168.178.1. But for
> IPv6, it resolves to a ULA and a GUA with pseudorandom IIDs. Problem
> solved. (It does have an LLA too, of course, also with a pseudorandom IID.)
>
> This is a case where IPv6 is clearly safer than IPv4. You can find a home
> router's IPv4 address in public documentation or by a very short search.
> You can find its IPv6 address by searching a space of size 2^64.


Then back to my question, if we have to use IPv4 to bootstrap the router,
aren’t you basically admitting at least use case #2 is bogus, if not the
other two as well?

How do we convince the browser community to take this seriously? Why should
they bother, because we say so?

I also don’t buy Ted’s argument about typing IPv6 LLAs in, people type in
MAC addresses every day, in support tickets, self-service MAC address
registration tools, like to register their cable modem, in DHCP
configurations, etc… Yes, we cut & paste them when we can, but that isn't
always practical.

Further, I'll bet those same D-Link instructions tells you what a MAC
address is, and where to find it on the label in case you need to tell your
provider about it, And, I'm pretty sure there is an option for MAC
spoofing, so you can type in the MAC address of your old router into the
D-Link, in case that is easier than registering a new one with your provider

An IPv6 LLA is only slightly more complicated than a MAC address,
especially if you use a EUI-64 LLA. Yes, [RFC8064] recommends not using
EUI-64s, but to quote [RFC2119];

The phrase "NOT RECOMMENDED" mean that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or even
useful.


I’m just saying, it might be useful to put in a document, this is one case
where a EUI-64 LLA could be useful and why.

As for MDNS, I'm all for it, but where is the document for browsers to
support that option? And again, why would browsers ever support Zone ID in
IPv6 literals, if MDNS works so much better?

Anyway, I think the document's rationale for this work needs to be
stronger, and not so easy to poke holes into it. I was only providing my
suggestion for improvement, if you have better ideas go with those.

Thanks