draft-ietf-shim6-locator-pair-selection-00.txt   draft-ietf-shim6-locator-pair-selection-01.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Expires: November 26, 2006 May 25, 2006 Intended status: Informational October 22, 2006
Expires: April 25, 2007
Default Locator-pair selection algorithm for the SHIM6 protocol Default Locator-pair selection algorithm for the SHIM6 protocol
draft-ietf-shim6-locator-pair-selection-00 draft-ietf-shim6-locator-pair-selection-01
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 33 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 November 26, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 . . . . . . . . . . . . . . . . . . . 4 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
2.5. About IPv4 addresses . . . . . . . . . . . . . . . . . . . 6
3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6 3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 8 4. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8
6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 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 3, line 47 skipping to change at page 3, line 47
presented in this note is a locator pair selection mechanism as presented in this note is a locator pair selection mechanism as
opposed to separate source address and destination address selection opposed to separate source address and destination address selection
mechanisms as described in RFC 3484. We think that such approach is mechanisms as described in RFC 3484. We think that such approach is
more appropriate for the shim6 protocol, since reachability seems to more appropriate for the shim6 protocol, since reachability seems to
be a property of an address pair rather than a property of a single be a property of an address pair rather than a property of a single
address. address.
The presented mechanism takes into account general properties of the The presented mechanism takes into account general properties of the
available addresses, in particular the address family (v4 or v6), available addresses, in particular the address family (v4 or v6),
address scope [3], mobility consideration (Home-Addresses and Care- address scope [3], mobility consideration (Home-Addresses and Care-
off Addresses) [5], [4], status of the addresses (Preferred and off Addresses) [4], status of the addresses (Preferred and Deprecated
Deprecated addresses) [6], privacy considerations (Public and addresses) [5], privacy considerations (Public and Temporary
Temporary addresses) [7]. In addition it also takes into account addresses) [6]. In addition it also takes into account shim6
shim6 specific information such as whether the addresses are known to specific information such as whether the addresses are known to be
be locally operational (as defined in [2]), if locator pairs are know locally operational (as defined in [2]), if locator pairs are know to
to be unidirectionally operational [2], the local and remote be unidirectionally operational [2], the local and remote preferences
preferences for the different locators available in the shim6 for the different locators available in the shim6 context.
context.
Multicast addresses are out of the scope of the document. Multicast addresses are out of the scope of the document.
2. Preliminary considerations 2. Preliminary considerations
2.1. Candidate Locator-pair set 2.1. Candidate Locator-pair set
We define the local set of locally-operational locators (LOLs(local)) We define the local set of locally-operational locators (LOLs(local))
as the local locators that are included in the local locator set as the local locators that are included in the local locator set
(Ls(local) as defined in [1]) and that are locally operational as (Ls(local) as defined in [1]) and that are locally operational as
skipping to change at page 4, line 36 skipping to change at page 4, line 35
The candidate locator-pair set is the set of locator pairs that can The candidate locator-pair set is the set of locator pairs that can
be used to send packets in a shim context. be used to send packets in a shim context.
The candidate locator-pair set contains in all the possible locator The candidate locator-pair set contains in all the possible locator
pairs formed with the first of them belonging to the local set of pairs formed with the first of them belonging to the local set of
locally-operational locators (LOLs(local)) and the second locator locally-operational locators (LOLs(local)) and the second locator
belonging to the locally-operational locators of the peer belonging to the locally-operational locators of the peer
(LOLs(peer)). (LOLs(peer)).
This can be expressed as:
Cand_Loc_Pair_Set ={(x,y)/[x in LOLs(local) and y in LOLs(peer)} Cand_Loc_Pair_Set ={(x,y)/[x in LOLs(local) and y in LOLs(peer)}
Current shim6 protocol specification only supports IPv6 addresses as
locators. In case the shim6 protocol specification is updated and
IPv4 addresses are accepted as locators, the creation of the
Candidate Locator Pair Set must only accept locator pairs where both
source and destiantion address are of the same family. The result
would be the following formula:.
Cand_Loc_Pair_Set ={(x,y)/[family(x) = family(y)] AND [x in
LOLs(local) and y in LOLs(peer)]}
Question: should we allow locator pairs with all types of scope
combinations or should we restrict the type of scope combinations for
the inclusion in the cadidate set? If we don't allow all the
combinations, we can remove rule 1 aboput scopes
2.2. Locator-pair States 2.2. Locator-pair States
Locator pairs can be in the following state: Locator pairs can be in the following state:
o Unidirectionally Operational state: As defined in [2], is when o Unidirectionally Operational state: As defined in [2], is when
packets send with the first locator as the source address and the packets send with the first locator as the source address and the
second locator as a destination address are known to reach the second locator as a destination address are known to reach the
destination. In the shim6 case, a locator pair is know to be destination. In the shim6 case, a locator pair is know to be
unidirectionally operational when there is fresh information about unidirectionally operational when there is fresh information about
packets reaching the peer, using the mechanisms defined in [2] or packets reaching the peer, using the mechanisms defined in [2] or
skipping to change at page 5, line 24 skipping to change at page 5, line 38
2.3. Locator preferences 2.3. Locator preferences
2.3.1. Remote locator preferences 2.3.1. Remote locator preferences
Remote locator preferences can be obtained through the shim6 protocol Remote locator preferences can be obtained through the shim6 protocol
using the Locator Preference option. The preferences consist in a using the Locator Preference option. The preferences consist in a
Flag octet, a Priority octet and an optional Weight octet. Flag octet, a Priority octet and an optional Weight octet.
The weight field express the relative weight for locators with the The weight field express the relative weight for locators with the
same priority, and as defined in [8] larger weights should be given a same priority, and as defined in [7] larger weights should be given a
proportionally higher probability of being selected. In order to proportionally higher probability of being selected. In order to
include this probability information in the locator-pair selection include this probability information in the locator-pair selection
algorithm, a new weight* information is generated from the weight algorithm, a new weight* information is generated from the weight
values as following: values as following:
We order each set of destination addresses with the same priority and We order each set of destination addresses with the same priority and
defined weight values using the following algorithm defined in [8]: defined weight values using the following algorithm defined in [7]:
Arrange all addresses (that have not been ordered yet) in any order, Arrange all addresses (that have not been ordered yet) in any order,
except that all those with weight 0 are placed at the beginning of except that all those with weight 0 are placed at the beginning of
the list. the list.
Compute the sum of the weights of those addresses, and with each Compute the sum of the weights of those addresses, and with each
address associate the running sum in the selected order. Then choose address associate the running sum in the selected order. Then choose
a uniform random number between 0 and the sum computed (inclusive), a uniform (pseudo)random number between 0 and the sum computed
and select the address whose running sum value is the first in the (inclusive), and select the address whose running sum value is the
selected order which is greater than or equal to the random number first in the selected order which is greater than or equal to the
selected. This address is the next one to be included in the ordered (pseudo)random number selected. This address is the next one to be
list. Remove this address from the set of the unordered addresses included in the ordered list. Remove this address from the set of
and apply the described algorithm to the unordered address set to the unordered addresses and apply the described algorithm to the
select the next target address. Continue the ordering process until unordered address set to select the next target address. Continue
there are no unordered addresses. the ordering process until there are no unordered addresses.
The weight* (W*1, W*2,...,W*N) values for each of the addresses is The weight* (W*1, W*2,...,W*N) values for each of the addresses is
their final position in the resulting ordered list. their final position in the resulting ordered list.
The procedure is repeated for each one of the sets containing The procedure is repeated for each one of the sets containing
destination addresses with equal priority. destination addresses with equal priority.
The Weight information is not used in the locator-pair selection The Weight information is not used in the locator-pair selection
mechanism, but the Weight* information is. mechanism, but the Weight* information is.
2.3.2. Source locator preferences 2.3.2. Source locator preferences
With respect to the local locator preferences, this document assumes With respect to the local locator preferences, this document assumes
that the host will have a mechanism to express Priority and Weight that the host will have a mechanism to express Priority and Weight
information for local locators similar to the one defined in [8]. information for local locators similar to the one defined in [7].
The same procedure is used to assign Weight* values to the source The same procedure is used to assign Weight* values to the source
locators that have the same priority value. locators that have the same priority value.
Note that destination and source addresses are never included in the Note that destination and source addresses are never included in the
same set, even if they have the same priority value. same set, even if they have the same priority value.
The Weight information is not used in the locator-pair s election The Weight information is not used in the locator-pair s election
mechanism, but the Weight* information is. mechanism, but the Weight* information is.
2.4. Locator-pair selection table 2.4. Locator-pair selection table
We define the Locator-pair selection table to express preferences We define the Locator-pair selection table to express preferences
about which source address prefix to use when communicating with a about which source address prefix to use when communicating with a
given destination address prefix. The table contains entries having given destination address prefix. The table contains entries having
a source prefix and a destination prefix each. Given a locator pair, a source prefix and a destination prefix each. Given a locator pair,
it is then possible to find a match when both the source prefix is it is then possible to find a match when both the source prefix is
contained in the source address and the destination prefix is contained in the source address and the destination prefix is
contained in the destination address. contained in the destination address.
2.5. About IPv4 addresses
IPv4 addresses are considered to be Public in the RFC3041 sense,
Preferred in the RFC2462 sense.
3. Default Locator-Pair Selection Algorithm 3. Default Locator-Pair Selection Algorithm
The goal of the defualt locator-pair selection algorithm is to The goal of the defualt locator-pair selection algorithm is to
produce an ordered list of locator pairs to be tried for rehoming an produce an ordered list of locator pairs to be tried for rehoming an
ongoing communication. The ordered list can be produced with any ongoing communication. The ordered list can be produced with any
sorting algorithm. The set of rules described next are the sorting algorithm. The set of rules described next are the
comparison criteria to be used in the locator-pair sorting algorithm. comparison criteria to be used in the locator-pair sorting algorithm.
This rules act must be processed in order and if a given rule selects This rules act must be processed in order and if a given rule selects
a locator pair over the other one, then the following rules don't a locator pair over the other one, then the following rules don't
need to be processed and the selected locator pair is prefered. need to be processed and the selected locator pair is prefered.
We are comparing two locator pairs (src1,dst1) and (src2,dst2). Note We are comparing two locator pairs (src1,dst1) and (src2,dst2). Note
that in some cases the source or the destination addresses of the two that in some cases the source or the destination addresses of the two
pairs may be equal. pairs may be equal.
Rule 1: Prefer appropriate scope: If scope(src1) >= scope(dst1) and
Rule 1: Prefer the same address: If src1 = dst1 and src2 <> dst2,
then prefer (src1,dst1).
Rule 2: Prefer appropriate scope: If scope(src1) >= scope(dst1) and
scope(src2) < scope(dst2), then prefer (src1,dst1). scope(src2) < scope(dst2), then prefer (src1,dst1).
Rule 3: Avoid Non-Operational pairs: If (src1,dst1) is in Non- Rule 2: Avoid Non-Operational pairs: If (src1,dst1) is in Non-
Operational state and (src2,dst2) is in Unidirectionally Operational state and (src2,dst2) is in Unidirectionally
Operational or in Unknown state, then prefer (src2,dst2). Operational or in Unknown state, then prefer (src2,dst2).
Rule 4: Prefer Unidirectionally Operational state: If (src1,dst1) is Rule 3: Prefer Unidirectionally Operational state: If (src1,dst1) is
in Unknown state and (src2,dst2) is in Unidirectionally in Unknown state and (src2,dst2) is in Unidirectionally
Operational, then prefer (src2,dst2). Operational, then prefer (src2,dst2).
Rule 5: Prefer fresher reachability information: If (src1,dst1) and Rule 4: Prefer fresher reachability information: If (src1,dst1) and
(src2,dst2) are both in Unidirectionally Operational state, (src2,dst2) are both in Unidirectionally Operational state,
then prefer the one with smallest age information i.e. the then prefer the one with smallest age information i.e. the
one for which newer reachability information is available. one for which newer reachability information is available.
Rule 6: Prefer same address family: If (src1,dst1) are both of the Rule 5: Prefer ULID-Pair: If (src1,dst1) is the ULID-pair of the
same address family (v4/v6) and (src2,dst2) are of different context, the prefer (src1,dst1)
address family, then prefer (src1,dst1) (This could also be
done with the Locator-pair selection table)
Rule 7: Prefer matching scope: If scope(src1) = scope(dst1) and Rule 6: Prefer matching scope: If scope(src1) = scope(dst1) and
scope(src2) < scope(dst2), then prefer (src1,dst1) scope(src2) < scope(dst2), then prefer (src1,dst1)
Rule 8: Prefer Locator-pair table match: If (dst1,src1) has a match Rule 7: Prefer Locator-pair table match: If (dst1,src1) has a match
in the Locator-pair selection table and (src2,dst2) does not in the Locator-pair selection table and (src2,dst2) does not
have a match in the locator-pair selection table, then have a match in the locator-pair selection table, then
prefer (dst1,src1). prefer (dst1,src1).
Rule 9: Prefer Preferred addresses: If src1 address is a Preferred Rule 8: Prefer Preferred addresses: If src1 address is a Preferred
address in the RFC2462 sense and src2 is a deprecated address in the RFC2462 sense and src2 is a deprecated
address in the RFC2462 sense, then prefer (src1,dst1) address in the RFC2462 sense, then prefer (src1,dst1)
Rule 10: Prefer Local Priority: If src1 of (src1,dst1) has a lowest Rule 9: Prefer Local Priority: If src1 of (src1,dst1) has a lowest
Priority than src2 of (src2,dst2) then prefer (src1,dst1) Priority than src2 of (src2,dst2) then prefer (src1,dst1)
Rule 10: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest
Rule 11: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest
Weight* than src2 of (src2,dst2) then prefer (src1,dst1) Weight* than src2 of (src2,dst2) then prefer (src1,dst1)
Rule 12: Prefer Temporary addresses: If src1 is a temporary address Rule 11: Prefer Local Care-off Addresses: If src1 is a Care-off
[7] and src2 is a public address, the prefer (src1,dst1) address [4] and src2 is a Home Address, the prefer
over (src2,dst2) (src1,dst1). This only applies to Mobile IP [4].
Rule 13: Prefer Local Care-off Addresses: If src1 is a Care-off
address [4] [5] and src2 is a Home Address, the prefer
(src1,dst1)
Rule 14: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest Rule 12: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest
Priority than dst2 of (src2,dst2) then prefer (src1,dst1) Priority than dst2 of (src2,dst2) then prefer (src1,dst1)
Rule 15: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest Rule 13: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest
Weight* than dst2 of (src2,dst2) then prefer (src1,dst1) Weight* than dst2 of (src2,dst2) then prefer (src1,dst1)
Rule 16: Prefer Remote Care-off Addresses: If dst1 is a Care-off Rule 14: Prefer Remote Care-off Addresses: If dst1 is a Care-off
address (Temporary flag set in the Locator preferences address (Temporary flag set in the Locator preferences
options defined in [1]) and dst2 is not a Care-off address, options defined in [1]) and dst2 is not a Care-off address,
the prefer (src1,dst1) the prefer (src1,dst1). This only applies to Mobile IP [4].
Rule 17: Prefer ULID-Pair: If (src1,dst1) is the ULID-pair of the
context, the prefer (src1,dst1)
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
accpetable locator set?
4. Security considerations 4. TO DO
TBD Include an implementation section descring a formula that can express
several rules with a single calculation.
5. Acknowledgements 5. 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
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
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.
6. References Iljitsch van Beijnum provided a detailed review of this document.
8. 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.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [5] Thomson, S. and T. Narten, "IPv6 Stateless Address
August 2002.
[6] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [7] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[9] Draves, R., "Default Address Selection for Internet Protocol [8] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
Author's Address Author's Address
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 11, line 29 skipping to change at page 11, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 41 change blocks. 
91 lines changed or deleted 132 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/