Subject: chakrabarti-ipv6-addrselect-api-00 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 14:13:59 +0200 (EET)

Hi,

A few comments on the address selection API draft.

non-editorial:
--------------
6. Security Considerations

   This document conforms to the same security implications as specified
   in IPv6 Basic Socket API [2] document. It is also recommended that
   the applications set IPV6_V6ONLY IP level socket option to permit
   the nodes to not process IPv4 packets as IPv4 Mapped addresses.

==> even if I kinda agree with the last sentence, it seems to me to be a bit
farfetched to be mentioned in this spec?

   - Is there a need for "validation" functions to go with these
     preferences such as functions that check whether an address is
     a temporary address?

==> perhaps validation functions would be nice, but generally speaking, it
is not possible to, for certainty, to ensure what an address is or isn't?

==> Please clarify whether you meant a macro like "IN6_IS_ADDR_LOOPBACK" or
something "verify whether this address assigned on the node was of type 
X"?

mostly editorial:
-----------------

Expires: August, 2003                             Samita Chakrabarti 
                                                  Sun Microsystems, Inc.
					          Julien Laganier
                                                  Sun Microsystems, Inc.
	                                          LIP / ENS-Lyon

						  February, 2003
==> a typo with affilications I assume, extra Sun?

              IPv6 Socket API for source address selection
               draft-chakrabarti-ipv6-addrselect-api-00.txt 

==> uppercase words

INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003

==> s/Feb., 2003/Feb 2003/ should be enough.

4.  Changes to the protocol-independent nodename translation

    Section 8 of Default Address Selction [1] document indicates about
==> s/Selc/Selec/

5. IPv4-Mapped IPv6 Addresses

   IPv4-Mapped IPv6 addresses are not supported for setting preference
   on home, care-of-address, CGA, non-CGA, public or privacy auto-
   configured addresses as source addresses. Because they are all pure
   IPv6 addresses. 

==> reword the last sentence to mix better with the rest.
==> isn't it "IPv4-mapped" with small m?

[2]    R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens,
           "Basic Socket Interface Extensions for IPv6", 
            draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002.

==> surnames first, initial next in the ref author lists

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 19:58:55 +0100 (CET)

> is not possible to, for certainty, to ensure what an address is or isn't?

In some cases yes, but there are some issues related e.g. to the late binding
of source addresses for e.g. UDP.

For instance, if you specify PREFER_SRC_TMP with the semantics of it being
a requirement (i.e. REQUIRE_SRC_TMP) then getaddrinfo() might succeed,
the setsockopt might succeed, yet when you go to send a UDP packet
then sendto() would have to fail because there is no more a temporary source
address available for the destination to which you are trying to send.

When using TCP then the failure would appear at the time of connect which
is better, but it might still be hard to react reasonably to such failures.
The validation allows doing a getsockname() after connect() to see what
address the socket ended up with, which allows for "softer" error handling.

Thus I don't think we can do only hard requirements but that we also need
to be able to express preferences. And preferences + validation seems to be
able to solve what you can do with preferences + requirements.

> something "verify whether this address assigned on the node was of type 

Given that there is an extensible set of flags it might make more sense to
define the validation as a function which take the flags as arguments
e.g.
	inet6_is_addr(struct in6_addr *, uint32_t flags)
where the flags contain the SRC_PREFER flag set.

     Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Mar 2003 21:24:26 +0200 (EET)

> where the flags contain the SRC_PREFER flag set.

That didn't answer the question, but I assume you meant that the v6
address being validated must belong to the node performing validation?

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 22:07:01 +0100 (CET)

> address being validated must belong to the node performing validation?

Sorry for my poor reading.

In general it makes sense to restrict the address verification to run
on the node itself. While some aspects (such as temporary vs. public)
can be determined on other nodes, telling the difference between a home
address and a care of address can only be done on the node itself.

  Erik