Internet DRAFT - draft-arifumi-ipv6-policy-dist
draft-arifumi-ipv6-policy-dist
Network Working Group A. Matsumoto
Internet-Draft T. Fujisaki
Expires: December 21, 2006 J. Kato
S. Niinobe
NTT
June 19, 2006
Practical Usages of Address Selection Policy Distribution
draft-arifumi-ipv6-policy-dist-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes some practical usages of address selection
policy distribution mechanism defined in another document. Address
selection policies are originated by ISPs or by network
administrators and are delivered to each end host. These policies
are stored at end hosts in the form of default address selection
policy table. This mechanism enables central control of address
Matsumoto, et al. Expires December 21, 2006 [Page 1]
Internet-Draft Policy Table Distribution Usage June 2006
selection policy at end hosts, so it is essential or helpful in many
cases, such as IPv4 and IPv6 dual-stack environment and ULA and
Global address parallel-use environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Practical Use Example . . . . . . . . . . . . . . . . . . . . 3
2.1. Source Address Selection . . . . . . . . . . . . . . . . . 3
2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4
2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5
2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6
2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7
2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 7
2.1.6. Multicast Source Address Selection . . . . . . . . . . 8
2.1.7. Temporary Address Selection . . . . . . . . . . . . . 8
2.2. Destination Address Selection . . . . . . . . . . . . . . 9
2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9
2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 10
2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Matsumoto, et al. Expires December 21, 2006 [Page 2]
Internet-Draft Policy Table Distribution Usage June 2006
1. Introduction
IPv6 is originally designed to be able to have multiple addresses on
a network interface. RFC 3484 [RFC3484] defines some default rules
by which destination address and a source addresses are selected
among two or more addresses. Also, RFC 3484 address selection
mechanism is implemented on major OSes. However, we've found that
some important cases where those default rules aren't enough or even
evil.
We published a problem statement Internet Draft [I-D.arifumi-v6ops-
addr-select-ps] that illustrates various kinds of address selection
related problems. Almost all of these problems can be solved by a
built-in feature called "policy table" that is already defined in RFC
3484 and implemented in a lot of operating systems.
What is missing here is a method to centrally control end-hosts'
address selection behavior from outside of the host like routing
protocol for routing table. It is almost non-sense to force every
user to configure policy table manually, to inform users of
relatively large amount of policies and to make them change policy
table configuration every time the backbone topology or address space
changes.
We've proposed a method [I-D.fujisaki-dhc-addr-select-opt] to
distribute address selection policy to end-hosts, in the form of a
new option for DHCPv6 [RFC3315].
Our method is so versatile that can be used in a lot of environments
for a lot of purposes. This document describes some practical usages
of our method.
2. Practical Use Example
2.1. Source Address Selection
Matsumoto, et al. Expires December 21, 2006 [Page 3]
Internet-Draft Policy Table Distribution Usage June 2006
2.1.1. Multiple Routers on Single Interface
==================
| Internet |
==================
| |
2001:db8::/32 | | 3ffe:1800::/32
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:a::/48 | | 3ffe:1800:a::/48
+------+---+ +----+-----+
| Gateway1 | | Gateway2 |
+--------+-+ +-+--------+
| |
2001:db8:a:1::/64 | | 3ffe:1800:a:1::/64
| |
-----+-+-----+------
|
+-+----+ 2001:db8:a:1:EUI64
| Host | 3ffe:1800:a:1:EUI64
+------+
[Fig. 1]
To avoid wrong address selection and connection failure, one approach
is to configure correctly both the routing table and address policy
table at Host. You can use RFC 4191 [RFC4191] to deliver routing
information to hosts.
When the Host selects Gateway1 for its default route and each ISP
distributes its address block,
Prefix Precedence Label
2001:db8::/32 20 1
::/0 20 1
3ffe:1800:/32 10 2
Another approach is to configure the gateways but not the Host and
make use of packet redirection based on the source address between
the gateways.
Matsumoto, et al. Expires December 21, 2006 [Page 4]
Internet-Draft Policy Table Distribution Usage June 2006
2.1.2. Ingress Filtering Problem
==================
| Internet |
==================
| |
2001:db8::/32 | | 3ffe:1800::/32
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:a::/48 | | 3ffe:1800:a::/48
++-------++
| Gateway |
+----+----+
| 2001:db8:a:1::/64
| 3ffe:1800:a:1::/64
------+---+----------
|
+-+----+ 2001:db8:a:1:EUI64
| Host | 3ffe:1800:a:1:EUI64
+------+
[Fig. 2]
In this example, as far as Gateway1 doesn't adopt source-address-
based routing, the Host has to select an appropriate source address
in accordance with Gateway's routing policy. The Gateway can notify
its routing policy in the form of policy table like below. Here the
Gateway selects ISP1 for its default route.
Prefix Precedence Label
2001:db8::/32 20 1
::/0 20 1
3ffe:1800:/32 10 2
Matsumoto, et al. Expires December 21, 2006 [Page 5]
Internet-Draft Policy Table Distribution Usage June 2006
2.1.3. Half-Closed Network Problem
+--------+
| Host-C | 3ffe:503:c:1:EUI64
+-----+--+
|
============== +--------+
| Internet | | Host-B | 3ffe:1800::EUI64
============== +--------+
| |
2001:db8::/32 | | 3ffe:1800::/32
+----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+
| |
2001:db8:a::/48 | | 3ffe:1800:a::/48
++-------++
| Gateway |
+----+----+
| 2001:db8:a:1::/64
| 3ffe:1800:a:1::/64
------+---+----------
|
+--+-----+ 2001:db8:a:1:EUI64
| Host-A | 3ffe:1800:a:1:EUI64
+--------+
[Fig. 3]
To avoid wrong address selection to Host-C, Gateway have to
distribute the following policy to Host-A. In this case The longest
matching algorithm always chooses the wrong address.
Prefix Precedence Label
2001:db8::/32 10 1
::/0 10 1
3ffe:1800::/32 10 2
Only the ISP1 and ISP2 know what policy Host-A should have, so we
propose that ISPs should deliver their policy information to their
customers in the form of DHCPv6 option that we stated above.
Matsumoto, et al. Expires December 21, 2006 [Page 6]
Internet-Draft Policy Table Distribution Usage June 2006
2.1.4. Combined Use of Global and ULA
+--------+
| Host-C | 8000:db8::1
+-----+--+
|
============
| Internet |
============
|
|
+----+----+
| ISP |
+----+----+
|
2001:db8:a::/48 |
+----+----+
| Gateway |
+-+-----+-+
| | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3:100:/64
-----+--+- -+--+----
| |
fd01:2:3:200:EUI64 | | 2001:db8:a:100:EUI64
+----+----+ +-+------+ fd01:2:3:100:EUI64
| Printer | | Host-A |
+---------+ +--------+
[Fig. 4]
In a few years the longest matching rule will not be able to choose
the correct address anymore: the moment the assignment of those
Global Unicast Addresses whose beginning bit is 1 starts.
So, to avoid connection failure between Host-A and Host-C in this
figure the site administrator should distribute the following policy.
Prefix Precedence Label
fd01:2:3::/48 20 1
2001:db8:a::/48 10 2
::/0 10 2
2.1.5. Site Renumbering
It takes a long time to invalidate the old prefix. Also you cannot
stop routing to the old prefix because there could be a long-lived
TCP or UDP session that uses the old prefix.
Matsumoto, et al. Expires December 21, 2006 [Page 7]
Internet-Draft Policy Table Distribution Usage June 2006
+-----+---+
| Gateway |
+----+----+
| 2001:db8:a:1::/64 (new)
| 3ffe:1800:a:1::/64 (old)
------+---+----------
|
+--+-----+ 2001:db8:a:1:EUI64 (new)
| Host-A | 3ffe:1800:a:1:EUI64 (old)
+--------+
[Fig. 5]
Prefix Precedence Label
2001:db8:a:1::/64 20 1
::/0 20 1
3ffe:1800:a:1::/64 10 2
2.1.6. Multicast Source Address Selection
The longest matching algorithm selects a ULA [RFC4193] address if the
sending host has both a ULA and a global address. This behavior is
not always desirable. It depends on the usage and the routing policy
of ULA. If the source address of the multicast packets should not be
ULA, you have to configure policy table accordingly.
The policy below selects ULA for site-local multicast address and
global unicast address for global-scope multicast address.
Prefix Precedence Label
ff05::/16 10 1
fc00::/7 10 1
ff0e::/16 10 2
2000::/3 10 2
2.1.7. Temporary Address Selection
For now you do not have a method to control usage policy of temporary
address other than specifying a temporary address at 128bit prefix
length and keeping the entry up-to-date according to the change of
the temporary address.
There are a lot of cases that we want to control the usage of
temporary address more minutely, so it is desirable to make policy
table support temporary address description.
Matsumoto, et al. Expires December 21, 2006 [Page 8]
Internet-Draft Policy Table Distribution Usage June 2006
2.2. Destination Address Selection
2.2.1. IPv4 or IPv6 prioritization
The default policy table gives IPv6 addresses higher precedence than
IPv4 addresses.
+---------+
| Tunnel |
| Service |
+--+---++-+
| ||
| ||
===========||==
| Internet || |
===========||==
| ||
10.2.0.0/16 | ||
+----+-+ ||
| ISP | ||
+----+-+ ||
| ||
IPv4 (Native) | || IPv6 (Tunnel)
10.2.30.0/32 | ||
++-----++-+
| Gateway |
+----+----+
| 2001:db8:a:1::/64
| 192.168.0.0/24
|
------+---+----------
|
+-+----+ 2001:db8:a:1:EUI64
| Host | 192.168.0.100
+------+
[Fig. 6]
In the figure above, a site has native IPv4 and tunneled IPv6
connectivity. Therefore, the administrator may want to set a higher
priority for using IPv4 than using IPv6 because the quality of the
tunnel network seems to be worse than that of the native transport.
Prefix Precedence Label
::/0 20 1
::ffff:0:0/96 10 2
Matsumoto, et al. Expires December 21, 2006 [Page 9]
Internet-Draft Policy Table Distribution Usage June 2006
The administrator can indicate that IPv4 should take precedence over
IPv6, while keeping to provide both IPv4 and IPv6 connectivity, by
delivering DHCPv6 Default Address Selection Option that includes the
policy above.
2.2.2. ULA and IPv4 dual-stack environment
When the Host below tries to connect to Host-C that has registered
both A and AAAA records in the DNS, the host will choose AAAA as the
destination address and ULA for the source address. This will
clearly result in a connection failure.
+--------+
| Host-C | AAAA = 2001:db8::80
+-----+--+ A = 192.47.163.1
|
============
| Internet |
============
| no IPv6 connectivity
+----+-+
| ISP |
+----+-+
|
| fd01:2:3::/48 (ULA)
| 10.2.0.0/16
IPv4 NAT ++--------+
| Gateway |
+----+----+
| fd01:2:3:4::/64 (ULA)
| 192.168.0.0/24
------+---+----------
|
+-+----+ fd01:2:3:4::100 (ULA)
| Host | 192.168.0.100
+------+
[Fig. 7]
The policy below enables IPv6 communication within the ISP. Outside
of the ISP IPv4 communication has highor priority than IPv6.
Prefix Precedence Label
fd01:2:3::/48 30 3
::ffff:0:0/96 20 2
::/0 10 1
Matsumoto, et al. Expires December 21, 2006 [Page 10]
Internet-Draft Policy Table Distribution Usage June 2006
2.2.3. ULA or Global Prioritization
ULA and IPv6 global address both have global scope, and default rules
do not specify which address should be given priority. This point
makes IPv6 implementation of address-based service differentiation a
bit harder.
+------+
| Host |
+-+--|-+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fd01:2:3::80
| |
2001:db8:a::/48 | |
fd01:2:3:::/48 | |
+----+----|+
| Gateway ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fd01:2:3:100:/64
--+-+---|-----
| |
+-+---|+ 2001:db8:a:100:EUI64
| Host | fd01:2:3:100:EUI64
+------+
[Fig. 7]
If you want to make in-site hosts to get information of DNS internal
zone, you should deliver the following policies to them from the
gateway.
Prefix Precedence Label
fd01:2:3::/48 20 1
::/0 10 2
3. Security Considerations
With regard to the possibility of traffic abduction through the
announcement of a bogus policy, this scheme seems to neither lower
Matsumoto, et al. Expires December 21, 2006 [Page 11]
Internet-Draft Policy Table Distribution Usage June 2006
nor raise the security level obtained by the existing base-protocols,
such as DHCP-PD, DHCP and RA. However, it does raise the possibility
of a new form of DoS attack on routers and hosts, in which large
numbers of address-selection policies are generated by different
source addresses. We will have to discuss this and take
precautionary measures in designing the protocol specification.
4. IANA Considerations
This document has no actions for IANA.
5. Acknowledgement
Many thanks to Tim Chown, Iljitsch, Changming and Shin Miyagawa for
detailed feedbacks and discussions on this document. We really
appreciate all the members in our laboratory for their contributions.
6. References
6.1. Normative References
[I-D.arifumi-v6ops-addr-select-ps]
Matsumoto, A., "Problem Statement of Default Address
Selection in Multi-prefix Environment: Operational Issues
of RFC3484 Default Rules",
draft-arifumi-v6ops-addr-select-ps-00 (work in progress),
June 2006.
[I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., "Distributing Default Address Selection
Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-02 (work in progress),
June 2006.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
6.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
Matsumoto, et al. Expires December 21, 2006 [Page 12]
Internet-Draft Policy Table Distribution Usage June 2006
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
Appendix A. Revision History
00-version (2005.12.1): Initial version.
01-version (2006.6.19): Some cases were added in accordance with
the problem statement I-D.
Matsumoto, et al. Expires December 21, 2006 [Page 13]
Internet-Draft Policy Table Distribution Usage June 2006
Authors' Addresses
Arifumi Matsumoto
NTT PFLab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Tomohiro Fujisaki
NTT PFLab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7351
Email: fujisaki@lab.ntt.co.jp
Jun-ya Kato
NTT PFLab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 2939
Email: kato@syce.net
Shirou Niinobe
NTT PFLab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 4949
Email: nin@syce.net
Matsumoto, et al. Expires December 21, 2006 [Page 14]
Internet-Draft Policy Table Distribution Usage June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Matsumoto, et al. Expires December 21, 2006 [Page 15]
