draft-ietf-v6ops-addr-select-ps-07.txt   draft-ietf-v6ops-addr-select-ps-08.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Informational NTT Intended status: Informational NTT
Expires: December 14, 2008 R. Hiromi Expires: December 14, 2008 R. Hiromi
Intec Netcore Intec Netcore
K. Kanayama K. Kanayama
INTEC Systems INTEC Systems
June 12, 2008 June 12, 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-07.txt draft-ietf-v6ops-addr-select-ps-08.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 2, line 30 skipping to change at page 2, line 30
2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6
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 . . . . . . . . . . 9 2.1.6. Multicast Source Address Selection . . . . . . . . . . 9
2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9
2.2. Destination Address Selection . . . . . . . . . . . . . . 10 2.2. Destination Address Selection . . . . . . . . . . . . . . 10
2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 10 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 10
2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 11 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 11
2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 12 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 12
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix. Revision History . . . . . . . . . . . . . 14 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
In IPv6, a single physical link can have multiple prefixes assigned In IPv6, a single physical link can have multiple prefixes assigned
to it. In such cases, an end-host may have multiple IP addresses to it. In such cases, an end-host may have multiple IP addresses
assigned to an interface on that link. In the IPv4-IPv6 dual stack assigned to an interface on that link. In the IPv4-IPv6 dual 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
Globally routable networks, an end-host typically has multiple IP Globally routable networks, an end-host typically has multiple IP
skipping to change at page 9, line 14 skipping to change at page 9, line 14
connection due to limitations relating to what applications are connection due to limitations relating to what applications are
capable of doing." 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 | 2001:db8:a::100 (old)
+--------+ +------+
[Fig. 5] [Fig. 5]
Solution analysis: Solution analysis:
This problem can be mitigated in the RFC 3484 framework. For This problem can be mitigated in the RFC 3484 framework. For
example, configuring some address selection policies into the example, configuring some address selection policies into Host's
Host-A's RFC 3484 policy table can solve this problem. RFC 3484 policy table can solve this problem.
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 Unicast Address. host has both a ULA and a Global Unicast Address.
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into the
sending host's RFC 3484 policy table can solve this problem.
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
skipping to change at page 11, line 19 skipping to change at page 11, line 24
RFC 3484 policy table can solve this problem. RFC 3484 policy table can solve this problem.
2.2.2. ULA and IPv4 dual-stack environment 2.2.2. ULA and IPv4 dual-stack environment
This is a special form of IPv4 and IPv6 prioritization. When an This is a special form of IPv4 and IPv6 prioritization. When an
enterprise has IPv4 Internet connectivity but does not yet have IPv6 enterprise has IPv4 Internet connectivity but does not yet have IPv6
Internet connectivity, and the enterprise wants to provide site-local Internet connectivity, and the enterprise wants to provide site-local
IPv6 connectivity, a ULA is the best choice for site-local IPv6 IPv6 connectivity, a ULA is the best choice for site-local IPv6
connectivity. Each employee host will have both an IPv4 global or connectivity. Each employee host will have both an IPv4 global or
private address and a ULA. Here, when this host tries to connect to private address and a ULA. Here, when this host tries to connect to
Host-C that has registered both A and AAAA records in the DNS, the Host-B that has registered both A and AAAA records in the DNS, the
host will choose AAAA as the destination address and the ULA for the host will choose AAAA as the destination address and the ULA for the
source address. This will clearly result in a connection failure. source address. This will clearly result in a connection failure.
+--------+ +--------+
| Host-C | AAAA = 2001:db8::80 | Host-B | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1 +-----+--+ A = 192.0.2.1
| |
============ ============
| Internet | | Internet |
============ ============
| no IPv6 connectivity | no IPv6 connectivity
+----+----+ +----+----+
| Router | | 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
------+---+---------- ------+---+----------
| |
+-+----+ fd01:2:3:4::100 (ULA) +-+------+ fd01:2:3:4::100 (ULA)
| Host | 192.0.2.245 | Host-A | 192.0.2.245
+------+ +--------+
[Fig. 7] [Fig. 7]
Solution analysis: Solution analysis:
This problem can be solved in the RFC 3484 framework. For This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into Host's example, configuring some address selection policies into Host-A's
RFC 3484 policy table can solve this problem. RFC 3484 policy table can solve this problem.
2.2.3. ULA or Global Prioritization 2.2.3. ULA or Global Prioritization
Differentiating services by the client's source address is very Differentiating services by the client's source address is very
common. IP-address-based authentication is an typical example of common. IP-address-based authentication is an typical example of
this. Another typical example is a web service that has pages for this. Another typical example is a web service that has pages for
the public and internal pages for employees or involved parties. Yet the public and internal pages for employees or involved parties. Yet
another example is DNS zone splitting. another example is DNS zone splitting.
However, a ULA and IPv6 global address both have global scope, and However, a ULA and IPv6 global address both have global scope, and
RFC3484 default rules do not specify which address should be given RFC3484 default rules do not specify which address should be given
priority. This point makes IPv6 implementation of address-based priority. This point makes IPv6 implementation of address-based
service differentiation a bit harder. service differentiation a bit harder.
+------+ +--------+
| Host | | Host-B |
+-+--|-+ +-+--|---+
| | | |
===========|== ===========|==
| Internet | | | Internet | |
===========|== ===========|==
| | | |
| | | |
+----+-+ +-->+------+ +----+-+ +-->+------+
| 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 | |
+----+----|+ +----+----|+
| Router || | 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::100 +-+---|--+ 2001:db8:a:100::100
| Host | fc12:3456:789a:100::100 | Host-A | fc12:3456:789a:100::100
+------+ +--------+
[Fig. 7] [Fig. 7]
Solution analysis: Solution analysis:
This problem can be solved in the RFC 3484 framework. For This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into Host's example, configuring some address selection policies into Host-A's
RFC 3484 policy table can solve this problem. RFC 3484 policy table can solve this problem.
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
cannot be achieved only by routers. cannot be achieved only by routers.
skipping to change at page 15, line 20 skipping to change at page 15, line 44
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: 05:
This version reflects comments from IESG members and Bob Hinden. This version reflects comments from IESG members and Bob Hinden.
06: 06:
This version reflects comments from Thomas Narten. This version reflects comments from Thomas Narten.
07: 07:
This version reflects comments from Alfred Hoenes. This version reflects comments from Alfred Hoenes.
08:
Solution analysis for the section 2.1.6 was added.
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. 16 change blocks. 
24 lines changed or deleted 29 lines changed or added

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