One document matched: draft-arifumi-ipv6-policy-dist-00.txt
Network Working Group A. Matsumoto
Internet-Draft T. Fujisaki
Expires: June 4, 2006 J. Kato
NTT
Dec 1, 2005
Practical Usages of Default Address Selection Policy Distribution
draft-arifumi-ipv6-policy-dist-00.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 June 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes some practical usages of default address
selection policy distribution mechanism defined in another document.
Default address selection policies are originated by ISPs or by
network administrators and are delivered to each end node. These
policies are stored at end nodes in the form of default address
selection policy table. This mechanism is effective in many cases,
such as IPv4 and IPv6 dual-stack environment and other multiple
Matsumoto, et al. Expires June 4, 2006 [Page 1]
Internet-Draft Policy Table Distribution Dec 2005
address environment. Every end node is guided by the policy in
selecting an appropriate destination and source addresses.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Practical Use Example . . . . . . . . . . . . . . . . . . . . 3
2.1. Case 1: IPv4 and IPv6 prioritization . . . . . . . . . . . 3
2.2. Case 2: ULA or Global Prioritization . . . . . . . . . . . 5
2.3. Case 3: Multicast Source Address Selection . . . . . . . . 6
2.4. Case 4: Global-Closed Mixed Connectivity . . . . . . . . . 6
2.5. Case 5: Renumbering Site Prefix . . . . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Matsumoto, et al. Expires June 4, 2006 [Page 2]
Internet-Draft Policy Table Distribution Dec 2005
1. Introduction
This document describes some practical usages of the distribution
mechanism for default address selection policy that is defined in
another document. [T. Fujisaki]
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. Even
in those cases, you can make a host to select a correct address by
configuring address selection policy table correctly.
There is, however, no mechanism to automatically configure policy
table 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. So we propose a
mechanism to distribute address selection policy.
Our proposal is a new option for DHCPv6 [RFC3315] and its format is
defined in another document. This document illustrates practical
examples that benefit from our proposing protocol.
2. Practical Use Example
2.1. Case 1: IPv4 and IPv6 prioritization
The default policy for policy table gives IPv6 addresses higher
precedence than IPv4 addresses. There seems to be a lot of cases,
however, where network administrators want to control end nodes
address selection policy otherwise.
Matsumoto, et al. Expires June 4, 2006 [Page 3]
Internet-Draft Policy Table Distribution Dec 2005
+---------+
| 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. 1]
In the figure above, a site has native IPv4 and tunneled IPv6
connectivity. Therefore, the administrator of this site knows
communication quality of IPv6 is much worse than IPv4. This kind of
problem can be solved by applying the following policy table to
hosts.
Prefix Precedence Label
::/0 20 1
::ffff:0:0/96 10 2
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.
Matsumoto, et al. Expires June 4, 2006 [Page 4]
Internet-Draft Policy Table Distribution Dec 2005
2.2. Case 2: ULA or Global Prioritization
By default, the scope of these addresses is global. Also, unlike
site-locals, a site may have more than one of these prefixes and use
them at the same time. By making use of this characteristics, you
can achieve strong and simple access control. Like the figure below,
a web server has both ULA [RFC4193] and Global IPv6 addresses. A
host in this site also has both addresses.
By configuring client address based access control at the web server,
a client with ULA gets in internal only web pages and a client with
Global address gets access to only public web pages. As it is
relatively easy to reject packets with ULA source address getting
into the site at border router, this kind of access control seems to
be reliable.
+------+
| Host |
+-+--|-+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ Web | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80
| |
2001:db8:a::/48 | |
fc12:3456:789a::/48 | |
+----+----|+
| Gateway ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fc12:3456:789a:100:/64
--+-+---|-----
| |
+-+---|+ 2001:db8:a:100:EUI64
| Host | fc12:3456:789a:100:EUI64
+------+
[Fig. 2]
If you want to make in-site hosts to get into internal web site, you
should deliver the following policies to them from the gateway.
Matsumoto, et al. Expires June 4, 2006 [Page 5]
Internet-Draft Policy Table Distribution Dec 2005
Prefix Precedence Label
fc00::/7 20 1
::/0 10 2
2.3. Case 3: Multicast Source Address Selection
This case is an example of Site-local or Global prioritization. When
you send a multicast packet across site-borders, the source address
of the multicast packet has to be a global scope address. The
longest matching algorithm, however, selects a ULA address, if a
sending host has both an ULA and a global address.
The following policy fixes this incongruity. For site-scope
multicast, the destination address is in ff05::/16, and the source
address should be ULA. For global-scope multicast, the destination
address is in ff0e::/16, and the source address will be global
unicast address.
Prefix Precedence Label
ff05::/16 10 5
fc00::/7 10 5
ff0e::/16 10 6
2000::/3 10 6
This is surely a workaround. But, this clearly seems to be a defect
of the rules of RFC 3484 and this is supposed to be fixed sooner.
2.4. Case 4: Global-Closed Mixed Connectivity
You can see another typical source address selection problem in a
site with global-closed mixed connectivity like the figure below. In
this case, Host-A is in a multihomed network and has two IPv6
addresses delegated from each of up-stream ISPs. Note that ISP2 is
closed network and doesn't have connectivity to the Internet.
Matsumoto, et al. Expires June 4, 2006 [Page 6]
Internet-Draft Policy Table Distribution Dec 2005
+--------+
| 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)
+----+-+ +-+----+
DHCP-PD | | DHCP-PD
2001:db8:a::/48 | | 3ffe:1800:a::/48
++-------++
| Gateway |
+----+----+
| 2001:db8:a:1::/64
| 3ffe:1800:a:1::/64
DHCP |
------+---+----------
|
+--+-----+ 2001:db8:a:1:EUI64
| Host-A | 3ffe:1800:a:1:EUI64
+--------+
[Fig. 3]
Host-C is located somewhere in the Internet and has an IPv6 address
3ffe:503:c:1:EUI64. When Host-A sends a packet to Host-C, longest
matching algorithm chooses 3ffe:1800:a:1:EUI64 for the source
address. In this case, the packet goes through ISP1 and may be
filtered by ISP1's ingress filter. Even if the packet isn't filtered
by ISP1 fortunately, a return packet from Host-C won't possibly reach
at Host-A, because the return packet is destined for 3ffe:1800:a:1:
EUI64, which is closed from the Internet.
In this case, the source address selection problem will be solved, if
Host-A has the following policy table and the gateway has an
appropriate routing table.
Prefix Precedence Label
2001:db8::/32 10 100
::/0 10 100
2001:db8:a:1::/64 10 100
3ffe:1800::/32 10 200
3ffe:1800:a:1::/64 10 200
Matsumoto, et al. Expires June 4, 2006 [Page 7]
Internet-Draft Policy Table Distribution Dec 2005
2.5. Case 5: Renumbering Site Prefix
RFC 4192 [RFC4192] describes a recommended procedure to renumber a
network from one prefix to another. An auto-configured address has a
lifetime, so by stopping advertisement old prefix is invalidated
eventually.
However, you can make this transition more rapid and smooth by
injecting address selection policy like below.
|
+-----+---+
| 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. 4]
Prefix Precedence Label
2001:db8:a:1::/64 20 1
::/0 20 1
3ffe:1800:a:1::/64 10 2
In addition to whole site renumbering, partial site renumbering may
be getting more common. For example, ISP's customer prefix
renumbering may be helpful for privacy protection. This is common
with IPv4, but you can provide smooth renumbering in IPv6.
3. Security Considerations
With regard to the possibility of traffic abduction through the
announcement of a bogus policy, this scheme seems to neither lower
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.
Matsumoto, et al. Expires June 4, 2006 [Page 8]
Internet-Draft Policy Table Distribution Dec 2005
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
[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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[T. Fujisaki]
Fujisaki, T., Matsumoto, A., Kato, J., and S. Niinobe,
"Practical Usages of Default Address Selection Policy
Distribution", draft-fujisaki-dhc-addr-select-opt-01.txt.
(Work In Progress) (work in progress), Dec 1 2005.
6.2. Informative References
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
Matsumoto, et al. Expires June 4, 2006 [Page 9]
Internet-Draft Policy Table Distribution Dec 2005
Authors' Addresses
Arifumi Matsumoto
NTT PFLab
Midori-Cho 3-9-11
Mitaka City, Tokyo Prefecture 180-8585
JP
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Tomohiro Fujisaki
NTT PFLab
Midori-Cho 3-9-11
Mitaka City, Tokyo Prefecture 180-8585
JP
Phone: +81 422 59 7351
Email: fujisaki@syce.net
Jun-ya Kato
NTT PFLab
Midori-Cho 3-9-11
Mitaka City, Tokyo Prefecture 180-8585
JP
Phone: +81 422 59 2939
Email: kato@syce.net
Matsumoto, et al. Expires June 4, 2006 [Page 10]
Internet-Draft Policy Table Distribution Dec 2005
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 (2005). 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 June 4, 2006 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 06:03:29 |