draft-ietf-v6ops-addr-select-req-03.txt   draft-ietf-v6ops-addr-select-req-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: April 14, 2008 R. Hiromi Expires: May 9, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
October 12, 2007 November 6, 2007
Requirements for address selection mechanisms Requirements for address selection mechanisms
draft-ietf-v6ops-addr-select-req-03.txt draft-ietf-v6ops-addr-select-req-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 37 skipping to change at page 1, line 37
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 April 14, 2008. This Internet-Draft will expire on May 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In a multi-prefix environment, nodes could have multiple addresses on In a multi-prefix environment, nodes could have multiple addresses on
one network interface. RFC 3484 defines a source and destination one network interface. RFC 3484 defines a source and destination
address-selection algorithm, which is commonly deployed in current address-selection algorithm, which is commonly deployed in current
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3
2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4
2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4
2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4
2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4
2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4
2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. List of threats introduced by new address-selection 3.1. List of threats introduced by new address-selection
mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. List of recommendations in which security mechanism 3.2. List of recommendations in which security mechanism
should be applied . . . . . . . . . . . . . . . . . . . . . 5 should be applied . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that One physical network can have multiple logical networks. In that
case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6 case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6
dual-stack environment, in a site that uses both ULA [RFC4193] and dual-stack environment, in a site that uses both ULA [RFC4193] and
global scope addresses or in a site connected to multiple upstream global scope addresses or in a site connected to multiple upstream
IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default
address-selection rules for the source and destination addresses. address-selection rules for the source and destination addresses.
skipping to change at page 4, line 48 skipping to change at page 4, line 48
have effect on address-selection behavior at their users' hosts. have effect on address-selection behavior at their users' hosts.
2.8. Next-hop Selection 2.8. Next-hop Selection
The mechanism can control next-hop-selection behavior at hosts or The mechanism can control next-hop-selection behavior at hosts or
cooperate with other routing mechanisms, such as routing protocols cooperate with other routing mechanisms, such as routing protocols
and RFC 4191 [RFC4191]. If the address-selection mechanism is used and RFC 4191 [RFC4191]. If the address-selection mechanism is used
with a routing mechanism, the two mechanisms have to be able to work with a routing mechanism, the two mechanisms have to be able to work
synchronously. synchronously.
2.9. Compatibility with RFC 3493
The mechanism can allow an application that uses the basic socket
interface defined in RFC 3493 [RFC3493] to work correctly. That is,
with the basic socket interface the application can select an
appropriate source and destination addresses and can communicate with
the destination host. This requirement does not necessarily mean
that OS protocol stack and socket libraries should not be changed.
3. Security Considerations 3. Security Considerations
3.1. List of threats introduced by new address-selection mechanism 3.1. List of threats introduced by new address-selection mechanism
There are some security incidents when combining these requirements There are some security incidents when combining these requirements
described in Section 2 into a protocol. In particular, here are six described in Section 2 into a protocol. In particular, here are six
possible threats. possible threats.
1. Hijacking or tapping from malicious nodes connecting from beyond 1. Hijacking or tapping from malicious nodes connecting from beyond
unapproved network boundaries. unapproved network boundaries.
skipping to change at page 6, line 20 skipping to change at page 6, line 28
This document has no actions for IANA. This document has no actions for IANA.
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-v6ops-addr-select-ps] [I-D.ietf-v6ops-addr-select-ps]
Matsumoto, A., "Problem Statement of Default Address Matsumoto, A., "Problem Statement of Default Address
Selection in Multi-prefix Environment: Operational Issues Selection in Multi-prefix Environment: Operational Issues
of RFC3484 Default Rules", of RFC3484 Default Rules",
draft-ietf-v6ops-addr-select-ps-01 (work in progress), draft-ietf-v6ops-addr-select-ps-02 (work in progress),
April 2007. October 2007.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
5.2. Informative References 5.2. Informative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
Appendix A. Appendix. Revision History
04:
A new requirement item "Compatibility with RFC 3493" was added,
which reflected a comment from Remi Denis-Courmont at the v6ops
mailing list.
03:
Security Consideration section was rewritten according to comments
from SECDIR.
02:
The description and evaluation of solution approaches were
separated into a new document called
draft-arifumi-v6ops-addr-select-sol-00.
01:
Other than policy table distribution approach, the solution
section included several solutions discussed at 67th IETF meeting.
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
Email: arifumi@nttv6.net Email: arifumi@nttv6.net
 End of changes. 10 change blocks. 
9 lines changed or deleted 42 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/