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