Re: Globally Unique Link Local Addresses (Re: about violation of standards)

[神明達哉 <[e-mail]>]

At Wed, 24 Apr 2019 20:29:57 +1000,
Mark Smith <[e-mail]> wrote:

> > getaddrinfo() does in most implementations as it returns a pointer to a
> > struct sockaddr_in6 which have a sin6_scope_id field.  inet_pton() deals
> > with the part to the left of the % symbol.
>
> I was more thinking about scenarios where only an address is expected to
be
> supplied, so there would not be a need for a DNS look up.
>
> So it wouldn't and didn't occur to me to use getaddrinfo() just for the
> purpose of converting an LL address % string into a sockaddr_in6
structure.

Today's applications use getaddrinfo() primarily to be protocol
independent (and to support both IPv6 and IPv4 as a result), not
necessarily for scenarios involving name-to-address resolution, let
alone specifically for converting LL addresses with the % notation:
apps don't have to use protocol-dependent code logic whether it's
invoked as "ssh 192.0.2.1" or "ssh 2001:db8::1".  And for this primary
reason the use of getaddrinfo() is very common.

The better support for scoped addresses is just a bonus effect of it,
but thanks to the common adoption most modern applications can
understand the % notation without doing anything special for
link-local addresses within their application code.

That's the whole point of this topic.  Recall the original context:

> At Wed, 24 Apr 2019 13:28:48 +1000,
> Mark Smith <[e-mail]> wrote:

> > However, the drawback of using LL addresses is that each application
> > has to be written to specifically handle them via sin6_scope_id.
>
> This is not entirely accurate.  Section 11 of RFC 4007 exists exactly
> for this purpose.

the point is that "each application has to be written to specifically
handle them via sin6_scope_id" is not correct for most modern
applications.  I don't deny there are still exceptions, but they are
exceptions, and would be weak to be used as a rationale to introduce
something new.

--
JINMEI, Tatuya