draft-ietf-v6ops-addr-select-req-00.txt   draft-ietf-v6ops-addr-select-req-01.txt 
IPv6 Operations Working Group A. Matsumoto IPv6 Operations Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Standards Track NTT Intended status: Standards Track NTT
Expires: May 5, 2007 R. Hiromi Expires: August 5, 2007 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
Requirements for distributing RFC3484 address selection policy Requirements for the address selection mechanisms
draft-ietf-v6ops-addr-select-req-00.txt draft-ietf-v6ops-addr-select-req-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2007. This Internet-Draft will expire on August 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RFC3484 defines source and destination address selection algorithms RFC3484 defines source and destination address selection algorithms
that are commonly deployed in current popular OSs. Meanwhile, there that are commonly deployed in current popular OSs. Meanwhile, there
is a possibility to provide multiple addresses in one physical is a possibility to provide multiple addresses in one physical
network. In such a multi-prefix environment, end-hosts could network. In such a multi-prefix environment, end-hosts could
encounter some troubles in the communication because of default use encounter some troubles in the communication because of default use
of the RFC3484 mechanism. of the RFC3484 mechanism. Some mechanism for the address selection
problems are proposed including RFC3484 policy table distribution and
Therefore, extending various rules beyond the default use of the RFC3484-update. This document describes the requirements for these
RFC3484 mechanism should be considered. We propose a concept of address selection mechanisms.
distribution of address selection policy to an end-host as a solution
to these possible problems.
In this document, we describe detailed requirements of address
selection policy distribution.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3
2. Policy distribution model and terminology . . . . . . . . . . 4 2. Requirements of Address Selection . . . . . . . . . . . . . . 3
3. Requirements of Policy distribution . . . . . . . . . . . . . 5 2.1. Contents of Policy Table . . . . . . . . . . . . . . . . . 3
3.1. Contents of Policy Table . . . . . . . . . . . . . . . . . 5 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Redistribution of changed Policy Table . . . . . . . . . . 4
3.3. Redistribution of changed Policy Table . . . . . . . . . . 5 2.4. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Generating Policy Table per CPE/Node . . . . . . . . . . . 4
3.5. Generating Policy Table per CPE/Node . . . . . . . . . . . 6 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Possible Solutions for Address Selection Problem . . . . . . . 4
4. Solutions for RFC3484 policy distribution . . . . . . . . . . 6 3.1. Routing System Assistance for Address Selection by
4.1. Policy distribution with router advertisement (RA) Fred Baker . . . . . . . . . . . . . . . . . . . . . . . . 4
message option . . . . . . . . . . . . . . . . . . . . . . 6 3.2. 3484-update . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Policy distribution in DHCPv6 . . . . . . . . . . . . . . 7 3.3. shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Using other protocols . . . . . . . . . . . . . . . . . . 7 3.4. policy distribution mechanism . . . . . . . . . . . . . . 6
4.4. Defining a new protocol . . . . . . . . . . . . . . . . . 8 4. Discussion at 67th IETF . . . . . . . . . . . . . . . . . . . 7
4.5. Converting routing information to policy table . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Routing System Assistance for Address Selection by Appendix A. Solutions for RFC3484 policy distribution . . . . . . 9
Fred Baker . . . . . . . . . . . . . . . . . . . . . . . . 8 A.1. Policy distribution with router advertisement (RA)
5.2. 3484-update . . . . . . . . . . . . . . . . . . . . . . . 9 message option . . . . . . . . . . . . . . . . . . . . . . 10
5.3. shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. Policy distribution in DHCPv6 . . . . . . . . . . . . . . 10
5.4. policy distribution mechanism . . . . . . . . . . . . . . 10 A.3. Using other protocols . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 A.4. Defining a new protocol . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 A.5. Converting routing information to policy table . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that One physical network can have multiple logical networks. In that
case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual
stack environment or in a site connected to both ULA [RFC4193] and stack environment or in a site connected to both ULA [RFC4193] and
global scope networks, an end-host has multiple IP addresses. These global scope networks, an end-host has multiple IP addresses. These
are examples of the networks that we focus on in this document. In are examples of the networks that we focus on in this document. In
such an environment, an end-host will encounter some communication such an environment, an end-host will encounter some communication
trouble documented in PS. [I-D.ietf-v6ops-addr-select-ps] trouble documented in PS. [I-D.arifumi-v6ops-addr-select-ps]
RFC 3484 [RFC3484] defines both source and destination address RFC 3484 [RFC3484] defines both source and destination address
selection algorithms. RFC 3484 defines a default address table, and selection algorithms. RFC 3484 defines a default address table, and
enables adding other entries to this table. Flexible address enables adding other entries to this table. Flexible address
selection can be carried out. selection can be carried out.
In addition, the distribution of an address policy table is an In addition, the distribution of an address policy table is an
important matter. RFC 3484 describes all the algorithms for setting important matter. RFC 3484 describes all the algorithms for setting
the address policy table, but it makes no mention of the address policy table, but it makes no mention of
autoconfiguration. autoconfiguration.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
To make a smooth connection with the appropriate source and To make a smooth connection with the appropriate source and
destination address selection inside a multi-prefix environment, destination address selection inside a multi-prefix environment,
nodes must be informed about routing policies of their upstream nodes must be informed about routing policies of their upstream
networks and possible source address selection policies. Then, those networks and possible source address selection policies. Then, those
nodes must put those policies into individual policy tables. nodes must put those policies into individual policy tables.
On the other hand, the RFC3484 mechanism is commonly deployed. On the other hand, the RFC3484 mechanism is commonly deployed.
However, manual configuration of the policy table is not a feasible However, manual configuration of the policy table is not a feasible
idea and some automatic mechanism is needed. idea and some automatic mechanism is needed.
Therefore, we propose a concept of distribution of address selection
policy from a network to an end-host to cooperate with the RFC3484
mechanism as a solution to these possible problems.
In this document, requirements for distribution of the address In this document, requirements for distribution of the address
selection policy are described for promotional use of the RFC3484 selection policy are described for promotional use of the RFC3484
mechanism. Our goal is to carry our autoconfiguration with mechanism.
distribution mechanism for utilization of RFC3484 more effectively.
1.1. Scope of this document 1.1. Scope of this document
Revising address selection rules defined in RFC 3484 is out of our
scope.
The routing information from an upstream network is necessary, but in The routing information from an upstream network is necessary, but in
this document, we are focused on how to select source and destination this document, we are focused on how to select source and destination
addresses at the RFC3484 address policy table of the end-host. addresses at the RFC3484 address policy table of the end-host.
In addition, there must be some practical ways or considerations 2. Requirements of Address Selection
other than the RFC3484 policy table to solve the address selection
problem, such as utilization of some routing protocols or operational
technique with a specific route but these discussions are out of our
scope. However, we select some examples of other mechanisms in
Section 5 only for comparison.
2. Policy distribution model and terminology
The distribution model:
Fig. 1: (basic model)
Policies transferred from the Policy Broker to the Node over an access
network.
+----+ +-------------+
|Node|<----------/policies/----------|Policy Broker|
+----+ +-------------+
Fig. 2: (extended model)
+----+ +--------------+ +-------------+
|Node|<---/policies/---|PolicyEnforcer|<---|Policy Broker|
+----+ +--------------+ +-------------+
Essentials (or Principles):
The distribution of Policy, which means that the address selection
policy of RFC3484 is sent to nodes, has the following functions.
* Policy Broker, which means a Policy originator in xSP, for
example, a dhcp server, originates its policy and sends it to a
Node using some prefix-assignment Protocols.
* A Node receives a Policy as a client. Then the client puts those
policies into its own Policy Table, which means the address
selection table defined in RFC3484.
* Policy Broker should make the Policy so that it can be easily
embedded into Nodes. The Policy message format should be defined
based on the algorithm specified in RFC3484.
* There might be a situation in which a Policy Broker and Node are
disconnected, and no direct message is exchanged. In this case,
there is a middle box defined as a Policy Enforcer, for example,
CPE illustrated in Fig. 2, and it relays the policy to the Node.
Requirements should be considered to include the policy-relay
case.
Terminology:
Node: end-host, end-terminal
CPE: Customer premises equipment
PE: Provider Edge device
NAS: Network Access Server
Policy: address selection policy for RFC3484 rule set
Policy Enforcer: optionally attached equipment to relay policy
Policy Broker/Server: Policy Originator in xSP(mandate)
Prefix Delegation Protocol: Protocols to carry prefix information data
address selection table: address selection table defined in RFC3484
Policy Table: address selection table defined in RFC3484
3. Requirements of Policy distribution
The purpose of the Policy distribution mechanism is to distribute a
Policy Table to Nodes and configure the Policy Table on the Nodes
automatically. The use of a distributed Policy Table on Nodes for
other purposes (e.g, configuring routing Table on the Nodes) is out
of the scope of this document.
3.1. Contents of Policy Table 2.1. Contents of Policy Table
A Policy Table is a set of Policies described in RFC 3484. Each A Policy Table is a set of Policies described in RFC 3484. Each
Policy consists of four elements: prefix value, precedence value, Policy consists of four elements: prefix value, precedence value,
label value, and zone index value. The Policy distribution mechanism label value, and zone index value. The Policy distribution mechanism
should be able to distribute a Policy Table that has one or more should be able to distribute a Policy Table that has one or more
Policies to Nodes. Policies to Nodes.
3.2. Timing 2.2. Timing
The Policy Table should be distributed to Nodes by a Policy broker at The Policy Table should be distributed to Nodes by a Policy broker at
any time when Nodes send a request for the Policy. any time when Nodes send a request for the Policy.
3.3. Redistribution of changed Policy Table 2.3. Redistribution of changed Policy Table
When a Policy broker has any change in a Policy Table that is When a Policy broker has any change in a Policy Table that is
distributed to Nodes, the Policy broker should redistribute the distributed to Nodes, the Policy broker should redistribute the
latest Policy Table to Nodes. latest Policy Table to Nodes.
3.4. Sections 2.4. Sections
The Policy distribution mechanism should support being performed in The Policy distribution mechanism should support being performed in
two kinds of sections: from PE to CPE and from CPE to Node. Policy two kinds of sections: from PE to CPE and from CPE to Node. Policy
distribution mechanisms provided in each section may or many not be distribution mechanisms provided in each section may or many not be
the same. the same.
3.5. Generating Policy Table per CPE/Node 2.5. Generating Policy Table per CPE/Node
The Policy distribution mechanism should allow for generating an The Policy distribution mechanism should allow for generating an
appropriate Policy Table per Node. For example, in some cases, each appropriate Policy Table per Node. For example, in some cases, each
Node may have a different set of assigned prefixes. In such a case, Node may have a different set of assigned prefixes. In such a case,
the appropriate Policy Table for each Node may also be different, and the appropriate Policy Table for each Node may also be different, and
a Policy broker may be needed to generate the Policy Table according a Policy broker may be needed to generate the Policy Table according
to the identity of the Node. to the identity of the Node.
3.6. Security 2.6. Security
The Policy distribution mechanism should provide for reliable, secure The Policy distribution mechanism should provide for reliable, secure
distribution of the Policy distribution from a Policy broker to distribution of the Policy distribution from a Policy broker to
Nodes. Nodes.
4. Solutions for RFC3484 policy distribution 3. Possible Solutions for Address Selection Problem
As described in section 4.1, the address selection policy table
consists of four elements: prefix value, precedence, label, and zone-
index. The policy distribution mechanism will deliver lists of these
elements.
4.1. Policy distribution with router advertisement (RA) message option
The RA message can be used to deliver a policy table by adding a new
ND option. Existing ND transport mechanisms (i.e., advertisements
and solicitations) are used. Advantages and disadvantages are almost
the same as those described in [DNS configuration RFC, RA section].
In addition, an advantage and disadvantages of distributing a policy
table are as follows.
Advantages:
- The RA message is used to deliver IPv6 address prefixes.
Therefore, delivering policies for selecting addresses with the
address attached to the host would be natural.
Disadvantages:
- The RA message is limited in size, and the RA may not be
sufficient to deliver full policies. The same compression
techniques, which were adopted in RFC4191 [RFC4191] can be used to
increase the number of policies delivered by RA messages.
- Currently, RA messages are not used between a PE and CPE. Other
protocols may be necessary to deliver a policy table.
- Configuring a policy table in each router that advertises RA
messages with an address prefix is necessary, so if a site has a
lot of routers, there will be a higher management cost.
- Delivering a specific policy table to one node is impossible
because RA messages are multicast.
4.2. Policy distribution in DHCPv6
By defining a new DHCPv6 option like
[I-D.fujisaki-dhc-addr-select-opt], a policy table can be delivered.
The advantages and disadvantages are almost the same as those
described in [DNS configuration RFC, DHCPv6 section].
In addition, there are the following advantages and disadvantages.
Advantages:
- Currently, DHCPv6 prefix delegation is mainly used between a PE
and CPE. Delivering a policy table with prefixes is possible.
- A DHCPv6 server can deliver a host-specific policy table.
- By using a DHCPv6 relay mechanism, managing a policy table from a
central server is possible.
Disadvantages:
- The DHCPv6 message size is limited to the maximum UDP transmission
size, so delivering complex policies by DHCPv6 may be impossible.
4.3. Using other protocols
Using other protocols (i.e., http and ftp) to deliver the policy
table is possible.
Advantages:
- No new transport mechanisms are necessary.
Disadvantages:
- Other service discovery mechanisms will be necessary.
- The procedure to distribute information should be defined (e.g.,
when to distribute and where the information is stored).
- Existing protocols may not have a mechanism to inform clients
about policy changes.
4.4. Defining a new protocol
Defining a new protocol to deliver a policy table will have the
following advantages and disadvantages.
Advantages:
- Defining a protocol suitable for policy distribution may be
possible.
Disadvantages:
- In addition to the disadvantages of 4.3, a new transport mechanism
needs to be defined.
4.5. Converting routing information to policy table
In an environment in which routing information and network links are
separated (e.g., between PE and CPE), converting routing information
to a policy table is possible. However, when intermediate routers
and nodes receive next-hop information, that is aggregated as a
default route or neighbor router, and cannot generate policy table [a
policy table cannot be generated].
Advantages:
- No new distribution mechanism is necessary.
Disadvantages:
- This mechanism can be used only in a limited environment.
5. Discussion
Other than this policy distribution mechanism, a few mechanisms are A few mechanisms for address selection problems are proposed. This
proposed. This section quickly reviews each proposal including a section quickly reviews each proposal including a policy distribution
policy distribution mechanism. mechanism.
5.1. Routing System Assistance for Address Selection by Fred Baker 3.1. Routing System Assistance for Address Selection by Fred Baker
Fred Baker proposed to us about this mechanism. A host asks the DMZ Fred Baker proposed to us about this mechanism. A host asks the DMZ
routers or the local router which is the best pair of source and routers or the local router which is the best pair of source and
destination addresses when the host has a set of addresses A and destination addresses when the host has a set of addresses A and
destination host has a set of addresses B. And then, the host uses destination host has a set of addresses B. And then, the host uses
the policy provided by the server/routing system as a guide in the policy provided by the server/routing system as a guide in
applying the response. He also proposed a mechanism that utilizes applying the response. He also proposed a mechanism that utilizes
ICMP error message to change the source address of the existing ICMP error message to change the source address of the existing
session. This point resembles 5.2 3484-update mechanism, so the session. This point resembles 5.2 3484-update mechanism, so the
following evaluation is based only on the first part of his proposal. following evaluation is based only on the first part of his proposal.
skipping to change at page 9, line 34 skipping to change at page 5, line 36
- A host has to wait until the response is received from the routing - A host has to wait until the response is received from the routing
system. system.
- The existing host/router OS implementation has to be changed a - The existing host/router OS implementation has to be changed a
lot. In the existing TCP/IP protocol stack implementation, lot. In the existing TCP/IP protocol stack implementation,
destination address selection is mainly the role of the destination address selection is mainly the role of the
application and not that of the kernel unlike source address application and not that of the kernel unlike source address
selection. Therefore, implementing this model without causing any selection. Therefore, implementing this model without causing any
affects on applications is not so easy. affects on applications is not so easy.
5.2. 3484-update 3.2. 3484-update
M. Bagnulo proposed a new method of address selection in his draft. M. Bagnulo proposed a new method of address selection in his draft.
[I-D.bagnulo-rfc3484-update] When the host notices that a network [I-D.bagnulo-rfc3484-update] When the host notices that a network
failure occurs or packets are dropped somewhere in the network by for failure occurs or packets are dropped somewhere in the network by for
example, an ingress filter, the host changes the source address of example, an ingress filter, the host changes the source address of
the connection to another source address. The host stores a cache of the connection to another source address. The host stores a cache of
address selection information so that the host can select an address selection information so that the host can select an
appropriate source address for new connections. appropriate source address for new connections.
Advantages: Advantages:
skipping to change at page 10, line 19 skipping to change at page 6, line 19
lot. In particular, changing the source address of the existing lot. In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation. TCP/IP protocol stack implementation.
- There is not so much experience with this kind of address - There is not so much experience with this kind of address
selection cache mechanism. selection cache mechanism.
- The host tries every address one-by-one, so the user has to wait - The host tries every address one-by-one, so the user has to wait
for a long time before the appropriate address pair is found. for a long time before the appropriate address pair is found.
5.3. shim6 3.3. shim6
shim6 is designed for site-multihoming. This mechanism introduces a shim6 is designed for site-multihoming. This mechanism introduces a
new method of address selection for session initiation and session new method of address selection for session initiation and session
survivability, which is documented in survivability, which is documented in
[I-D.ietf-shim6-locator-pair-selection] and [I-D.ietf-shim6-locator-pair-selection] and
[I-D.ietf-shim6-failure-detection]. [I-D.ietf-shim6-failure-detection].
The shim6 host detects connection failures and changes the source The shim6 host detects connection failures and changes the source
address during the session. address during the session.
skipping to change at page 10, line 45 skipping to change at page 6, line 45
Disadvantages: Disadvantages:
- A host has to learn address selection information per destination - A host has to learn address selection information per destination
host. The number of cache entry can be too big. host. The number of cache entry can be too big.
- The existing host/router OS implementation has to be changed - The existing host/router OS implementation has to be changed
significantly. significantly.
- The host tries every address one-by-one, so the user has to wait - The host tries every address one-by-one, so the user has to wait
for a long time before the appropriate address pair is found. for a long time before the appropriate address pair is found.
5.4. policy distribution mechanism 3.4. policy distribution mechanism
This mechanism takes advantages of RFC 3484 Policy Table that is This mechanism takes advantages of RFC 3484 Policy Table that is
widely deployed already. By distributing policies for Policy Table, widely deployed already. By distributing policies for Policy Table,
you can auto-configure a host's address selection policy. you can auto-configure a host's address selection policy.
Advantages: Advantages:
- A host can receive and understand address selection information - A host can receive and understand address selection information
before the host starts a connection. Therefore, the amount of before the host starts a connection. Therefore, the amount of
traffic and connection overhead time can be minimized. traffic and connection overhead time can be minimized.
skipping to change at page 11, line 8 skipping to change at page 7, line 8
This mechanism takes advantages of RFC 3484 Policy Table that is This mechanism takes advantages of RFC 3484 Policy Table that is
widely deployed already. By distributing policies for Policy Table, widely deployed already. By distributing policies for Policy Table,
you can auto-configure a host's address selection policy. you can auto-configure a host's address selection policy.
Advantages: Advantages:
- A host can receive and understand address selection information - A host can receive and understand address selection information
before the host starts a connection. Therefore, the amount of before the host starts a connection. Therefore, the amount of
traffic and connection overhead time can be minimized. traffic and connection overhead time can be minimized.
- A host does not need any other address-selection-related - A host does not need any other address-selection-related
information once that host receives the address selection policy information once that host receives the address selection policy
set. This can also reduce the amount of traffic. set. This can also reduce the amount of traffic.
- The existing OS implementation does not need to be changed - The existing OS implementation does not need to be changed
significantly on the OS that implements the RFC 3484 policy table. significantly on the OS that implements the RFC 3484 policy table.
Only the delivery mechanism to the table has to be prepared. Only the delivery mechanism to the table has to be prepared.
- Destination address selection can also be controlled by this - Destination address selection can also be controlled by this
mechanism. mechanism.
Disadvantages: Disadvantages:
- No other address selection rule that is beyond the RFC 3484 - No other address selection rule that is beyond the RFC 3484 policy
policy table framework can be implemented. table framework can be implemented.
- The OS implementation has to be changed, and the policy - The OS implementation has to be changed, and the policy
distribution server, such as a gateway router, has to be prepared. distribution server, such as a gateway router, has to be prepared.
- When DHCP or RA is used for transport mechanism of policy table, - When DHCP or RA is used for transport mechanism of policy table,
frequently changing policy cannot be delivered to hosts quickly frequently changing policy cannot be delivered to hosts quickly
because of the nature of these protocols. because of the nature of these protocols.
6. Security Considerations 4. 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.
5. Security Considerations
Address false-selection can lead to serious security problem, such as Address false-selection can lead to serious security problem, such as
session hijack. However, it should be noted that address selection session hijack. However, it should be noted that address selection
is eventually up to end-hosts. We have no means to enforce one is eventually up to end-hosts. We have no means to enforce one
specific address selection policy to every end-host. So, a network specific address selection policy to every end-host. So, a network
administrator has to take countermeasures for unexpected address administrator has to take countermeasures for unexpected address
selection. selection.
7. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References Appendix A. Solutions for RFC3484 policy distribution
8.1. Normative References In this section, several mechanisms for distributing RFC3484 policy
are compared and evaluated. The reason why this section is in
appendix is that these discussions should be after address selection
mechanism selection is finished and policy distribution mechanism is
selected. solution.
[I-D.ietf-v6ops-addr-select-ps] As described in section 3.1, the address selection policy table
consists of four elements: prefix value, precedence, label, and zone-
index. The policy distribution mechanism will deliver lists of these
elements.
A.1. Policy distribution with router advertisement (RA) message option
The RA message can be used to deliver a policy table by adding a new
ND option. Existing ND transport mechanisms (i.e., advertisements
and solicitations) are used. Advantages and disadvantages are almost
the same as those described in [DNS configuration RFC, RA section].
In addition, an advantage and disadvantages of distributing a policy
table are as follows.
Advantages:
- The RA message is used to deliver IPv6 address prefixes.
Therefore, delivering policies for selecting addresses with the
address attached to the host would be natural.
Disadvantages:
- The RA message is limited in size, and the RA may not be
sufficient to deliver full policies. The same compression
techniques, which were adopted in RFC4191 [RFC4191] can be used to
increase the number of policies delivered by RA messages.
- Currently, RA messages are not used between a PE and CPE. Other
protocols may be necessary to deliver a policy table.
- Configuring a policy table in each router that advertises RA
messages with an address prefix is necessary, so if a site has a
lot of routers, there will be a higher management cost.
- Delivering a specific policy table to one node is impossible
because RA messages are multicast.
A.2. Policy distribution in DHCPv6
By defining a new DHCPv6 option like
[I-D.fujisaki-dhc-addr-select-opt], a policy table can be delivered.
The advantages and disadvantages are almost the same as those
described in [DNS configuration RFC, DHCPv6 section].
In addition, there are the following advantages and disadvantages.
Advantages:
- Currently, DHCPv6 prefix delegation is mainly used between a PE
and CPE. Delivering a policy table with prefixes is possible.
- A DHCPv6 server can deliver a host-specific policy table.
- By using a DHCPv6 relay mechanism, managing a policy table from a
central server is possible.
Disadvantages:
- The DHCPv6 message size is limited to the maximum UDP transmission
size, so delivering complex policies by DHCPv6 may be impossible.
A.3. Using other protocols
Using other protocols (i.e., http and ftp) to deliver the policy
table is possible.
Advantages:
- No new transport mechanisms are necessary.
Disadvantages:
- Other service discovery mechanisms will be necessary.
- The procedure to distribute information should be defined (e.g.,
when to distribute and where the information is stored).
- Existing protocols may not have a mechanism to inform clients
about policy changes.
A.4. Defining a new protocol
Defining a new protocol to deliver a policy table will have the
following advantages and disadvantages.
Advantages:
- Defining a protocol suitable for policy distribution may be
possible.
Disadvantages:
- In addition to the disadvantages of 4.3, a new transport mechanism
needs to be defined.
A.5. Converting routing information to policy table
In an environment in which routing information and network links are
separated (e.g., between PE and CPE), converting routing information
to a policy table is possible. However, when intermediate routers
and nodes receive next-hop information, that is aggregated as a
default route or neighbor router, and cannot generate policy table [a
policy table cannot be generated].
Advantages:
- No new distribution mechanism is necessary.
Disadvantages:
- This mechanism can be used only in a limited environment.
7. References
7.1. Normative References
[I-D.arifumi-v6ops-addr-select-ps]
Matsumoto, A., "Problem Statement of Default Address Matsumoto, A., "Problem Statement of Default Address
Selection in Multi-prefix Environment: Operational Issues Selection in Multi-prefix Environment: Operational Issues
of RFC3484 Default Rules", of RFC3484 Default Rules",
draft-ietf-v6ops-addr-select-ps-00 (work in progress), draft-arifumi-v6ops-addr-select-ps-01 (work in progress),
November 2006. October 2006.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2. Informative References 7.2. Informative References
[I-D.arifumi-ipv6-policy-dist]
Matsumoto, A., "Practical Usages of Address Selection
Policy Distribution", draft-arifumi-ipv6-policy-dist-01
(work in progress), June 2006.
[I-D.bagnulo-rfc3484-update] [I-D.bagnulo-rfc3484-update]
Bagnulo, M., "Updating RFC 3484 for multihoming support", Bagnulo, M., "Updating RFC 3484 for multihoming support",
draft-bagnulo-rfc3484-update-00 (work in progress), draft-bagnulo-rfc3484-update-00 (work in progress),
June 2006. June 2006.
[I-D.fujisaki-dhc-addr-select-opt] [I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., "Distributing Default Address Selection Fujisaki, T., "Distributing Default Address Selection
Policy using DHCPv6", Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-02 (work in progress), draft-fujisaki-dhc-addr-select-opt-03 (work in progress),
June 2006. January 2007.
[I-D.ietf-shim6-failure-detection] [I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-06 (work in progress), draft-ietf-shim6-failure-detection-07 (work in progress),
September 2006. December 2006.
[I-D.ietf-shim6-locator-pair-selection] [I-D.ietf-shim6-locator-pair-selection]
Bagnulo, M., "Default Locator-pair selection algorithm for Bagnulo, M., "Default Locator-pair selection algorithm for
the SHIM6 protocol", the SHIM6 protocol",
draft-ietf-shim6-locator-pair-selection-01 (work in draft-ietf-shim6-locator-pair-selection-01 (work in
progress), October 2006. progress), October 2006.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Intec Netcore, Inc. Intec Netcore, Inc.
Shinsuna 1-3-3 Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075 Koto-ku, Tokyo 136-0075
Japan Japan
Phone: +81 3 5665 5069 Phone: +81 3 5665 5069
Email: kanayama@inetcore.com Email: kanayama@inetcore.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 39 change blocks. 
262 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/