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

[Mark Smith <[e-mail]>]

On Wed., 24 Apr. 2019, 16:04 Mark Andrews, <[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 lookup.

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.

LL addresses not being useful to applications if stored in unicast DNS,
because of the absent necessary zone info in a AAAA response, also means
getaddrinfo() doesn't sound like the right thing to use.



> From various getaddrinfo man pages.
>
> MacOS:
>
>      This implementation of getaddrinfo() allows numeric IPv6 address
> notation
>      with scope identifier, as documented in section 11 of RFC 4007.  By
>      appending the percent character and scope identifier to addresses, one
>      can fill the sin6_scope_id field for addresses.  This would make
> manage-
>      ment of scoped addresses easier and allows cut-and-paste input of
> scoped
>      addresses.
>
>      At this moment the code supports only link-local addresses with the
> for-
>      mat.  The scope identifier is hardcoded to the name of the hardware
>      interface associated with the link (such as ne0).  An example is
>      ``fe80::1%ne0'', which means ``fe80::1 on the link associated with the
>      ne0 interface''.
>
>      The current implementation assumes a one-to-one relationship between
> the
>      interface and link, which is not necessarily true from the
> specification.
>
> Linux:
>      Notes
>
>      getaddrinfo() supports the address%scope-id notation for specifying
> the IPv6
>      scope-ID.
>
>
> Mark
>
> > On 24 Apr 2019, at 3:12 pm, Mark Smith <[e-mail]> wrote:
> >
> >
> >
> > On Wed., 24 Apr. 2019, 14:01 神明達哉, <[e-mail]> wrote:
> > 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 viasin6_scope_id.
> >
> > This is not entirely accurate.  Section 11 of RFC 4007 exists exactly
> > for this purpose.  And, in fact, applications like ssh can perfectly
> > work for a link-local destination even on a multi-link host even if
> > the application (ssh client) doesn't do anything special for
> > link-local address:
> >
> > % ssh fe80::1%lo0 'echo ok'
> > ok
> >
> >
> > So what Sockets API function converts "fe80::1%lo0" into a populated
> sockaddr_in6 structure including sin6_scope_id?
> >
> > inet_pton() only deals with and returns addresses, so it seems you have
> to write additional special case code that handles the % zone suffix.
> >
> >
> > It's true that *some* applications may still need to handle link-local
> > addresses as a special case, though.
> >
> > > I understand that one of the motivations for Link-Local addressing was
> > > the "dentist's office" scenario i.e. non-technical, plug and play, "it
> > > just works" networking. Having to have specially adapted applications
> > > to suit that that scenario is pretty contradictory to that goal.
> >
> > I wouldn't expect a dentist to type in a textual link-local address
> > (or for that matter, perhaps any textual IPv6 address) anyway.
> >
> > So my thoughts have been that things like MDNS would also return the
> zone information for a LL address to the resolver, although I haven't
> looked into whether it does or not.
> >
> > I still see that it would be simpler if interface or zone information
> was effectively embedded in the LL address, as it is in GUA and ULA
> addresses, using the, transparent to the application, node's route table to
> resolve and determine the ingress/egress network link interface.
> >
> >
> >   In
> > this context it's more about a higher level problem than
> > scope-awareness of the application.  It would have to use some kind of
> > zero-config service discovery library with sophisticated user
> > interface.  That "library" may have to be aware of the concept of
> > scoped addresses more explicitly, but the application would be more
> > likely to be agnostic about it.
> >
> > --
> > JINMEI, Tatuya
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
>