Subject: Scope ID secret Cabal (minutes)

From: Carl Williams <[email-masked]>
Date: Tue, 30 Nov 1999 00:06:43 -0800 (PST)

Jim Bound asked a number of the ipng wg members 
who have been working on the IPv6 extensions to 
the socket API to meet, discuss and provide feedback
to the ipng working group on the effects of 
the scope id with the existing IPv6 socket API.

Below are the minutes to the meeting. I tried to 
provide some organization to the note taking I did.  
Here is the organization:

- Purpose of meeting
- Who Attended
- APIs that are effected by the scope id issue
- Some raw discussion details of our debate
- Conclusions/recommendations
- Issues the group didn't reach agreement on

We attempted to be complete in identifying all API
issues relating to scope id.  It is the hope 
that by publishing these minutes that they will serve 
to focus debate and discussion on the scope address
issue in order to facilitate a complete solution this
time around.

Carl

Minutes from IETF-DC socket API meeting
---------------------------------------

Purpose of meeting:

Jim Bound asked a number of the ipng wg members 
who are working on implementing the IPv6 extensions to 
the socket API to meet and discuss the problems of 
the scope id with the existing IPv6 socket API.
We were asked to publish to the working group alias 
any recommendations that the group arrived at as well 
as enumerate any additional issues in which no consensus
was reached.

At a minimum the group sought to enumerate all the
issues of scope addresses with the existing IPv6
socket specification and publish them to the ipng
alias.  

Attendees of the Meeting:  

Jack McCann (Compaq), Tim Hartrick (Mentat), Chris
Harding (Open Group), Brian Zill (MSFT), Jun-ichiro
Hagino (KAME project), Tatuya Jinmei (KAME Project),
Carl Williams (Sun), Yanick Pouffary (Compaq), 
Maryann Maher (ISI).

Minutes were sent out to all participants including
Erik Nordmark (Sun) and Jim Bound (Compaq) for
editing purposes.  It shouldn't be assumed that
each participant agrees to all the statements
detailed in the minutes.  The working group
participants were able to reach consensus on some
key items which have been outlined in the "Recommendation" 
section below.

APIs that are effected by the scope id issue
--------------------------------------------

o getipnodebyname(), getipnodebyaddr()
o inet_ntop(), inet_pton()
o INET6_ADDRSTRLEN
o ifindex APIs

getipnodebyname()/getipnodebyaddr()
===================================

The group identified possible options to
dealing with scope addresses and the
getipnodebyname()/getipnodebyaddr() APIs:

(a) Extend the getipnodebyname() interface to
work with scoped addresses.
(b) Standard compile flag fix
(c) Deprecate getipnodebyname()/getipnodebyaddr()
(d) Define function to cut out scope id and pass it
into a yet to be defined function.  The other address
portion would be passed into getipnodebyaddress()
(e) Simply use getaddrinfo()/getnameinfo() as scopes
are transparent to these interfaces.

(a) would break backward compatibility.  A compile
flag was not a realistic option and deprecating
getipnodebyname()/getipnodebyaddr() may have unwanted
psychological consequences on those looking to port
their applications to use the IPv6 socket API.  The 
conclusion the group reached was to adopt (e) and provide 
an applicability statement for the getipnodebyname() and 
getipnodebyaddr() interfaces detailing the circumstances 
of the limitations of these APIs.

Problem with scope information and name-to-address
and address-to-name resolution:

   * Comments made during the meeting *
   
   Resolver should know what scope the host is in so
   DNS knows who to query.  There could be two DNS servers
   to query (in case of host in two sites).  Want to
   look at the scope id to know which one.
   Magic won't be generic to DNS. 
   
   A comment was made that it is conceivable that you can call on 
   both - pass back scope info to state which direction you're going.
   
   *** Get same information if you're feeding into getaddrinfo().
   
   Tim: More than one reason against doing this.  First, you have
   the same exact problem if the host is multihomed.  Link local 
   addresses with this identifier makes getipnodebyname() useless 
   for multihome host.
   
   Brian: Vendors/Implementors have been writing applications with
   getipnodebyname()/getipnodebyaddr() and testing them with 
   global address and then in the field people are using link local
   addresses and things break.
   
   Jun-ichiro: Use site address on wrong link is API or configuration 
   issue.  DNS is only name service that has this problem.  
   
        addr something  scope_id
        
   restrict it to only numeric address.  Does name correspond to address
   and scope.  If name is in both sites, DNS will respond to both
   sites (fec0@japan, feco@usa).
   
   Type in fully-qualified domain name.  If you use scope id, then
   name should contain scope.  Resolver should return addr + scope id.
   Should we allow a scope qualifier on a name?  No, DNS will decide 
   which one you hit based on domain search order.
   
   Jack: Why site specific for numeric and not more?
   
   Jun-ichiro:  System administrator must configure DNS correctly
   so that there is no name collision.  Jun-ichiro proposed the
   following mapping:
   
		<FQDN> -> <numeric addr, scope>

   Jun-ichiro will send out more details (in separate email) to
   the ipng working group alias on a proposal to map between FQDN,
   numeric, and scope.
   
   Brian: Asked whether textual representations of scope ids with 
   addresses should apply only to numeric addresses or nodenames 
   (fully qualified or not).  In other words, would we support 
   "1/deering" and/or "cisco/deering".  (This assumes that we _are_ 
   supporting things like "1/fec0::dead:beef:cafe" and 
   "cisco/fec0::dead:beef:cafe")  The answer (quickly voiced and 
   not challenged) was no, we wouldn't support those.
   A nodename should always map to a scope id and numeric address, 
   so attaching a scope id to a nodename would be ambiguous since 
   you'd have two scope ids then. 
  
   Jack: We have been living in denial regarding scope addresses.
   
   Jim B: Can't break existing binaries.  Can't deprecate getipnodeby*().
   
   Tim:  There is no "water to wine" solution.  Can't fix getipnodeby*()
   in binary compatible way.  We only need one set of interfaces.
   We have those with getaddrinfo()/getnameinfo() which work
   with scope addresses.  Even if getipnodebyname() was extended to work
   with scope addresses, old binaries will still do the old thing.
   
getaddrinfo()
=============

    Should also define the AI_ADDRCONFIG flag with getaddrinfo().  This
    allows applications to weed out addresses that they can't communicate
    with.  There was also a proposal to have getaddrinfo() return mapped 
    addresses.  There were concerns that this would change the basic
    definition of getaddrinfo() in terms of it being protocol-independent.
    
    Since there is little support for fixing getipnodebyname(), it is being
    recommended that the getaddrinfo() flags (ai_flags field of addrinfo
    structure) value also support:
    
    AI_ADDRCONFIG
    AI_DEFAULT
    AI_ALL
    AI_V4MAPPED
    
    The current programming paradigm that is being recommended with
    getaddrinfo() remains intact.  There may be some cases whereby
    being able to toggle getaddrinfo() to return only AF_INET6 with
    mapped addresses may make porting existing applications easier.
     
    This proposal is allowing additional flexibility similar to what
    getipnodebyname() offers. For example, the application can choose
    to have only AF_INET6 addrinfo structures returned by getaddrinfo
    (containing mapped addresses) rather than deal with both AF_INET 
    and AF_INET6 sockets (using pure IPv4 and native IPv6 addresses).

Recommendations
===============

     The participants attending the API meeting reached a consensus
     on the following issues.  We are making these recommendations
     to the ipng working group alias for debate.

     1. It is recommended that we should leave getipnodebyname()/
     getipnodebyaddr() as they are and provide an applicability statement 
     detailing the circumstances of the limitations of these APIs.
     
     It was recommended that the getaddrinfo()/getnameinfo() APIs work
     with scope addresses and as such applications should simply
     use these APIs.
     
     2. Add the AI_ADDRCONFIG flag to getaddrinfo().  There was discussion
     at this meeting of whether this was ok given that POSIX has a copyright
     on this API.  Chris Harding explained that we could change this API.
     Currently, the XNET is being merged into the Austin group.  
     
     Chris states that as far as XNS and POSIX are concerned, we should 
     proceed with the current plan, which is to merge the sockets part 
     of the recently approved XNS specification into the Austin Group work 
     on a combined Open Group/POSIX standard for UNIX. (There is a Sanity 
     Check of XNS still to come, but we can not make technical changes 
     during a Sanity Check). The new version of XNS should not be published, 
     but be used purely as input to Austin.

     Chris points out that once the dust has settled on what is needed to 
     be done to the API to fix this problem, we can input that to the 
     Austin Group so that it can be incorporated in the joint UNIX standard.

     3. inet_ntop()/inet_pton()
     
     It is recommended that the use of getaddrinfo() and getnameinfo() be
     used with the AI_NUMERICHOST flag to obtain the same functionality 
     that inet_ntop()/inet_pton() provides but still work with scope 
     addresses.

     4. It was noted at the meeting that the getxxxbyyyy call 
     (e.g., getipnodebyname()) made porting existing applications 
     easier (more of a 1-1 mapping).  A bit more coding when using 
     the getaddrinfo()/getnameinfo() functions.
     
     5. It was obvious to everyone at the meeting that there is no
     "water to wine" solution.

Other Issues:
=============

     Other issues that we didn't have enough time to discuss and
     that we are noting so that they can be discussed on the ipng
     alias:
     
     1. INET6_ADDRSTRLEN
     
     INET6_ADDRSTRLEN is defined to be 46 characters.  The value of 
     INET6_ADDRSTRLEN depends on how we make a textual representation 
     of "scope_id" portion. 
     
     There was some mention in the meeting for defining the 
     following getnameinfo(3) flags:
     
		NI_NUMREICHOST	   host is numeric (46 digits maximum)
		NI_NUMREICSCOPE    scope is numeric (2^32 => 10 max digits)
		NI_NUMREICPORT	   port is numeric (2^16 => 5 digits)
	getnameinfo(3) would return:
		fec0::1@cisco	if you give NI_NUMERICHOST
		fec0::1@3	if you give NI_NUMERICHOST | NI_NUMERICSCOPE
 		deering.cisco.com	if you give NI_NUMERICSCOPE
 		deering.cisco.com	if you give 0

     Jun-ichiro also stated in a follow-up email that it is okay to leave 
     INET6_ADDRSTRLEN as is (= 46), and add a note that says "it is only for 
     inet_ntop(), don't use it with getnameinfo.  This does not include 
     scope portion".	  
     
     Jun-ichiro points out that we have NI_MAXHOST for getnameinfo, which 
     is the only function that returns addr@scope of scope/addr. NI_MAXHOST 
     is more suitable than INET6_ADDRSTRLEN as getnameinfo may return a 
     string for other protocol families as well.  Jun-ichiro and others 
     recommend that NI_MAXHOST should be used for getnameinfo() and 
     RFC2553-bis should say it loudly.
   
     2. How do we make the stuff that currently uses ifindex (such as joining
     a multicast group) provide the ability to say "use that site" instead of
     specifying an actual interface. 
     
     We didn't discuss this issue during our meeting but I would like to 
     note the problem in the minutes for completeness.  Courtesy of Erik 
     I included his summary on the ifindex issue:
     
	"The issues I brought up in Tokyo (see my slides). One of the 
	things that is missing wrt different scopes/zones is:
	How do we make the stuff that currently uses ifindex (such as 
	joining a multicast group) provide the ability to say "use 
	that site" instead of specifying an actual interface.

	The room suggested generalizing the use of ifindex in the API to be
	a "zone id". Thus you could envision calling if_nametoindex("cisco")
	where "cisco" is a site name advertised using MZAP (or in Router 
	Advertisements if we choose to incorporate MZAP functionality as a
	new option) and the resulting index would be used in IPV6_JOIN_GROUP, 
	IPV6_MULTICAST_IF, etc.

	If we choose to go this way it would make sense to generalize
	the name if_nametoindex to be e.g. zone_nametoindex (while preserving 
	the old for compatibility) and presumably having a zone_nameindex 
	which can produce different types of lists (interfaces, links, sites).

	But perhaps we need to have the more general discussion if this all 
	makes sense before we look at extensions and clarifications to the 
	basic API."
	
     3.  It is recommended that the following getipnodebyname() flags also be
     defined for getaddrinfo():

         AI_ADDRCONFIG
         AI_DEFAULT
         AI_ALL
         AI_V4MAPPED
         
     Specification of their use will be analogous to that of 
     getipnodebyname().  There was support for adding these flags to the 
     getaddrinfo() interface,  but I am leaving the proposal in the 
     "Other Issues" section as we didn't have a chance to completely 
     discuss the proposal at the API meeting.
     
     NOTE: There was strong consensus on adding AI_ADDRCONFIG to
     getaddrinfo() so this is listed in the "Recommendation" section above.
     I am also listing it here for completeness.
     
     4.  Jun-ichiro will send out more details (in separate email) to
     the ipng working group alias on a proposal to map between FQDN,
     numeric, and scope.   

Credits:

Thanks for all those who participated in the discussion and
to Tim Hartrick (Mentat) who came up the title of the meeting  :).
Thanks to Erik and Jim for their comments on the minutes.

   

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------