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

[Mark Andrews <[e-mail]>]

> On 26 Apr 2019, at 4:20 pm, Mark Smith <[e-mail]> wrote:
> 
> On Fri, 26 Apr 2019 at 07:47, Mark Andrews <[e-mail]> wrote:
>> 
>> Which mythical application only takes IP addresses then connects to them?  I’ve yet to see one written.
>> 
> 
> BGP "application" on a router or a route server for example. Router
> control planes are functionally hosts by RFC 8200, and all of their
> applications e.g. OSPF, BGP processes etc. all deal with raw IP
> addresses, including LLs, most of the time.
> 
> Here's one I wrote. As it is relatively low level, using IP addresses
> explicitly instead of DNS names seemed more suitable. So I wrote
> routines to handle % suffixes in supplied unicast and multicast
> addresses. I would have used getaddrinfo() for that if it had been
> more obvious to do so.
> 
> https://github.com/markzzzsmith/replicast
> 
> 
>> Yes, scoped addresses are a small pain.
>> 
>> Yes, storing scoped addresses in the DNS is not currently supported.  It wouldn’t be that hard to add support with a new type that provided a globally unique name for the link and that name gets locally mapped to a scope id.
>> The A6 record format repurposed would work. Add a RA option to publish the globally unique link name to each link.  Getaddinfo could filter out non local link local addresses.
>> 
> 
> That could work.
> 
>> Getaddrinfo doesn’t just optionally look stuff up in the DNS. It also does transformations like converting to mapped addresses when the node is IPv6 only.  It could potentially apply DNS64 translations as well.
>> 
>> Using getaddrinfo for address literals has been advised for years.
> 
> The trouble is that getaddrinfo() seems to have become more general
> purpose than in the past, where it was specifically for name
> resolution for a long time e.g. per RFC 3493 and how it is presented
> in Unix Network Programming.

Yet, RFC 3493 has these flags for controlling getaddrinfo’s behaviour.

AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.

It was *never* as simple as you make it out to be. It was intended to
replace testing for literal addresses, then performing hostname lookups
and getservbyname lookups, then filling out struct sockaddr structures.
Adding scope handling to this was natural.  Add DNS64 handling would also
be natural.

> I think it would have been more logical to have adapted inet_pton()
> and inet_ntop() to handle % suffixes, understandably not possible
> because they only return binary address representations. Some way of
> embedding a unique link identifier within the IPv6 LL address would
> allow them to be used rather than the less obvious getaddrinfo().


> Regards,
> Mark.
> 
>> --
>> Mark Andrews
>> 
>> On 24 Apr 2019, at 20:29, Mark Smith <[e-mail]> wrote:
>> 
>> 
>> 
>> 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]
>>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]