[Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

Owen DeLong owen at delong.com
Thu Apr 29 15:29:53 UTC 2010


On Apr 29, 2010, at 4:26 AM, Mark Smith wrote:

> On Mon, 26 Apr 2010 07:46:04 -0700
> Jim Burwell <jimb at jsbc.cc> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> On 4/26/2010 03:36, Mikael Abrahamsson wrote:
>>> On Sun, 25 Apr 2010, Owen DeLong wrote:
>>> 
>>>> I fail to see how link local is any more difficult than any
>>>> other IPv6 address.
>>> 
>>> They're different because you have to know your local network
>>> interface name as well.
>>> 
>>>> Windows might get interesting as windows interface naming is,
>>>> uh, creative at best.
>>> 
>>> Exactly.
>>> 
>> Installation software could make this easy.  It could either prompt
>> the user to type in the address on a sticker then enumerate all
>> interfaces on the system and attempt to contact the router on each NIC.
>> 
>> Another possibility is that it could enumerate all the interfaces,
>> then use the IPv6 link-local scope all routers multicast (ff02::2) to
>> enumerate a list of routers found on each link, sort them and/or
>> filter them by ethernet OUI, and present a list of choices for the
>> user to click on to configure the router.  The user could also easily
>> match the enet address on a little slip of paper or sticker on the
>> router to this list, or through some initial settings on the router
>> which allow info to be pulled from it somehow, present a list of
>> unconfigured routers, etc, etc.
>> 
>> Point is, I can imagine a lot of ways this could be made user-proof
>> via software/firmware combination that requires no advanced networking
>> knowledge.
>> 
> 
> It's called multicast DNS. It's easier for that to deal just with
> vanilla IPv6 addresses (i.e. via application calls to getaddrinfo()),
> rather than IPv6 LL addrs + interface names.
> 
Actually, mDNS will handle IPv6 LL just fine.  The interface name is
automatically provided along with the scope in the return values from
getaddrinfo():

struct addrinfo {
             int ai_flags;           /* input flags */
             int ai_family;          /* protocol family for socket */
             int ai_socktype;        /* socket type */
             int ai_protocol;        /* protocol for socket */
             socklen_t ai_addrlen;   /* length of socket-address */
             struct sockaddr *ai_addr; /* socket-address for socket */
             char *ai_canonname;     /* canonical name for service location */
             struct addrinfo *ai_next; /* pointer to next in list */
};

struct sockaddr is an abstraction to an address-family specific structure.
The IPv6 structure (sockaddr_in6) is as follows:

struct sockaddr_in6 {
        __uint8_t       sin6_len;       /* length of this struct(sa_family_t)*/
        sa_family_t     sin6_family;    /* AF_INET6 (sa_family_t) */
        in_port_t       sin6_port;      /* Transport layer port # (in_port_t)*/
        __uint32_t      sin6_flowinfo;  /* IP6 flow information */
        struct in6_addr sin6_addr;      /* IP6 address */
        __uint32_t      sin6_scope_id;  /* scope zone index */
};


Note that the sockaddr_in6 structure will contain an in6_addr structure
and a sin6_scope_id (which specifies the scope of the address and
should, according to RFC 4007 contain enough information to identify
the zone (interface) as well).

Thus you should be able to pass the return value of getaddrinfo()
with an mDNS result containing a link local address to connect()
and expect it to work just fine.

Owen





More information about the NANOG mailing list