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

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 11 Jan 2007 18:49:16 +0900

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.
> 
> ?