--- 1/draft-ietf-shim6-locator-pair-selection-01.txt 2007-07-09 22:12:16.000000000 +0200 +++ 2/draft-ietf-shim6-locator-pair-selection-02.txt 2007-07-09 22:12:16.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group M. Bagnulo Internet-Draft UC3M -Intended status: Informational October 22, 2006 -Expires: April 25, 2007 +Intended status: Informational July 8, 2007 +Expires: January 9, 2008 Default Locator-pair selection algorithm for the SHIM6 protocol - draft-ietf-shim6-locator-pair-selection-01 + draft-ietf-shim6-locator-pair-selection-02 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 @@ -23,49 +23,47 @@ 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 25, 2007. + This Internet-Draft will expire on January 9, 2008. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract In this note, we present a locator-pair selection mechanism for the shim6 protocol. The presented mechanism provides an ordered list of available locator-pairs that can be used for outgoing traffic. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4 2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4 2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 5 2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5 2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5 2.3.2. Source locator preferences . . . . . . . . . . . . . . 6 2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6 3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6 - 4. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 - 5.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8 - 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 + 4.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 1. Introduction Once that a shim6 context is established between two peers, they are free to select the best locator pair to continue the communication. In particular, when an outage is detected, they will need to select a new locator pair to rehome the communication. Besides, policy or other considerations may lead to change the locator pair used in the @@ -316,75 +314,57 @@ Other rules that may be worth taking into account are: o Prefer native transport o Prefer smaller scope o Prefer most dissimilar locator pair to the currently used o Prefer locator pair contained in incoming packet o Longest prefix match o Should we eliminate the site and link local addresses from the accpetable locator set? -4. TO DO - - Include an implementation section descring a formula that can express - several rules with a single calculation. - -5. Security considerations +4. Security considerations Note that according to the shim6 protocol specification, locators are included in the Ls(peer) only after HBA/CGA verification has been successful. This eliminates the possibility of using locators that do not belong to the peer. Besides, it should be noted that before using a given locator pair to actually send data packets, a reachability test is performed in order to prevent flooding attacks. -5.1. Privacy considerations +4.1. Privacy considerations Including or not RFC3041 [6] addresses in the Locator set available for a shim6 context may have privacy implications. This is so because of two reaosns: First, the inclusion of RFC 3041 addresses in the locator set discloses the RFC3041 addresses of the host to the peer. Second, the locator sets of both peers are exchanged in clear text during the shim6 context establishment and/or in the subsequent UPDATE messages. This means that an attacker located along the path that can observe such packets can discover that all the addresses included in the locator set belong to the same host, beating the purpose of RFC3041 private addresses. So, when forming the locator set of a shim6 context the host must take into account these privacy considerations in order to decide whether to include RFC3041 addresses in the locator set of a shim6 context. -6. Change History - - From draft-ietf-shim6-locator-pair-selection-00 to - draft-ietf-shim6-locator-pair-selection-01 - - Removed rule 1 (preffer src=dst). Removed rule 12 (about preffering - temporary RFC3041 addresses) and added Privacy considerations section - about including or not RFC3041 temporary addresses in the locator set - for a shim6 context. Removed section about IPv4 considerations. - Removed rule 6 about same address family and added consideration only - including locator pairs with addresses of the same family in the - candidate locator pair set creation. Editorial changes - -7. Acknowledgements +5. Acknowledgements The idea of pre-assigning Weight* values for introducing the Weight probability in the locator-pair selection process was suggested by Albert Banchs. Marcelo Bagnulo worked on this document while visiting Ericsson Research laboratory Nomadiclab. Iljitsch van Beijnum provided a detailed review of this document. -8. References +6. References [1] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-04 (work in progress), March 2006. [2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-03 (work in progress), December 2005. @@ -414,32 +394,32 @@ Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information