On 17-Feb-25 13:29, Tero Kivinen wrote:
Brian E Carpenter writes:
For example, a typical home router may today be configured via "192.168.178.1" but not via "fe80::1%eth0"
which only makes sense by using an RFC 1918 address, so I think
we have no choice. We could use 10.1.1.1, which is a bit more
obvious.
Why would only RFC1918 addresses make sense there? I have seen home
routers using non RFC1918 addresses too, and they might even take
IP-address from local DHCP server and use that.
Changing text to use IPv4 addresses reserved for examples would be
best.
Tero, I have difficulty with this. We use the word "typical" for
a good reason - in our experience of such devices, RFC 1918 is
absolutely typical. The reason for defining global addresses
for documentation was to avoid accidental use of genuine global
addresses, but that problem doesn't apply here and something
like 192.0.2.1 would definitely not be typical.
Of course we (the authors) will do whatever seems to be the
rough consensus on this. (RFC 3849 is Informational, so there
is no absolute rule here.)
Security considerations do list typical issues but one of the issues
with zone identifiers is that the set of characters it can use is
not defined, thus web-form, etc might have difficulties to remove
unsafe characters. For example entering zone identifiers of
"fe80::1%`echo string > /etc/config`" might allow users to cause
unauthorized changes to the system without proper authentication.
On the other hand just automatically limiting zone identifiers
to ascii letters and numbers does not work, as they may contain
some special characters like "." or "-".
That's true, and in any case RFC 4007 does not restrict the character
set in any way, so if we add any restriction here it might break
some existing implementations. I'm not sure that there is anything
useful we can write here. Do you have any suggestions?
I was thinking saying that as RFC 4007 does not restrict the character
set in any way, each implementation processing zone identifiers needs
to make checks appropriate for the environment it is used in. Doing
too strict checks may make it impossible to type some zone
identifiers, making too loose checks might cause issues when unquated
special characters are passed forward.
I.e., not adding any restrictions, just add warning, that
implementations need to understand this.
OK, that makes sense. We can add something along those lines. (The
telechat date is in April, so we will wait a while before posting
a new version.)
The ASCII NUL character might not be the only one that needs special
processing...
Right, it's just the most obvious trap.
Thanks
Brian
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
