--- 1/draft-ietf-v6ops-addr-select-req-03.txt 2007-11-09 01:12:07.000000000 +0100 +++ 2/draft-ietf-v6ops-addr-select-req-04.txt 2007-11-09 01:12:07.000000000 +0100 @@ -1,21 +1,21 @@ IPv6 Operations Working Group A. Matsumoto Internet-Draft T. Fujisaki Intended status: Informational NTT -Expires: April 14, 2008 R. Hiromi +Expires: May 9, 2008 R. Hiromi K. Kanayama Intec Netcore - October 12, 2007 + November 6, 2007 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 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 @@ -26,21 +26,21 @@ 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 April 14, 2008. + This Internet-Draft will expire on May 9, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In a multi-prefix environment, nodes could have multiple addresses on one network interface. RFC 3484 defines a source and destination address-selection algorithm, which is commonly deployed in current @@ -56,31 +56,33 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 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 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. List of recommendations in which security mechanism should be applied . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . . . 8 + Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . . . 9 1. Introduction One physical network can have multiple logical networks. In that 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 global scope addresses or in a site connected to multiple upstream IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default address-selection rules for the source and destination addresses. @@ -159,20 +161,29 @@ have effect on address-selection behavior at their users' hosts. 2.8. Next-hop Selection The mechanism can control next-hop-selection behavior at hosts or cooperate with other routing mechanisms, such as routing protocols and RFC 4191 [RFC4191]. If the address-selection mechanism is used with a routing mechanism, the two mechanisms have to be able to work 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.1. List of threats introduced by new address-selection mechanism There are some security incidents when combining these requirements described in Section 2 into a protocol. In particular, here are six possible threats. 1. Hijacking or tapping from malicious nodes connecting from beyond unapproved network boundaries. @@ -224,34 +235,56 @@ This document has no actions for IANA. 5. References 5.1. Normative References [I-D.ietf-v6ops-addr-select-ps] Matsumoto, A., "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", - draft-ietf-v6ops-addr-select-ps-01 (work in progress), - April 2007. + draft-ietf-v6ops-addr-select-ps-02 (work in progress), + October 2007. [RFC3484] Draves, R., "Default Address Selection for Internet 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 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 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 Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net