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

[Mark Smith <[e-mail]>]

On Thu, 25 Apr 2019 at 06:08, 神明達哉 <[e-mail]> wrote:
>
> 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.
>

So perhaps there could be an update to RFC 3493.

It seems that inet_pton() and inet_ntop() should be now considered
more internal, "under the hood/bonnet" functions, rather than things
you might use to convert user input, and getaddrinfo() is now more
general purpose rather than something you use only when you need name
resolution/DNS lookup to be performed.

Regards,
Mark.

<snip>