draft-ietf-v6ops-addr-select-ps-03.txt   draft-ietf-v6ops-addr-select-ps-04.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: July 31, 2008 R. Hiromi Expires: August 28, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
January 28, 2008 February 25, 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-03.txt draft-ietf-v6ops-addr-select-ps-04.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 July 31, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
One physical network can carry multiple logical networks. Moreover, One physical link can carry multiple subnets. Moreover, we can use
we can use multiple physical networks at the same time in a host. In multiple physical networks at the same time in a host. In that
that environment, end hosts might have multiple IP addresses and be environment, end hosts might have multiple IP addresses and be
required to use them selectively. Without an appropriate source/ required to use them selectively. Without an appropriate source/
destination address selection mechanism, the host will experience destination address selection mechanism, the host will experience
some trouble in communication. RFC 3484 defines both the source and some trouble in communication. RFC 3484 defines default source and
destination address selection algorithms, but the multi-prefix destination address selection algorithms, but the multi-prefix
environment considered here needs additional rules beyond those of environment considered here needs additional rules beyond those of
the default operation. This document describes the possible problems the default operation. This document describes the possible problems
that end hosts could encounter in an environment with multiple that end hosts could encounter in an environment with multiple
logical networks. subnets.
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. 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 . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 8
2.2. Destination Address Selection . . . . . . . . . . . . . . 8 2.2. Destination Address Selection . . . . . . . . . . . . . . 9
2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 8 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9
2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 9 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 . . . . . . . . . . . . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Appendix. Revision History . . . . . . . . . . . . . 13 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
One physical network can carry multiple logical networks. In that One physical link can carry multiple subnets. In that case, an end-
case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual host has multiple IP addresses. In the IPv4-IPv6 dual stack
stack environment or in a site connected to both a ULA [RFC4193] and environment or in a site connected to both a ULA [RFC4193] and Global
Global scope networks, an end-host has multiple IP addresses. These scope networks, an end-host has multiple IP addresses. These are
are examples of networks that we focus on in this document. In such examples of networks that we focus on in this document. In such an
an environment, an end-host will encounter some communication environment, an end-host will encounter some communication troubles.
trouble.
Inappropriate source address selection at the end-host causes Inappropriate source address selection at the end-host causes
unexpected asymmetric routing, filtering by a router or discarding of unexpected asymmetric routing, filtering by a router or discarding of
packets bacause there is no route to the host. packets bacause there is no route to the host.
Considering a multi-prefix environment, destination address selection Considering a multi-prefix environment, destination address selection
is also important for correct or better communication establishment. is also important for correct or better communication establishment.
RFC 3484 [RFC3484] defines both source and destination address RFC 3484 [RFC3484] defines default source and destination address
selection algorithms. In most cases, the host will be able to selection algorithms. In most cases, the host will be able to
communicate with the targeted host using the algorithms. However, communicate with the targeted host using the algorithms. However,
there are still problematic cases such as when multiple default there are still problematic cases. This document describes such
routes are supplied. This document describes such possibilities of possibilities of incorrect address selection, which leads to dropping
incorrect address selection, which leads to dropping packets and packets and communication failure.
communication failure.
In addition, the provision of an address policy table is an important
matter. RFC 3484 describes all the algorithms for setting the
address policy table but address policy provisions are not mentioned.
RFC 3484 only defines how to configure the address policy table
manually.
1.1. Scope of this document 1.1. Scope of this document
There has been a lot of discussion about "multiple addresses/ There has been a lot of discussion about "multiple addresses/
prefixes" but the multi-homing techniques for achieving redundancy prefixes". As other mechanisms already exists, the multi-homing
are out of our scope. Cooperation with a mechanism like shim6 is techniques for achieving redundancy are out of our scope.
rather desirable. We focus on an end-site network environment. The
scope of this document is to sort out problematic cases of false We focus on an end-site network environment. The scope of this
dropping of the address selection within a multi-prefix environment. document is to sort out problematic cases related to address
selection. It includes problems that cannot always be solved by
changing the host's address selection algorithm, such as an address
selection mechanism that depends on the IPv6 address types. For
example, a global address isn't always globally routable and ULA's
routable domain is dependent on the network policy. This document
includes these kind of network policy related address selection
problems, as long as these problems are serious enough and worth
solving.
2. Problem Statement 2. Problem Statement
2.1. Source Address Selection 2.1. Source Address Selection
2.1.1. Multiple Routers on Single Interface 2.1.1. Multiple Routers on Single Interface
================== ==================
| Internet | | Internet |
================== ==================
| | | |
2001:db8:1000::/36 | | 2001:db8:8000::/36 2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+ +----+-+ +-+----+
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+----+-+ +-+----+ +----+-+ +-+----+
| | | |
2001:db8:1000:::/48 | | 2001:db8:8000::/48 2001:db8:1000:::/48 | | 2001:db8:8000::/48
+------+---+ +----+-----+ +-----+---+ +----+----+
| Gateway1 | | Gateway2 | | Router1 | | Router2 |
+--------+-+ +-+--------+ +-------+-+ +-+-------+
| | | |
2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64 2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64
| | | |
-----+-+-----+------ -----+-+-----+------
| |
+-+----+ 2001:db8:1000:1::EUI64 +-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::EUI64 | Host | 2001:db8:8000:1::100
+------+ +------+
[Fig. 1] [Fig. 1]
Generally speaking, there is no interaction between next-hop Generally speaking, there is no interaction between next-hop
determination and address selection. In this example, when a Host determination and address selection. In this example, when a host
sends a packet via Gateway1, the Host does not necessarily choose sends a packet via Router1, the host does not necessarily choose
address 2001:db8:1000:1::EUI64 given by Gateway1 as the source address 2001:db8:1000:1::100 given by Router1 as the source address.
address. This causes the same problem as described in the next This causes the same problem as described in the next section
section 'Ingress Filtering Problem'. 'Ingress Filtering Problem'.
2.1.2. Ingress Filtering Problem 2.1.2. Ingress Filtering Problem
================== ==================
| Internet | | Internet |
================== ==================
| | | |
2001:db8:1000::/36 | | 2001:db8:8000::/36 2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+ +----+-+ +-+----+
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+----+-+ +-+----+ +----+-+ +-+----+
| | | |
2001:db8:1000:::/48 | | 2001:db8:8000::/48 2001:db8:1000:::/48 | | 2001:db8:8000::/48
++-------++ ++-------++
| Gateway | | Router |
+----+----+ +----+----+
| 2001:db8:1000:1::/64 | 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64 | 2001:db8:8000:1::/64
------+---+---------- ------+---+----------
| |
+-+----+ 2001:db8:1000:1::EUI64 +-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::EUI64 | Host | 2001:db8:8000:1::100
+------+ +------+
[Fig. 2] [Fig. 2]
When a relatively small site, which we call a "customer network", is When a relatively small site, which we call a "customer network", is
attached to two upstream ISPs, each ISP delegates a network address attached to two upstream ISPs, each ISP delegates a network address
block, which is usually /48, and a host has multiple IPv6 addresses. block, which is usually /48, and a host has multiple IPv6 addresses.
When the source address of an outgoing packet is not the one that is When the source address of an outgoing packet is not the one that is
delegated by an upstream ISP, there is a possibility that the packet delegated by an upstream ISP, there is a possibility that the packet
will be dropped at the ISP by its Ingress Filter. Ingress will be dropped at the ISP by its Ingress Filter. Ingress
filtering(uRPF: unicast Reverse Path Forwarding) is becoming more filtering(uRPF: unicast Reverse Path Forwarding) is becoming more
popular among ISPs to mitigate the damage of DoS attacks. popular among ISPs to mitigate the damage of DoS attacks.
In this example, when the Gateway chooses the default route to ISP2 In this example, when the Router chooses the default route to ISP2
and the Host chooses 2001:db8:1000:1::EUI64 as the source address for and the Host chooses 2001:db8:1000:1::100 as the source address for
packets sent to a host (2001:db8:2000::1) somewhere on the Internet, packets sent to a host (2001:db8:2000::1) somewhere on the Internet,
the packets may be dropped at ISP2 because of Ingress Filtering. the packets may be dropped at ISP2 because of Ingress Filtering.
2.1.3. Half-Closed Network Problem 2.1.3. Half-Closed Network Problem
You can see a second typical source address selection problem in a You can see a second typical source address selection problem in a
multihome site with global-closed mixed connectivity like in the multihome site with global-closed mixed connectivity like in the
figure below. In this case, Host-A is in a multihomed network and figure below. In this case, Host-A is in a multihomed network and
has two IPv6 addresses, one delegated from each of the upstream ISPs. has two IPv6 addresses, one delegated from each of the upstream ISPs.
Note that ISP2 is a closed network and does not have connectivity to Note that ISP2 is a closed network and does not have connectivity to
skipping to change at page 6, line 20 skipping to change at page 6, line 20
| Internet | | Host-B | 2001:db8:8000::1 | Internet | | Host-B | 2001:db8:8000::1
============== +--------+ ============== +--------+
| | | |
2001:db8:1000:/36 | | 2001:db8:8000::/36 2001:db8:1000:/36 | | 2001:db8:8000::/36
+----+-+ +-+---++ +----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel) | ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+ +----+-+ +-+----+
| | | |
2001:db8:1000:/48 | | 2001:db8:8000::/48 2001:db8:1000:/48 | | 2001:db8:8000::/48
++-------++ ++-------++
| Gateway | | Router |
+----+----+ +----+----+
| 2001:db8:1000:1::/64 | 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64 | 2001:db8:8000:1::/64
------+---+---------- ------+---+----------
| |
+--+-----+ 2001:db8:1000:1::EUI64 +--+-----+ 2001:db8:1000:1::100
| Host-A | 2001:db8:8000:1::EUI64 | Host-A | 2001:db8:8000:1::100
+--------+ +--------+
[Fig. 3] [Fig. 3]
You do not need two physical network connections here. The You do not need two physical network connections here. The
connection from the Gateway to ISP2 can be a logical link over ISP1 connection from the Router to ISP2 can be a logical link over ISP1
and the Internet. and the Internet.
When Host-A starts the connection to Host-B in ISP2, the source When Host-A starts the connection to Host-B in ISP2, the source
address of a packet that has been sent will be the one delegated from address of a packet that has been sent will be the one delegated from
ISP2, that is 2001:db8:8000:1::EUI64, because of rule 8 (longest ISP2, that is 2001:db8:8000:1::100, because of rule 8 (longest
matching prefix) in RFC 3484. matching prefix) in RFC 3484.
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::EUI64 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::EUI64, 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 as long as NAT does not exist
in the IPv6 world. in the IPv6 world. To solve this kind of network policy based
address selection problems, it is likely that delivering addtional
information to a node fits better than algorithmic solutions that are
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 |
+----+----+ +----+----+
| |
2001:db8:a::/48 | 2001:db8:a::/48 |
+----+----+ +----+----+
| Gateway | | Router |
+-+-----+-+ +-+-----+-+
| | 2001:db8:a:100::/64 | | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3: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:200::101 | | 2001:db8:a:100::100
+----+----+ +-+----+ fd01:2:3:100::EUI64 +----+----+ +-+----+ 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 Gateway. packets with ULA need to be filtered at the Router.
There is no serious problem related to address selection in this There is no serious problem related to address selection in this
case, because of the dissimilarity between the ULA and the Global case, because of the dissimilarity between the ULA and the Global
Unicast Address. The longest matching rule of RFC 3484 chooses the Unicast Address. The longest matching rule of RFC 3484 chooses the
correct address for both intra-site and extra-site communication. correct address for both intra-site and extra-site communication.
In a few years, however, the longest matching rule will not be able In the future, however, there is a possibility that the longest
to choose the correct address anymore. That is the moment when the matching rule will not be able to choose the correct address anymore.
assignment of those Global Unicast Addresses starts, where the first That is the moment when the assignment of those Global Unicast
bit is 1. In RFC 4291 [RFC4291], almost all address spaces of IPv6, Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291],
including those whose first bit is 1, are assigned as Global Unicast almost all address spaces of IPv6, including those whose first bit is
Addresses. 1, are assigned as Global Unicast Addresses.
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
Internet, the longest matching rule ceases to function properly for
the people trying to connect to the servers with those addresses.
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
lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 allows the use of a
deprecated address for a new outgoing connection. So, this technique
isn't always perfect.
+-----+---+ +-----+---+
| Gateway | | Router |
+----+----+ +----+----+
| 2001:db8:b::/64 (new) | 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old) | 2001:db8:a::/64 (old)
------+---+---------- ------+---+----------
| |
+--+-----+ 2001:db8:b::EUI64 (new) +--+-----+ 2001:db8:b::100 (new)
| Host-A | 2001:db8:a::EUI64 (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 must be a global scope address. The longest of the multicast packet should be a globally routable address. The
matching algorithm, however, selects a ULA if the sending host has longest matching algorithm, however, selects a ULA if the sending
both a ULA and a global address. host has both a ULA and a global 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 and CoA in a MobileIP network. when using HA (home address) and CoA (care-of address)in a Mobile
IPv6 [RFC3775] network.
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 9, line 23 skipping to change at page 9, line 38
===========||== ===========||==
| || | ||
192.0.2.0/24 | || 192.0.2.0/24 | ||
+----+-+ || +----+-+ ||
| ISP | || | ISP | ||
+----+-+ || +----+-+ ||
| || | ||
IPv4 (Native) | || IPv6 (Tunnel) IPv4 (Native) | || IPv6 (Tunnel)
192.0.2.0/26 | || 192.0.2.0/26 | ||
++-----++-+ ++-----++-+
| Gateway | | Router |
+----+----+ +----+----+
| 2001:db8:a:1::/64 | 2001:db8:a:1::/64
| 192.0.2.0/28 | 192.0.2.0/28
| |
------+---+---------- ------+---+----------
| |
+-+----+ 2001:db8:a:1:EUI64 +-+----+ 2001:db8:a:1::100
| Host | 192.0.2.2 | Host | 192.0.2.2
+------+ +------+
[Fig. 6] [Fig. 6]
In the figure above, a site has native IPv4 and tunneled-IPv6 In the figure above, a site has native IPv4 and tunneled-IPv6
connectivity. Therefore, the administrator may want to set a higher connectivity. Therefore, the administrator may want to set a higher
priority for using IPv4 than using IPv6 because the quality of the priority for using IPv4 than using IPv6 because the quality of the
tunnel network seems to be worse than that of the native transport. tunnel network seems to be worse than that of the native transport.
skipping to change at page 10, line 14 skipping to change at page 10, line 28
+--------+ +--------+
| Host-C | AAAA = 2001:db8::80 | Host-C | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1 +-----+--+ A = 192.0.2.1
| |
============ ============
| Internet | | Internet |
============ ============
| no IPv6 connectivity | no IPv6 connectivity
+----+----+ +----+----+
| Gateway | | Router |
+----+----+ +----+----+
| |
| fd01:2:3::/48 (ULA) | fd01:2:3::/48 (ULA)
| 192.0.2.128/25 | 192.0.2.128/25
++--------+ ++--------+
| Router | | Router |
+----+----+ +----+----+
| fd01:2:3:4::/64 (ULA) | fd01:2:3:4::/64 (ULA)
| 192.0.2.240/28 | 192.0.2.240/28
------+---+---------- ------+---+----------
skipping to change at page 11, line 21 skipping to change at page 11, line 27
===========|== ===========|==
| | | |
| | | |
+----+-+ +-->+------+ +----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80 | ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80 +----+-+ +-->+------+ fc12:3456:789a::80
| | | |
2001:db8:a::/48 | | 2001:db8:a::/48 | |
fc12:3456:789a::/48 | | fc12:3456:789a::/48 | |
+----+----|+ +----+----|+
| Gateway || | Router ||
+---+-----|+ +---+-----|+
| | 2001:db8:a:100::/64 | | 2001:db8:a:100::/64
| | fc12:3456:789a:100::/64 | | fc12:3456:789a:100::/64
--+-+---|----- --+-+---|-----
| | | |
+-+---|+ 2001:db8:a:100::EUI64 +-+---|+ 2001:db8:a:100::100
| Host | fc12:3456:789a:100::EUI64 | Host | fc12:3456:789a:100::100
+------+ +------+
[Fig. 7] [Fig. 7]
3. Conclusion 3. Conclusion
We have covered problems related to destination or source address We have covered problems related to destination or source address
selection. These problems have their roots in the situation where selection. These problems have their roots in the situation where
end-hosts have multiple IP addresses. In this situation, every end- end-hosts have multiple IP addresses. In this situation, every end-
host must choose an appropriate destination and source address, which host must choose an appropriate destination and source address, which
skipping to change at page 12, line 7 skipping to change at page 12, line 13
false-selection problem and take countermeasures beforehand. false-selection problem and take countermeasures beforehand.
4. Security Considerations 4. Security Considerations
When an intermediate router performs policy routing (e.g. source When an intermediate router performs policy routing (e.g. source
address based routing), inappropriate address selection causes address based routing), inappropriate address selection causes
unexpected routing. For example, in the network described in 2.1.3, unexpected routing. For example, in the network described in 2.1.3,
when Host-A uses a default address selection policy and chooses an when Host-A uses a default address selection policy and chooses an
inappropriate address, a packet sent to VPN can be delivered to a inappropriate address, a packet sent to VPN can be delivered to a
location via the Internet. This issue can lead to packet location via the Internet. This issue can lead to packet
eavesdropping or session hijack. eavesdropping or session hijack. However, sending the packet back to
the correct path from the attacker to the node is not easy, so these
two risk are not serious.
As documented in the security consideration section in RFC 3484, As documented in the security consideration section in RFC 3484,
address selection algorithms expose a potential privacy concern. address selection algorithms expose a potential privacy concern.
When a malicious host can make a target host perform address When a malicious host can make a target host perform address
selection, the malicious host can know multiple addresses attached to selection, for example by sending a anycast or a multicast packet,
the target host. In a case like 2.1.4, if an attacker can make Host the malicious host can know multiple addresses attached to the target
to send a multicast packet and the Host performs the default address host. In a case like 2.1.4, if an attacker can make Host to send a
selection algorithm, the attacker may be able to determine the ULAs multicast packet and Host performs the default address selection
attached to the Host. algorithm, the attacker may be able to determine the ULAs attached to
the Host.
These security risks have roots in inappropriate address selection. These security risks have roots in inappropriate address selection.
Therefore, if a countermeasure is taken, and hosts always select an Therefore, if a countermeasure is taken, and hosts always select an
appropriate address that is suitable to a site's network structure appropriate address that is suitable to a site's network structure
and routing, these risks can be avoided. and routing, these risks can be avoided.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
6.2. Informative References
[I-D.ietf-v6ops-nap] [I-D.ietf-v6ops-nap]
Velde, G., "Local Network Protection for IPv6", Velde, G., "Local Network Protection for IPv6",
draft-ietf-v6ops-nap-06 (work in progress), January 2007. draft-ietf-v6ops-nap-06 (work in progress), January 2007.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
6.2. Informative References
Appendix A. Appendix. Revision History Appendix A. Appendix. Revision History
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:
This version reflects comments from IESG members.
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. 49 change blocks. 
98 lines changed or deleted 123 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/