IPng Working Group Richard Draves Internet Draft Microsoft Research Document: draft-ietf-ipngwg-default-addr-select-02.txt November 24, 2000 Category: Standards Track Default Address Selection for IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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. Abstract This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. 1. Introduction The IPv6 addressing architecture [2] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [3]. Privacy considerations have introduced the concepts of "public addresses" Draves Standards Track - Expires June 2001 1 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 and "temporary addresses" [4]. The mobility architecture introduces "home addresses" and "care-of addresses" [5]. In addition, multi- homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems. Furthermore, dual or hybrid stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication. For example, when DNS name resolution yields both IPv6 and IPv4 addresses and the network protocol stack has available both IPv6 and IPv4 source addresses. In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior. As one example, suppose a DNS name resolves to a global IPv6 address and a global IPv4 address. If the node has assigned a global IPv6 address and a 169.254/16 auto- configured IPv4 address [6], then IPv6 is the best choice for communication. But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses. This document specifies source address selection and destination address selection separately, but using a common framework so that together the two algorithms yield useful results. The algorithms attempt to choose source and destination addresses of appropriate scope and configuration status (preferred or deprecated). Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information. The framework also has policy hooks to allow administrative override of the default behavior. For example, using these hooks an administrator can specify a preferred source prefix for use with a destination prefix, or prefer destination addresses with one prefix over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea. The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of destination or source address. Draves Standards Track - Expires June 2001 2 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. 2. Framework Our framework for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, the framework specifies two separate algorithms for these tasks. The algorithms are designed to work well together and they share a mechanism for administrative policy override. In this implementation architecture, applications use APIs [8] like getaddrinfo() and getipnodebyname() that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes represented as IPv4-mapped addresses). The application then passes a destination address to the network stack with connect() or sendto(). The application might use only the first address in the list, or it might loop over the list of addresses to find a working address. In any case, the network layer is never in a situation where it needs to choose a destination address from several alternatives. The application might also specify a source address with bind(), but often the source address is left unspecified. Therefore the network layer does often choose a source address from several alternatives. As a consequence, we intend that implementations of getaddrinfo() and getipnodebyname() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. Separately, the IPv6 network layer will use the source address selection algorithm when an application or upper- layer has not specified a source address. Application of this framework to source address selection in an IPv4 network layer may be possible but this is not explored further here. The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non- deprecated source addresses, avoid the use of transitional addresses when native addresses are available, and all else being equal prefer address pairs having the longest possible common prefix. For source address selection, temporary addresses [4] are preferred over public addresses. In mobile situations [5], home addresses are preferred over care-of addresses. The framework optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred Draves Standards Track - Expires June 2001 3 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used. 2.1. Scope Comparisons Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for node-local (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), and global (0xE) scopes [9]. Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope. We map unicast link- local to multicast link-local, unicast site-local to multicast site- local, and unicast global scope to multicast global scope. For example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global. We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B). This mapping implicitly conflates unicast site boundaries and multicast site boundaries [9]. 2.2. IPv4 Addresses and IPv4-Mapped Addresses The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [2]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address. IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [6], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [10], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site- local scope. IPv4 loopback addresses [11, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope. Other IPv4 addresses are assigned global scope. IPv4 addresses should be treated as having "preferred" configuration status. 2.3. IPv6 Addresses with Embedded IPv4 Addresses IPv4-compatible addresses [2] and 6to4 addresses [12] contain an embedded IPv4 address. For the purposes of this document, these addresses should be treated as having the scope of the embedded IPv4 Draves Standards Track - Expires June 2001 4 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 address. For example, the IPv6 address ::169.254.3.18 has link-local scope and the address 2002:0a01:0203::1 has site-local scope. IPv4-compatible addresses should be treated as having "preferred" configuration status. 2.4. Loopback Address and Other Format Prefixes The loopback address should be treated as having link-local scope and "preferred" configuration status. NSAP addresses, IPX addresses, and other addresses with as-yet- undefined format prefixes should be treated as having global scope and "preferred" configuration status. Later standards may supercede this treatment. 2.5. Policy Table The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces three values: a precedence value Precedence(A), a classification or label SrcLabel(A), and a second label DstLabel(A). The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A has higher precedence than address B, meaning that our algorithm will prefer to sort destination address A before destination address B. The labels SrcLabel(A) and DstLabel(A) allow for policies that prefer a particular source address prefix for use with a destination address prefix. The algorithms prefer to use a source address S with a destination address D if SrcLabel(S) = DstLabel(D). IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: Prefix Precedence SrcLabel DstLabel ::1/128 50 0 0 ::/0 40 1 1 2002::/16 30 2 2 ::/96 20 3 3 ::ffff:0:0/96 10 4 4 One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 [12] source addresses with 6to4 destination addresses, and v4-compatible [2] source addresses with v4-compatible destination addresses. Another Draves Standards Track - Expires June 2001 5 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. Policy table entries for scoped address prefixes MAY be qualified with an optional scope-id. If so, a prefix table entry only matches against an address during a lookup if the scope-id also matches the address's scope-id. 2.6. Common Prefix Length We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128. 3. Candidate Source Addresses The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address. We write CandidateSource(A) to denote the candidate set for the address A. It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that could forward the destination address to the outgoing interface. In some cases the destination address may be qualified with a scope- id or other information that will constrain the candidate set. For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface. In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this is an error. If the application or upper-layer specifies a source address that is in the candidate set for the destination, then the network layer MUST respect that choice. If the application or upper-layer does not specify a source address, then the network layer uses the source address selection algorithm specified in the next section. Draves Standards Track - Expires June 2001 6 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 4. Source Address Selection The source address selection algorithm chooses a source address for use with a destination address D. It is specified here in terms of the pair-wise comparison of addresses SA and SB. The pair-wise comparison can be used to select an address from the set CandidateSource(D). This source address selection algorithm only applies to IPv6 destination addresses, not IPv4 addresses. The pair-wise comparison consists of eight rules, which should be applied in order. If a rule chooses an address, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. If the eight rules fail to choose an address, some unspecified tie-breaker should be used. Rule 1: Prefer same address. If SA = D, then choose SA. Similarly, if SB = D, then choose SB. Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB and otherwise choose SA. Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then choose SA and otherwise choose SB. Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the source addresses is "preferred" and one of them is "deprecated", choose the one that is preferred. Rule 4: Prefer home addresses. If SA is a home address and SB is a care-of address, then prefer SA. Similarly, if SB is a home address and SA is a care-of address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. Rule 6: Prefer matching label. If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and Label(SA) <> MatchSrcLabel(D), then choose SB. Draves Standards Track - Expires June 2001 7 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Rule 7: Prefer temporary addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer public addresses over temporary addresses. Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then choose SB. Rule 8 may be superceded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. 5. Destination Address Selection The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list. The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document. We say that Source(D) is undefined if there is no source address available for destination D. For IPv6 addresses, this is only the case if CandidateSource(D) is the empty set. The pair-wise comparison of destination addresses consists of nine rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. Rule 1: Avoid unusable destinations. If there is no route to DB or if Source(DB) is undefined, then sort DA before DB. Similarly, if there is no route to DA or if Source(DA) is undefined, then sort DB before DA. Draves Standards Track - Expires June 2001 8 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then sort DB before DA. Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then sort DB before DA. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then sort DA before DB. Rule 4: Prefer home addresses. If Source(DA) is a home address and Source(DB) is a care-of address, then sort DA before DB. Similarly, if Source(DA) is a care-of address and Source(DB) is a home address, then sort DB before DA. Rule 5: Prefer matching label. If SrcLabel(Source(DA)) = DstLabel(DA) and SrcLabel(Source(DB)) <> DstLabel(DB), then sort DA before DB. Similarly, if SrcLabel(Source(DA)) <> DstLabel(DA) and SrcLabel(Source(DB)) = DstLabel(DB), then sort DB before DA. Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then sort DA before DB. Similarly, if Precedence(DA) < Precedence(DB), then sort DB before DA. Rule 7: Prefer smaller scope. If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if Scope(DA) > Scope(DB), then sort DB before DA. Rule 8: Use longest matching prefix. If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then sort DA before DB. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then sort DB before DA. Rule 9: Otherwise, leave the order unchanged. Sort DA before DB. Rules 8 and 9 may be superceded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance. 6. Interactions with Routing This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection. However, implementations may use source address considerations as a tiebreaker when choosing among otherwise equivalent routes. Draves Standards Track - Expires June 2001 9 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred global addresses. When sending to a global destination address, if there's no routing reason to prefer one interface over the other, then an implementation may preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination. Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other route is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. 7. Implementation Considerations The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is for getipnodebyname() and getaddrinfo() to call down to the IPv6 network layer with a list of destination addresses, sort the list in the network layer with full current knowledge of available source addresses, and return the sorted list to getipnodebyname() or getaddrinfo(). This is simple and gives the best results but it introduces the overhead of another system call. One way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to resort the list. Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getipnodebyname() or getaddrinfo(). To reduce overhead in this approach, the source address information can be cached, amortizing the overhead of retrieving it across multiple calls to getipnodebyname() and getaddrinfo(). In this approach, the implementation may not have knowledge of the outgoing interface for each destination, so it MAY use a looser definition of the candidate set during destination address ordering. In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries or source address assignments that might affect these algorithms have changed. Draves Standards Track - Expires June 2001 10 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 8. Security Considerations This document has no direct impact on Internet infrastructure security. 9. Examples This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. 9.1. Default Source Address Selection The source address selection rules, in conjunction with the default policy table, produce the following behavior: Destination: 2001::1 Sources: 3ffe::1 vs fe80::1 Result: 3ffe::1 (prefer appropriate scope) Destination: 2001::1 Sources: fe80::1 vs fec0::1 Result: fec0::1 (prefer appropriate scope) Destination: fec0::1 Sources: fe80::1 vs 2001::1 Result: 2001::1 (prefer appropriate scope) Destination: ff05::1 Sources: fe80::1 vs fec0::1 vs 2001::1 Result: fec0::1 (prefer appropriate scope) Destination: 2001::1 Sources: 2001::1 (deprecated) vs 2002::1 Result: 2001::1 (prefer same address) Destination: fec0::1 Sources: fec0::2 (deprecated) vs 2001::1 Result: fec0::2 (prefer appropriate scope) Destination: 2001::1 Sources: 2001::2 vs 3ffe::2 Result: 2001::2 (longest-matching-prefix) Destination: 2001::1 Sources: 2001::2 (care-of address) vs 3ffe::2 (home address) Result: 3ffe::2 (prefer home address) Destination: 2002:836b:2179::1 Sources: 2002:836b:2179::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2002:836b:2179::2 (prefer matching label) Draves Standards Track - Expires June 2001 11 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Destination: 2001::1 Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::d5e3:7953:13eb:22e8 (prefer temporary address) 9.2. Default Destination Address Selection The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior: Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer higher precedence) Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (prefer smaller scope) Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or fec0::2 (care-of address) or fe80::2 (care-of address) Destinations: 2001::1 vs fec0::1 Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home address) Sources: 2001::2 or fec0::2 (deprecated) or fe80::2 Destinations: 2001::1 vs fec0::1 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid deprecated addresses) Sources: 2001::2 or 3f44::2 or fe80::2 Destinations: 2001::1 vs 3ffe::1 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest matching prefix) Sources: 2002:836b:4179::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 2002:836b:4179::2) (prefer matching label) Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 Draves Standards Track - Expires June 2001 12 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence) 9.3. Configuring Preference for IPv6 vs IPv4 The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable. An administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: Prefix Precedence SrcLabel DstLabel ::1/128 50 0 0 ::/0 40 1 1 2002::/16 30 2 2 ::/96 20 3 3 ::ffff:0:0/96 100 4 4 This change to the default policy table produces the following behavior: Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) (prefer higher precedence) 9.4. Configuring Preference for Scoped Addresses The destination address selection rules give preference to destinations of smaller scope. For example, a site-local destination will be sorted before a global scope destination when the two are otherwise equally suitable. An administrator can change the policy table to reverse this preference and sort global destinations before site-local destinations, and site-local destinations before link- local destinations: Draves Standards Track - Expires June 2001 13 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Prefix Precedence SrcLabel DstLabel ::1/128 50 0 0 ::/0 40 1 1 fec0::/10 37 1 1 fe80::/10 33 1 1 2002::/16 30 2 2 ::/96 20 3 3 ::ffff:0:0/96 10 4 4 This change to the default policy table produces the following behavior: Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then fe80::1 (src fe80::2) (prefer higher precedence) Sources: 2001::2 (deprecated) or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (avoid deprecated addresses) 9.5. Configuring a Multi-Homed Site Consider a site A that has a business-critical relationship with another site B. To support their business needs, the two sites have contracted for service with a special high-performance ISP. This is in addition to the normal Internet connection that both sites have with different ISPs. The high-performance ISP is expensive and the two sites wish to use it only for their business-critical traffic with each other. Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS. The routing within both sites directs most traffic to the egress to the normal ISP, but the routing directs traffic sent to the other site's 2001 prefix to the egress to the high-performance ISP. To prevent unintended use of their high-performance ISP connection, the two sites implement ingress filtering to discard traffic entering from the high-performance ISP that is not from the other site. The default policy table and address selection rules produce the following behavior: Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b Draves Standards Track - Expires June 2001 14 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior. Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic may come back through the high-performance ISP. Again, this is not their desired behavior. This situation demonstrates the limitations of the longest-matching- prefix heuristic in multi-homed situations. However, the administrators of sites A and B can achieve their desired behavior via policy table configuration. For example, they can use the following policy table: Prefix Precedence SrcLabel DstLabel ::1 50 0 0 2001:aaaa:aaaa::/48 45 5 5 2001:bbbb:bbbb::/48 45 5 5 ::/0 40 1 1 2002::/16 30 2 2 ::/96 20 3 3 ::ffff:0:0/96 10 4 4 This policy table produces the following behavior: Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired. Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired. Draves Standards Track - Expires June 2001 15 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- uration", RFC 2462 , December 1998. 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy- 01.txt, July 2000. 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-12.txt, April 2000. 6 R. Troll. "Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network", draft-ietf-dhc-ipv4-autoconfig-05.txt, March 2000. 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. 9 S. Deering, B. Haberman, B. Zill. "IP Version 6 Scoped Address Architecture", draft-ietf-ipngwg-scoping-arch-01.txt, March 2000. 10 Y. Rekhter et. al, "Address Allocation for Private Internets", RFC 1918, February 1996. 11 F. Baker, Editor. "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 12 B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 Clouds", draft-ietf-ngtrans-6to4-07.txt, September 2000. Acknowledgments The author would like to acknowledge the contributions of the IPng Working Group, particularly Steve Deering and Ken Powell. Please let the author know if you contributed to the development of this draft and are not mentioned here. Author's Address Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 Draves Standards Track - Expires June 2001 16 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Phone: 1-425-936-2268 Email: richdr@microsoft.com Revision History Changes from draft-ietf-ipngwg-default-addr-select-01 Added Examples section, demonstrating default behavior and some policy table configuration scenarios. Removed many uses of MUST. Remaining uses concern the candidate set of source addresses and the source address selection rule that prefers source addresses of appropriate scope. Simplified the default policy table. Reordered the source address selection rules to reduce the influence of policy labels. Added more destination address selection rules. Added scoping of v4-compatible and 6to4 addresses based on the embedded IPv4 address. Changed references to anonymous addresses to use the new term, temporary addresses. Clarified that a user-level implementation of destination address ordering, which does not have knowledge of the outgoing interface for each destination, may use a looser definition of the candidate set. Clarified that an implementation should prevent an application or upper-layer from choosing a source address that is not in the candidate set and not prevent an application or upper-layer from choosing a source address that is in the candidate set. Miscellaneous editorial changes, including adding some missing references. Changes from draft-ietf-ipngwg-default-addr-select-00 Changed the candidate set definition so that the strong host model is recommended but not required. Added a rule to source address selection to prefer addresses assigned to the outgoing interface. Simplified the destination address selection algorithm, by having it use source address selection as a subroutine. Added a rule to source address selection to handle anonymous/public addresses. Added a rule to source address selection to handle home/care-of addresses. Draves Standards Track - Expires June 2001 17 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Changed to allow destination address selection to sort both IPv6 and IPv4 addresses. Added entries in the default policy table for IPv4- mapped addresses. Changed default precedences, so v4-compatible addresses have lower precedence than 6to4 addresses. Changes from draft-draves-ipngwg-simple-srcaddr-01 Added framework discussion. Added algorithm for destination address ordering. Added mechanism to allow the specification of administrative policy that can override the default behavior. Added section on routing interactions and TBD section on mobility interactions. Changed the candidate set definition for source address selection, so that only addresses assigned to the outgoing interface are allowed. Changed the loopback address treatment to link-local scope. Changes from draft-draves-ipngwg-simple-srcaddr-00 Minor wording changes because DHCPv6 also supports "preferred" and "deprecated" addresses. Specified treatment of other format prefixes; now they are considered global scope, "preferred" addresses. Reiterated that anycast and multicast addresses are not allowed as source addresses. Recommended that source addresses be taken from the outgoing interface. Required this for multicast destinations. Added analogous requirements for link-local and site-local destinations. Specified treatment of the loopback address. Changed the second selection rule so that if both candidate source addresses have scope greater or equal than the destination address and only of them is preferred, the preferred address is chosen. Draves Standards Track - Expires June 2001 18 draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Draves Standards Track - Expires June 2001 19