Hi all,
I'm sorry for my late action for this new wg draft.
I listed some points that was raised at San Diego and my comments below.
Let me classify these into 3 classes from the aspect of RFC3484 revision.
To move forward requirements draft, I suppose it's better to decide
what the base mechanism is we can rely on. That is, we can assume RFC3484
as it is now, or modified RFC3484 or nothing (start from zero).
1) Issues that don't need RFC3484 modification.
- specific set of policies to a specific host.
This issue is already in the requiremnt draft.
2) Issues that may need slight RFC3484 change.
- The address type dependent preference.
There was a thread "address selection and DHCPv6" by James Carlson
at IPv6 ML about address type dependent preference, such as DHCPv6,
RA, manual and also privacy extension(RFC3041) address.
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06910.html
It is hard to define default preferences for these address types,
because IMO it depends on the usage of these addresses, but not on
address types themselves. It is the policy table where you can
control host's address selection behavior. At this time, however,
I cannot say policy table is the perfect way to fulfill this
requirement.
For example, You can set priority on 3041 address by putting a line
in policy table specifying 3041 address by 128-bit prefixlen and
continuing to update policy table according to 3041 address changes.
But, this is surely troublesome for users and implementers.
One idea is to update RFC3484 policy table definition so that it
can handle alias addresses like privacy, DHCPv6 generated,
RA generated, manually generated (and even Home Address ?)
To prefer privacy address by default, and to prefer RA-generated
address for site internal, the policy table will look like this.
Prefix Pref Label
2001:db8:1234::<PRIVACY>/128 30 2
::/0 10 2
2001:db8:1234::<RA>:/128 30 1
2001:db8::/48 20 1
3) Issues that need big RFC 3484 change.
- Multiple Interfaces Issues
Dave Thaler gave us comments that multiple-interface hosts may face
policy collision and distribution of dst address selection policy
and src address selection policy should be separated. Also, per-interface
policy table was proposed.
After all, this is a policy collision problem.
To make a host have one policy table per network interface IMO doesn't
solve policy collision issue. Source address selection is performed
after output interface is selected, but destination address selection
is before output interface selection. In this case, destination address
selection uses all the policy tables a host has, so here collision can
happen.
Separating destination address selection and source address selection
will have a big change on RFC3484 policy table definition. Though it
may be a good idea to avoid source address selection policy collision.
- application specific address selection should be considered. Also,
XML was proposed for the right format to describe those policies.
This issue is so much application dependent. Even if policy table
supports application specific policies, the application doesn't
necessarily follow the policy table. It seems to me a better idea
to use address selection APIs or application specific configuration
file for it.
Any comments are welcome.
Best regards.
?