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

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