[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about draft-ietf-v6ops-addr-select-req-00.txt



Hi.

Let me re-post my e-mail below as I haven't received any feedbacks.
I'll include these discussions in the next revision and post it soon.

Regards.

Arifumi Matsumoto wrote:
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.

?