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

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

Hello Brian:

> > 	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.

Thanks for the comment. Yes, we published the 3rd revision of IPv6 address
selection API draft. I don't know why it did not get announced at the IPv6
ML. We intend to publish this document as an individual RFC. The document
is under review by some of the IPv6 API authors. But any input from the
wg is also appreciated very much by the authors.
> ------------------------------------------------------------------------
> 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?
> 
> ------------------------------------------------------------------------

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.

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. 

> Section 4:
>     <netinet/in.h>.
> Not in6.h?

IPV6 Socket options are defined in netinet/in.h
i,e. IPV6_HOPLIMIT, IPV6_NEXTHDR etc. 

<snip - editorial comments>

Thanks for the careful review for editorial changes. We will review
them to incorporate in the document.

>     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?

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.
> ------------------------------------------------------------------------
> 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?
> 

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

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

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 21 Jul 2005 17:40:13 -0400

> Good catch! Perhaps IPv6 Socket API authors can shine light on this.

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

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 22 Jul 2005 20:42:05 +0900 (JST)

Hello Samita,

I have one question about the usage of IPV6_PREFER_DST_LARGESCOPE and
IPV6_PREFER_DST_SMALLSCOPE socket options.

I'm afraid I cannot imagine when I need to use the above socket
options, since selection of a destination address is done by
getaddrinfo() (or by specifying an address explicitly) I think.

Do you have any concrete idea of the usage of above socket options?

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Brian Haley <[email-masked]>
Date: Fri, 22 Jul 2005 11:00:39 -0400

> 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_CGA | IPV6_PREFER_SRC_NONCGA
      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.

> by default as source address), but one can change that by using setsockopt()

The default is to follow RFC 3484, right?  :)

> is possible that a MIPv4 compliant dual-stack node may want to comunicate with a

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."

Thanks,

-Brian