Subject: APIs for controlling source address selection

From: Richard Draves <[email-masked]>
Date: Tue, 14 Nov 2000 09:24:55 -0800

draft-ietf-ipngwg-default-addr-select raises the possibility of per-socket
control over the mobility & privacy aspects of source address selection, for
those applications that aren't happy with their implementation's default
behavior.

For example: web browser on mobile node wants to use care-of addresses for
its transient HTTP connections.
For example: distributed internet game wants to use public addresses for its
sockets, so other players can do a getpeername() and get a permanent address
for the peer.

I would like to sketch out some possibilities. I think this should go into
rfc2553bis.

I have two possible designs for your consideration: A (simple) and B (more
complex).

Design A:
There are two new socket options at the IPPROTO_IPV6 level. You can get/set
both of them.

IPV6_PREFER_CAREOF_ADDRESS
Takes an int value. Boolean option - values are 0 & 1. The default value is
0, meaning source address selection prefers home addresses. If set to 1,
then source address selection prefers care-of addresses. With either
setting, if you have an address that is both a home address and a care-of
address (you are at one of our home network locations), then it is preferred
over other addresses.

IPV6_PREFER_PUBLIC_ADDRESS
Takes an int value. Boolean option - values are 0 & 1. The default value is
0, meaning source address selection prefers anonymous addresses. If set to
1, then source address selection prefers public addresses. Either way, note
that this is a low-priority preference. For example, choosing an
appropriately scoped address, and avoiding deprecated addresses, is more
important.

Pros: Simple
Cons: Need two system calls to change both settings. Can't express some
application requirements, like "must use an anonymous address" or "generate
a new anonymous address just for this socket". But are those reasonable
things to support?

Design B:
There is one new socket option at the IPPROTO_IPV6 level. You can get/set
the option.

IPV6_SOURCE_ADDRESS_SELECTION
Takes an unsigned int value, which is an OR combination of two values, one
value controls mobility and the other value controls privacy:
IPV6_PREFER_CAREOF_ADDRESS		0x10
IPV6_PREFER_HOME_ADDRESS		0x00
the default is IPV6_PREFER_HOME_ADDRESS.
Semantics as above.

IPV6_PREFER_PUBLIC_ADDRESS		0x01
IPV6_PREFER_ANONYMOUS_ADDRESS		0x00
IPV6_MUST_HAVE_ANONYMOUS_ADDRESS	0x02
IPV6_CREATE_NEW_ANONYMOUS_ADDRESS	0x03
the default is IPV6_PREFER_ANONYMOUS_ADDRESS.
The value IPV6_MUST_HAVE_ANONYMOUS_ADDRESS means that if the stack's default
rules would pick a global public address, the connect() (or whatever) call
should instead fail. If the stack picks a link-local or site-local scoped
source address (which is not anonymous), then that's OK.
For example, if an administrator has disable anonymous addresses on the
machine, and the app uses IPV6_MUST_HAVE_ANONYMOUS_ADDRESS, then the app
will get an error when trying to connect() to a global address. Whereas if
the app uses IPV6_PREFER_ANONYMOUS_ADDRESS, it will not get an error from
the connect().
The value IPV6_CREATE_NEW_ANONYMOUS_ADDRESS means that the if the stack's
default rules pick a global scope address, then the stack should use the /64
prefix to generate a new anonymous source address. This new anonymous source
address will be chosen for other sockets (unless explicitly specified with
bind()). This option forces the stack to generate a new anonymous address
for each socket, for the truly paranoid.

Pros: Gives the app more flexibility.
Cons: Gives the app more rope. Lets the app change both settings with one
system call. More code to implement (particularly
IPV6_CREATE_NEW_ANONYMOUS_ADDRESS).

What do you think?

Thanks,
Rich
--------------------------------------------------------------------
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: "Markku Savela" <[email-masked]>
Date: Wed, 15 Nov 2000 10:59:55 +0200

> -----Original Message-----
> From: EXT Richard Draves
>
> I have two possible designs for your consideration: A
> (simple) and B (more complex).

Either one is probably easy to implement and use.

I'm just wondering whether this type thing is the right direction to go with
the API? It requires each application to include a user controllable method
for choosing these settings.

In case of web browser, it's not just the case of choosing of care
address/home address for all connections. The actual need is could be to use
either care or home depending on which server one is using.

We already have a selector mechanism for IPSEC. It does occur to me that
this selector part could be a separate component, and IPSEC just one user of
it.

Another use of the selectors would be to define which connections use home
address and which are okay with care address. Similarly, there are probably
many other things that one could control through the selectors (quality of
service paramaters?).

Should we describe an API section that controls some kind of selector
mechanism, which would for example implicitly "fire" the specified socket
options for the connections that match? Let applications just do their own
stuff, and set control paramaters externally.

---

From: Dave Marquardt <[email-masked]>
Date: Wed, 15 Nov 2000 08:57:51 -0600

> for choosing these settings.

"require" seems a bit strong here.  I don't think any applications is
REQUIRED to use this interface.

-Dave

---

From: Jim Bound <[email-masked]>
Date: Thu, 16 Nov 2000 04:44:16 -0500

Richard,

I do not want this in 2553bis.  We are closing down this API for good.
Future work will be done in XNET.

What I suggest is you take it to the advanced API or create a new draft
for these options.

I have no comment on your proposal at this time.

Other than on any good implementation of IPv6 for Servers and Routers
the vendor needs to be able to permit the user to override the entire
notion of source address selection, in your draft.

I most likely will object to any MUSTS in this drafts anyway at last
call.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 16 Nov 2000 04:55:26 -0500

I like the idea of a selector API greatlly.  This could be a new piece
of work we need too.  

/jim