draft-ietf-v6ops-addr-select-ps-04.txt   draft-ietf-v6ops-addr-select-ps-05.txt 
IPv6 Operations Working Group A. Matsumoto IPv6 Operations Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Informational NTT Intended status: Informational NTT
Expires: August 28, 2008 R. Hiromi Expires: October 24, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
February 25, 2008 April 22, 2008
Problem Statement of Default Address Selection in Multi-prefix Problem Statement of Default Address Selection in Multi-prefix
Environment: Operational Issues of RFC3484 Default Rules Environment: Operational Issues of RFC3484 Default Rules
draft-ietf-v6ops-addr-select-ps-04.txt draft-ietf-v6ops-addr-select-ps-05.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 38 skipping to change at page 1, line 38
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 August 28, 2008. This Internet-Draft will expire on October 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
One physical link can carry multiple subnets. Moreover, we can use One physical link can carry multiple subnets. Moreover, we can use
multiple physical networks at the same time in a host. In that multiple physical networks at the same time in a host. In that
environment, end hosts might have multiple IP addresses and be environment, end hosts might have multiple IP addresses and be
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Source Address Selection . . . . . . . . . . . . . . . . . 3 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 3
2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4
2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5
2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 5 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 5
2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7 2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7
2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 8 2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 8
2.1.6. Multicast Source Address Selection . . . . . . . . . . 8 2.1.6. Multicast Source Address Selection . . . . . . . . . . 8
2.1.7. Temporary Address Selection . . . . . . . . . . . . . 8 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9
2.2. Destination Address Selection . . . . . . . . . . . . . . 9 2.2. Destination Address Selection . . . . . . . . . . . . . . 9
2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9
2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 10 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 10
2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 10 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 11
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Appendix. Revision History . . . . . . . . . . . . . 13 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
One physical link can carry multiple subnets. In that case, an end- One physical link can carry multiple subnets. In that case, an end-
host has multiple IP addresses. In the IPv4-IPv6 dual stack host has multiple IP addresses. In the IPv4-IPv6 dual stack
environment or in a site connected to both a ULA [RFC4193] and Global environment or in a site connected to both a ULA [RFC4193] and Global
scope networks, an end-host has multiple IP addresses. These are scope networks, an end-host has multiple IP addresses. These are
examples of networks that we focus on in this document. In such an examples of networks that we focus on in this document. In such an
environment, an end-host will encounter some communication troubles. environment, an end-host will encounter some communication troubles.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
Host-C is located somewhere on the Internet and has IPv6 address Host-C is located somewhere on the Internet and has IPv6 address
2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest
matching algorithm chooses 2001:db8:8000:1::100 for the source matching algorithm chooses 2001:db8:8000:1::100 for the source
address. In this case, the packet goes through ISP1 and may be address. In this case, the packet goes through ISP1 and may be
filtered by ISP1's ingress filter. Even if the packet is not filtered by ISP1's ingress filter. Even if the packet is not
filtered by ISP1, a return packet from Host-C cannot possibly be filtered by ISP1, a return packet from Host-C cannot possibly be
delivered to Host-A because the return packet is destined for 2001: delivered to Host-A because the return packet is destined for 2001:
db8:8000:1::100, which is closed from the Internet. db8:8000:1::100, which is closed from the Internet.
The important point is that each host chooses a correct source The important point is that each host chooses a correct source
address for a given destination address as long as NAT does not exist address for a given destination address. To solve this kind of
in the IPv6 world. To solve this kind of network policy based network policy based address selection problems, it is likely that
address selection problems, it is likely that delivering addtional delivering addtional information to a node fits better than
information to a node fits better than algorithmic solutions that are algorithmic solutions that are local to the node.
local to the node.
2.1.4. Combined Use of Global and ULA 2.1.4. Combined Use of Global and ULA
============ ============
| Internet | | Internet |
============ ============
| |
| |
+----+----+ +----+----+
| ISP | | ISP |
skipping to change at page 7, line 38 skipping to change at page 7, line 37
+----+----+ +-+----+ fd01:2:3:100::100 +----+----+ +-+----+ fd01:2:3:100::100
| Printer | | Host | | Printer | | Host |
+---------+ +------+ +---------+ +------+
[Fig. 4] [Fig. 4]
As NAP [I-D.ietf-v6ops-nap] describes, using a ULA may be beneficial As NAP [I-D.ietf-v6ops-nap] describes, using a ULA may be beneficial
in some scenarios. If the ULA is used for internal communication, in some scenarios. If the ULA is used for internal communication,
packets with ULA need to be filtered at the Router. packets with ULA need to be filtered at the Router.
There is no serious problem related to address selection in this This case does not presently create an address selection problem
case, because of the dissimilarity between the ULA and the Global because of the dissimilarity between the ULA and the Global Unicast
Unicast Address. The longest matching rule of RFC 3484 chooses the Address. The longest matching rule of RFC 3484 chooses the correct
correct address for both intra-site and extra-site communication. address for both intra-site and extra-site communication.
In the future, however, there is a possibility that the longest In the future, however, there is a possibility that the longest
matching rule will not be able to choose the correct address anymore. matching rule will not be able to choose the correct address anymore.
That is the moment when the assignment of those Global Unicast That is the moment when the assignment of those Global Unicast
Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291],
almost all address spaces of IPv6, including those whose first bit is almost all address spaces of IPv6, including those whose first bit is
1, are assigned as Global Unicast Addresses. 1, are assigned as Global Unicast Addresses.
Namely, when we start to assign a part of the address block 8000::/1 Namely, when we start to assign a part of the address block 8000::/1
as the global unicast address and that part is used somewhere in the as the global unicast address and that part is used somewhere in the
Internet, the longest matching rule ceases to function properly for Internet, the longest matching rule ceases to function properly for
the people trying to connect to the servers with those addresses. the people trying to connect to the servers with those addresses.
For example, when the destination host has an IPv6 address 8000::1,
and the originating host has 2001:db8::1 and fd0:1::1, the source
address will be fd00:1::1, because the longest matching bit length is
0 for 2001:db8::1 and 1 for fd0:1::1 respectively.
2.1.5. Site Renumbering 2.1.5. Site Renumbering
RFC 4192 [RFC4192] describes a recommended procedure for renumbering RFC 4192 [RFC4192] describes a recommended procedure for renumbering
a network from one prefix to another. An autoconfigured address has a network from one prefix to another. An autoconfigured address has
a lifetime, so by stopping advertisement of the old prefix, the a lifetime, so by stopping advertisement of the old prefix, the
autoconfigured address is eventually invalidated. autoconfigured address is eventually invalidated.
However, invalidating the old prefix takes a long time. You cannot However, invalidating the old prefix takes a long time. You cannot
stop routing to the old prefix as long as the old prefix is not stop routing to the old prefix as long as the old prefix is not
removed from the host. This can be a tough issue for ISP network removed from the host. This can be a tough issue for ISP network
administrators. administrators.
There is a technique of advertising the prefix with the preferred There is a technique of advertising the prefix with the preferred
lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 allows the use of a lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 does not absolutely
deprecated address for a new outgoing connection. So, this technique prohibit the use of a deprecated address for a new outgoing
isn't always perfect. connection due to limitations relating to what applications are
capable of doing."
+-----+---+ +-----+---+
| Router | | Router |
+----+----+ +----+----+
| 2001:db8:b::/64 (new) | 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old) | 2001:db8:a::/64 (old)
------+---+---------- ------+---+----------
| |
+--+-----+ 2001:db8:b::100 (new) +--+-----+ 2001:db8:b::100 (new)
| Host-A | 2001:db8:a::100 (old) | Host-A | 2001:db8:a::100 (old)
+--------+ +--------+
[Fig. 5] [Fig. 5]
2.1.6. Multicast Source Address Selection 2.1.6. Multicast Source Address Selection
This case is an example of Site-local or Global prioritization. When This case is an example of site-local or global prioritization. When
you send a multicast packet across site-borders, the source address you send a multicast packet across site-borders, the source address
of the multicast packet should be a globally routable address. The of the multicast packet should be a globally routable address. The
longest matching algorithm, however, selects a ULA if the sending longest matching algorithm, however, selects a ULA if the sending
host has both a ULA and a global address. host has both a ULA and a Global Unicast Address.
2.1.7. Temporary Address Selection 2.1.7. Temporary Address Selection
RFC 3041 [RFC3041] defines a Temporary Address. The usage of a RFC 3041 [RFC3041] defines a Temporary Address. The usage of a
Temporary Address has both pros and cons. That is good for viewing Temporary Address has both pros and cons. That is good for viewing
web pages or communicating with the general public, but that is bad web pages or communicating with the general public, but that is bad
for a service that uses address-based authentication and for logging for a service that uses address-based authentication and for logging
purposes. purposes.
If you could turn the temporary address on and off, that would be If you could turn the temporary address on and off, that would be
better. If you could switch its usage per service (destination better. If you could switch its usage per service (destination
address), that would also be better. The same situation can be found address), that would also be better. The same situation can be found
when using HA (home address) and CoA (care-of address)in a Mobile when using HA (home address) and CoA (care-of address)in a Mobile
IPv6 [RFC3775] network. IPv6 [RFC3775] network.
At the Future Work section in RFC 3041, it discusses that the API
extension might be necessary to achieve better address selection
mechanism with finer granularity.
2.2. Destination Address Selection 2.2. Destination Address Selection
2.2.1. IPv4 or IPv6 prioritization 2.2.1. IPv4 or IPv6 prioritization
The default policy table gives IPv6 addresses higher precedence than The default policy table gives IPv6 addresses higher precedence than
IPv4 addresses. There seem to be many cases, however, where network IPv4 addresses. There seem to be many cases, however, where network
administrators want to control the address selection policy of end- administrators want to control the address selection policy of end-
hosts the other way around. hosts the other way around.
+---------+ +---------+
skipping to change at page 13, line 35 skipping to change at page 14, line 29
01: 01:
IP addresse notations changed to docmentation address. IP addresse notations changed to docmentation address.
Descriptoin of solutions deleted. Descriptoin of solutions deleted.
02: 02:
Security considerations section rewritten according to comments Security considerations section rewritten according to comments
from SECDIR. from SECDIR.
03: 03:
Intended status changed to Informational. Intended status changed to Informational.
04: 04:
This version reflects comments from IESG members. This version reflects comments from IESG members.
05:
This version reflects comments from IESG members and Bob Hinden.
Authors' Addresses Authors' Addresses
Arifumi Matsumoto Arifumi Matsumoto
NTT PF Lab NTT PF Lab
Midori-Cho 3-9-11 Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3334 Phone: +81 422 59 3334
 End of changes. 15 change blocks. 
28 lines changed or deleted 39 lines changed or added

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