draft-ietf-v6ops-addr-select-req-05.txt   draft-ietf-v6ops-addr-select-req-06.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: September 7, 2008 R. Hiromi Expires: October 30, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
March 6, 2008 April 28, 2008
Requirements for address selection mechanisms Requirements for address selection mechanisms
draft-ietf-v6ops-addr-select-req-05.txt draft-ietf-v6ops-addr-select-req-06.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 September 7, 2008. This Internet-Draft will expire on October 30, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
There are some problematic cases when using default address selection There are some problematic cases when using default address selection
mechanism which RFC 3484 defines. This document describes additional mechanism which RFC 3484 defines. This document describes additional
requirements co-working with RFC3484 to solve the problems. requirements co-working with RFC3484 to solve the problems.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . 3 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 3
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
2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4
2.10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.10. Compatibility and Interoperability with RFC 3484 . . . . . 5
2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 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
Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
Today, the RFC 3484 [RFC3484] mechanism is widely implemented in Today, the RFC 3484 [RFC3484] mechanism is widely implemented in
major OSs. However, in many sites, the default address-selection major OSs. However, in many sites, the default address-selection
rules are not appropriate, and cause a communication failure. PS rules are not appropriate, and cause a communication failure. PS
[I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted [I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted
from incorrect address selection. from incorrect address selection.
Though RFC 3484 made the address-selection behavior of a host Though RFC 3484 made the address-selection behavior of a host
skipping to change at page 5, line 5 skipping to change at page 5, line 5
2.9. Compatibility with RFC 3493 2.9. Compatibility with RFC 3493
The mechanism can allow an application that uses the basic socket The mechanism can allow an application that uses the basic socket
interface defined in RFC 3493 [RFC3493] to work correctly. That is, interface defined in RFC 3493 [RFC3493] to work correctly. That is,
with the basic socket interface the application can select an with the basic socket interface the application can select an
appropriate source and destination addresses and can communicate with appropriate source and destination addresses and can communicate with
the destination host. This requirement does not necessarily mean the destination host. This requirement does not necessarily mean
that OS protocol stack and socket libraries should not be changed. that OS protocol stack and socket libraries should not be changed.
2.10. Security 2.10. Compatibility and Interoperability with RFC 3484
The mechanism has compatibility with RFC 3484. Now that RFC 3484 is
widely implemented, it may be most preferrable that a new address
selection mechanism does not conflict with the address selection
mechanisms defined in RFC 3484.
If the solution mechanism changes or replaces the address selection
mechanism defined in RFC 3484, interoperability has to be retained.
That is, a host with the new solution mechanism and a host with the
mechanism of RFC 3484 have to be interoperable.
2.11. Security
The mechanism works without any security problems. Possible security The mechanism works without any security problems. Possible security
threats are described in Security Considerations section. threats are described in Security Considerations section.
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 will be some security incidents when combining these There will be some security incidents when combining these
requirements described in Section 2 into a protocol. In particular, requirements described in Section 2 into a protocol. In particular,
skipping to change at page 6, line 17 skipping to change at page 6, line 25
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., Fujisaki, T., Hiromi, R., and K. Kanayama, Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement of Default Address Selection in Multi- "Problem Statement of Default Address Selection in Multi-
prefix Environment: Operational Issues of RFC3484 Default prefix Environment: Operational Issues of RFC3484 Default
Rules", draft-ietf-v6ops-addr-select-ps-04 (work in Rules", draft-ietf-v6ops-addr-select-ps-05 (work in
progress), February 2008. progress), April 2008.
[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. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[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.
5.2. Informative References 5.2. Informative References
Appendix A. Appendix. Revision History Appendix A. Appendix. Revision History
05: 01:
A new requirement item "Security" was added. Security Other than policy table distribution approach, the solution
Considerations section was rewritten according to comments from section included several solutions discussed at 67th IETF meeting.
SECDIR.
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 Considerations section was rewritten according to
comments from SECDIR.
02: 02:
The description and evaluation of solution approaches were The description and evaluation of solution approaches were
separated into a new document called separated into a new document called
draft-arifumi-v6ops-addr-select-sol-00. draft-arifumi-v6ops-addr-select-sol-00.
01: 03:
Security Considerations section was rewritten according to
Other than policy table distribution approach, the solution comments from SECDIR.
section included several solutions discussed at 67th IETF meeting. 04:
A new requirement item "Compatibility with RFC 3493" was added,
which reflected a comment from Remi Denis-Courmont at the v6ops
mailing list.
05:
A new requirement item "Security" was added. Security
Considerations section was rewritten according to comments from
SECDIR.
06:
A new requirement item "Compatibility and Interoperability with
RFC 3484" was added in response to comments from Tim Polk.
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. 11 change blocks. 
24 lines changed or deleted 40 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/