I was happy to see this draft, as I've been struggling to understand
how applications will work in the presence of limited scope addresses.
I've got a few questions and comments regarding the draft. Some of
these may be more appropriate for the Scoped Address Architecture draft,
especially in the areas surrounding DNS behavior (some of which has
already been discussed on the mailing list).
Note that most of my confusion surrounds hosts connecting to more than
one site-local zone. If this support was omitted from this and the Scoped
Address Architecture draft, then many of my questions below would
disappear.
- I don't see versions of inet_ntop() and inet_pton() which support the
proposed address format for limited scope addresses. I would have
thought both would be needed. Or are these APIs being deprecated in
favor of using getaddrinfo() and getnameinfo() to perform this
mapping (both for unicast and multicast addresses)? Either way, I
think it would be good to address this within this draft.
- I would like to see new APIs to map between a zone index and zone name
provided, similar to the if_nametoindex() and if_indextoname() calls.
At a minimum, these will be needed for the updated resolver APIs,
which becomes important given many platforms port their resolver from
the BIND distribution.
- getaddrinfo()
- What value should sin6_scope_id be set to for limited scope
addresses, such as a site-local address? Should it be the scope
index for the given zone into which the query is sent? If so, does
a resolver need to send the same query into each zone to which it is
attached? I find the whole interaction between the resolver, DNS
name server, and limited scope addresses is extremely confusing.
- If the host name includes a scope ID, should this restrict the zones
into which the DNS query is sent? I would assume so, but have
questions based on the next bullet.
- If the host name includes a scope ID, but the scope ID is not valid
at the invoking host, what should be done? Should the query fail?
Or should the scope ID be included on the limited scope addresses
returned?
- If the host name includes a scope ID, but the scope ID is not valid
for all the limited scope addresses which need to be returned, what
should be done? For instance, if a local hosts file includes both
link-local and site-local addresses, but the scope ID is only valid
for the site-local addresses, what should occur? Should the call
fail, or should only the site-local addresses be returned?
- getnameinfo()
- If NI_NUMERICSCOPE is not specified and the scope identifier cannot
be mapped to a scope zone name, what should this API do? Should the
call fail, or should it return the numeric form of the scope
identifier?
- What should be done if a nonzero scope identifier is included with
a global IPv6 address? Should the call fail, or should it return
the numeric form of the scope identifier?
- If a nonzero scope zone index is included, should it be used to
restrict the zone into which the DNS query is sent? For instance,
if the address is of site-local scope, should the query only be sent
into the zone which is identified by the scope ID? Or should the
resolver send the query into (any? all?) zones?
- For a limited scope address with a zero scope zone index, into which
zones should the resolver send the query? Should it send it into
the "default" zone, any zone, or send the query into zones? Since
the host would send a packet using this address/zone index pair
into the "default" zone, it might make sense for the resolver to
do the same.
- The discussions from the Scoped Address Architecture draft on when
to include the scope ID in textual formats should probably be moved
into this draft. For instance, the Scoped Address Architecture
draft talks about omitting the zone ID for the default zone on
textual displays.
Roy
