[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about draft-ietf-v6ops-addr-select-req-00.txt
Hello,
After previous meeting, we will make slight changes to the document.
We added 'Section 5' with comments there as follows. Could you feed
me back any comments? Especially, we ask commentators there to
check out your opinion. Thanks in advance!
---------
5. Discussion at 67th IETF
Here listed some points that was raised at San Diego and comments
below. These points are classified into 3 classes from the
aspect of
RFC3484. It seems to be better to settle the basis for this
discussion. That is, we can assume RFC3484 as it is now, we should
modify RFC3484 or we should start from nothing.
1) Issues that don't need RFC3484 modification">
- The ability to deliver 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 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 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.
--------
- 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.
On 2006/12/22, at 18:18, 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.
-------------------------------
Ruri Hiromi
hiromi@inetcore.com