Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt

From: Brian Haley <[email-masked]>
Date: Wed, 20 Jul 2005 16:08:31 -0400

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title		: IPv6 Socket API for source address selection
> 	Author(s)	: E. Nordmark, et al.
> 	Filename	: draft-chakrabarti-ipv6-addrselect-api-03.txt

Hi Samita, Erik, and Julien,

Didn't see this sent to the IPv6 ML, but sending comments here, most are 
editorial.

-Brian

------------------------------------------------------------------------
Overall comment:

1. The draft talks about setting flag X and flag not-X, but the only
place I see where this can happen is trying to set these together:

	IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
	AI_PREFER_SRC_CGA | AI_PREFER_SRC_NONCGA

Am I missing something?  Can I somehow turn-off the use of Care-of
Addresses as source addresses?  Maybe it's implied that if I don't set 
the flag in the setsockopt()/getaddrinfo() call that it turns-off using 
that type of source address?

------------------------------------------------------------------------
Section 4:

    <netinet/in.h>.

Not in6.h?

------------------------------------------------------------------------
Section 5:

First paragraph:

    Another strategy is to call down to network layer to retrieve source
/network/the network/

------------------------------------------------------------------------
Section 6:

The example code differs from that in Section 5, plus has a few typos.
I'll try and do this in diff -/+ style:

-	uint32_t flags;
-
-        flags = IPV6_PREFER_SRC_TMP;
---
+	uint32_t flags = IPV6_PREFER_SRC_TMP;

          if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
              (char *) &flags, sizeof (flags)) == -1) {
                  perror("setsockopt IPV6_ADDR_REFERENCES");
          }

    An application which needs to be able to restore the default settings
    on the socket would instead do this:

         uint32_t save_flags, flags;
         int optlen = sizeof (save_flags);

-       /* Save the existing IPv6_ADDR_PREFERENCE FLAG now */
---
+	/* Save the existing IPv6_ADDR_PREFERENCES flags now */

         if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
             &save_flags, &optlen) == -1 {
                 perror("getsockopt IPV6_ADDR_REFERENCES");
          }

          /* Set the new flags */
          flags = IPV6_PREFER_SRC_TMP;
          if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
              (char *) &flags, sizeof (flags)) == -1) {
                  perror("setsockopt IPV6_ADDR_REFERENCES");
          }

          /* Do some work with the socket */
-        ;
          / Restore the flags */
-        flags = IPV6_PREFER_SRC_TMP;
          if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
              (char *) &save_flags, sizeof (save_flags)) == -1) {
                  perror("setsockopt IPV6_ADDR_REFERENCES");
          }

------------------------------------------------------------------------
    Application must not set conflicting flags; the only conflicts that
/Application/Applications/

    are checked for are flag X and flag not-X being set at the same time.
    Example of conflicting flags: IPV6_PREFER_SRC_TMP |
    IPV6_PREFER_SRC_PUBLIC.

Maybe put "IP.. | IP.." on new line?  Not that important.

    In order to allow different implementations to do different parts of
    address selection in getaddrinfo() and in the protocol stack, this
    specification requires that applications set the same flags when
    calling getaddrinfo() and when calling setsockopt().  For example, if
    the application sets IPV6_PREFER_SRC_COA flag, it must use
/sets/sets the/

    AI_PREFER_SRC_COA flag when calling getaddrinfo().  If applications
/AI_PREFER_SRC_COA/the AI_PREFER_SRC_COA/

    are not setting the same flags the behavior of the implementation is
    undefined.

------------------------------------------------------------------------
    It is envisioned that Mobile IPv6 applications may want to choose
    Care-of-Address as source for short transaction (for efficiency)
    while roaming, but still keep Home address as source address for long
    lived communication for address stability.  Thus it is recommended
    that applications take this idea into consideration and use the
    source address selection API for home-address and care-of -address
    selection appropriately.  Similarly, an application may choose to set
    IPV6_PREFER_SRC_COA flag for datagram services; it uses home-address
    as source when at home and uses care-of-address outside home-network
    for short datagram transactions.  This is an advantage of having
    flexibility of "preference" vs. "requirement".
/my rewrite below/

    It is envisioned that Mobile IPv6-aware applications may want to
    choose a Care-of Address as the source address for short
    transactions (for efficiency) while roaming, but still use the Home
    Address as the source address for long-lived communications for
    address stability.  It is recommended that applications take this
    into consideration and use the source address selection API for
    Home Address and Care-of Address selection appropriately.

I don't think you need those last two sentences since one is just
repeating previous text anyways.

------------------------------------------------------------------------
Section 7:

    o  If an implementation supports both stream and datagram sockets, it
       should implement the address preference mechanism API described in
       this document on types of sockets.
/types/both types/

    o  Implementation supporting this API must implement both AI flags
       and socket option flags processing for portability of
       applications.
/Implementation/An implementation/

------------------------------------------------------------------------
Section 8:

I think the flags need to be indented like this for readability:

       Source address selection rule #4 (prefer home address):

         IPV6_PREFER_SRC_HOME (default)

------------------------------------------------------------------------
Section 9:

    IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that
    can be used on an AF_INET6 socket, are supported in this API.  In
    some cases the IPv4-mapped addresses may not make much sense because
    the attributes are IPv6 specific.  For example, IPv6 temporary
    addresses are not the same as private IPv4 addresses.  However, the
    IPv4 mapped-address support may be useful for mobile home address and
    care-of-address.  At this point it is not understood whether this API
    has any value to IPv4 addresses or AF_INET family of sockets.

The second to last sentence here is confusing (regarding mobile), can
you explain what you meant?

------------------------------------------------------------------------
Section 10:

    Sometimes an application may have a requirement to only use address
/address/an address/

------------------------------------------------------------------------
    The verification of temporary vs. public, home vs. care-of, CGA vs.
    not, are performed by a new function defined for this purpose:

       #include <netinet/in.h>

Not in6.h?

       boolean_t  inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
                                   uint32_t flags);

    Where the flags contain the specified source preference flags.  The
    function expects a non-NULL input for srcaddr. sockaddr_in6 structure
    must contain AF_INET6 as sin6_family.  It also must contain the
    scope_id information if the source address is a link-local address.

    The function returns true when srcaddr corresponds to a valid address
    in the node and that address type satisfies the preference flag(s).
    If srcaddr input value does not correspond to any address in the node
    or it does not match an address which satisfy the preferences
    indicated, the function returns false.

I think these two paragraphs should be re-written:

    The function expects a non-NULL input for srcaddr, where the
    sockaddr_in6 structure is initialized as follows:

	sin6_addr is the 128-bit IPv6 address
	sin6_family must be set to AF_INET6
	sin6_scope_id must be set if the address is link-local

    The flags argument contains the specified source preference flags.

    The function returns true (1) when the IPv6 address corresponds to a
    valid address in the node and satisfies the given preference flags.
    If the IPv6 address input value does not correspond to any address in
    the node, or it does not match an address which satisfies the
    preference flags indicated, the function returns false (0).

------------------------------------------------------------------------
    This function can handle multiple valid flags combination as its
/flags combination/preference flag combinations/

    second parameter, for example IPV6_PREFER_SRC_COA |
    IPV6_PREFER_SRC_TMP, which means that all flags must be satisfied for
    the result to be true.  Invalid flag values result in false return
    value.
/false/a false/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 21 Jul 2005 14:47:14 -0700 (PDT)

> > You mean ip6.h?
> > ip6.h is mainly for advanced API. But this document is more of an
> > extension to Base API. In that context,  <arpa/inet.h> may
> > be a choice. On the otherhand, all the address testing macros are
> > in netinet/in.h. 
> > 
> > Good catch! Perhaps IPv6 Socket API authors can shine light on this.
> > 
> > Thanks again,
> > -Samita
> > 
> 
> I'd vote for netinet/in.h
> 
> Some implementations have netinet/in6.h, but that's really an
> implemenation choice. Using netinet/in.h should work for ipv4 and ipv6.
> 
> -vlad
> 

It makes more sense. Agreed.

Thanks,
-Samita

---

From: "Steve Cipolli" <[email-masked]>
Date: Fri, 22 Jul 2005 15:14:30 -0400

The third sentence in the abstract appears to be broken:

This document fills that gap by specifying socket level options add new
flags for the getaddrinfo() API to specify preferences for address
selection that modify the default
address selection algorithm.

I think what was intended was:

This document fills that gap by specifying socket level options and
adding new flags for the getaddrinfo() API to specify preferences for
address selection that modify the default
address selection algorithm.

--Stephen

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 22 Jul 2005 17:21:40 -0700 (PDT)

> > 
> > The combination of flag X and not-X is not allowed - only one should be
> > set at one time, becuase one packet has one source address.
> 
> After talking to Vlad I now understand this, you're saying these are 
> invalid flags to set together:
> 
> 	HOME | COA
> 	TMP | PUBLIC
> 	CGA | NONCGA
> 	LARGE | SMALL
> 
>  From a C-code perspective, flag X and not-X would mean:
> 
> 	HOME & ~HOME
> 
> So I don't like the X/not-X text, I like the wording of "conflicting 
> flags" much better as used in a few other places.  Maybe if the end of 
> Section 4 could say this:
> 
>     Setting conflicting flags at the same time results in the error
>     EINVAL.  For example, invalid combinations of flags are:
> 
>       IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
>       IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_PUBLIC
>       IPV6_PREFER_SRC_LARGESCOPE | IPV6_PREFER_SRC_SMALLSCOPE
> 
>     If flags are set as a combination of 'X' and 'Y', and if 'Y'
>     is not applicable or available in the system, then the selected
>     address has attribute 'X' and system default for the attribute 'Y'.
>     For example, a possible valid combination of flags can be:
> 
>       IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE
> 
> There are other places that would need updating too.

Point taken.

> > The default flags are described in section 7. For example, by default
> > *_SRC_HOME is the choice of flag, ( it means COA address is not used
> > by default as source address), but one can change that by using setsockopt()
> > with *_SRC_COA.
> 
> The default is to follow RFC 3484, right?  :)

Yes. 

> > It was discussed in the ipv6 list sometimes ago that IPV4-mapped IPv6
> > addresses may be useful for home-address and COA  for IPv4
> > and IPV6 interoperability. It is not well understood, but I think it 
> > is possible that a MIPv4 compliant dual-stack node may want to comunicate 
with a
> > IPv6 address.
> 
> Ok, then can this sentence be changed to give that information:
> 
> "However, the IPv4 mapped-address support may be useful for mobile home 
> address and care-of-address."

Ok.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 22 Jul 2005 17:27:16 -0700 (PDT)

> address selection algorithm.

Agree, the sentence needs change.

-Samita