From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7078.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc7078.txt (limited to 'doc/rfc/rfc7078.txt') diff --git a/doc/rfc/rfc7078.txt b/doc/rfc/rfc7078.txt new file mode 100644 index 0000000..8395563 --- /dev/null +++ b/doc/rfc/rfc7078.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Matsumoto +Request for Comments: 7078 T. Fujisaki +Category: Standards Track NTT +ISSN: 2070-1721 T. Chown + University of Southampton + January 2014 + + + Distributing Address Selection Policy Using DHCPv6 + +Abstract + + RFC 6724 defines default address selection mechanisms for IPv6 that + allow nodes to select an appropriate address when faced with multiple + source and/or destination addresses to choose between. RFC 6724 + allows for the future definition of methods to administratively + configure the address selection policy information. This document + defines a new DHCPv6 option for such configuration, allowing a site + administrator to distribute address selection policy overriding the + default address selection parameters and policy table, and thus + allowing the administrator to control the address selection behavior + of nodes in their site. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7078. + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + +Matsumoto, et al. Standards Track [Page 1] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Introduction + + [RFC6724] describes default algorithms for selecting an address when + a node has multiple destination and/or source addresses to choose + from by using an address selection policy. This specification + defines a new DHCPv6 option for configuring the default policy table. + + Some problems were identified with the default address selection + policy as originally defined in [RFC3484]. As a result, RFC 3484 was + updated and obsoleted by [RFC6724]. While this update corrected a + number of issues identified from operational experience, it is + unlikely that any default policy will suit all scenarios, and thus + mechanisms to control the source address selection policy will be + necessary. Requirements for those mechanisms are described in + [RFC5221], while solutions are discussed in [ADDR-SEL]. Those + documents have helped shape the improvements in the default address + selection algorithm in [RFC6724] as well as the requirements for the + DHCPv6 option defined in this specification. + + This option's concept is to serve as a hint for a node about how to + behave in the network. Ultimately, while the node's administrator + can control how to deal with the received policy information, the + implementation SHOULD follow the method described below uniformly to + ease troubleshooting and to reduce operational costs. + +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 [RFC2119]. + + + + + +Matsumoto, et al. Standards Track [Page 2] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + +1.2. Terminology + + This document uses the terminology defined in [RFC2460] and the + DHCPv6 specification defined in [RFC3315] + +2. Address Selection Options + + The Address Selection option provides the address selection policy + table and some other configuration parameters. + + An Address Selection option contains zero or more policy table + options. Multiple policy table options in an Address Selection + option constitute a single policy table. When an Address Selection + option does not contain a policy table option, it may be used to just + convey the A and P flags for Automatic Row Additions and Privacy + Preference, respectively. + + The format of the Address Selection option is given below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_ADDRSEL | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |A|P| | + +-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS | + | (variable length) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Address Selection Option Format + + option-code: OPTION_ADDRSEL (84). + + option-len: The total length of the Reserved field, A and P flags, + and POLICY TABLE OPTIONS in octets. + + Reserved: Reserved field. The server MUST set this value to 0, and + the client MUST ignore its content. + + A: Automatic Row Addition flag. This flag toggles the Automatic + Row Addition flag at client hosts, which is described in + Section 2.1 of [RFC6724]. If this flag is set to 1, it does not + change client host behavior; that is, a client MAY automatically + add additional site-specific rows to the policy table. If set + to 0, the Automatic Row Addition flag is disabled, and a client + SHOULD NOT automatically add rows to the policy table. If the + option contains a POLICY TABLE option, this flag is meaningless, + + + +Matsumoto, et al. Standards Track [Page 3] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + and automatic row addition SHOULD NOT be performed against the + distributed policy table. This flag SHOULD be set to 0 only + when the Automatic Row Addition at client hosts is harmful for + site-specific reasons. + + P: Privacy Preference flag. This flag toggles the Privacy + Preference flag on client hosts, which is described in Section 5 + of [RFC6724]. If this flag is set to 1, it does not change + client host behavior; that is, a client will prefer temporary + addresses [RFC4941]. If set to 0, the Privacy Preference flag + is disabled, and a client will prefer public addresses. This + flag SHOULD be set to 0 only when the temporary addresses should + not be preferred for site-specific reasons. + + POLICY TABLE OPTIONS: Zero or more Address Selection Policy + Table options, as described below. This option corresponds to a + row in the policy table defined in Section 2.1 of [RFC6724]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_ADDRSEL_TABLE | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | label | precedence | prefix-len | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | prefix (variable length) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Address Selection Policy Table Option Format + + option-code: OPTION_ADDRSEL_TABLE (85). + + option-len: The total length of the label field, precedence field, + prefix-len field, and prefix field. + + label: An 8-bit unsigned integer; this value is for correlation of + source address prefixes and destination address prefixes. This + field is used to deliver a label value in the [RFC6724] policy + table. + + precedence: An 8-bit unsigned integer; this value is used for + sorting destination addresses. This field is used to deliver a + precedence value in the [RFC6724] policy table. + + + + + + +Matsumoto, et al. Standards Track [Page 4] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + prefix-len: An 8-bit unsigned integer; the number of leading bits in + the prefix that are valid. The value ranges from 0 to 128. If + an option with a prefix length greater than 128 is included, the + whole Address Selection option MUST be ignored. + + prefix: A variable-length field containing an IP address or the + prefix of an IP address. An IPv4-mapped address [RFC4291] must + be used to represent an IPv4 address as a prefix value. + + This field is padded with zeros up to the nearest octet boundary + when prefix-len is not divisible by 8. This can be expressed + using the following equation: (prefix-len + 7)/8 + + So, the length of this field should be between 0 and 16 bytes. + + For example, the prefix 2001:db8::/60 would be encoded with a + prefix-len of 60; the prefix would be 8 octets and would contain + octets 20 01 0d b8 00 00 00 00. + +3. Processing the Address Selection Option + + This section describes how to process a received Address Selection + option at the DHCPv6 client. + + This option's concept is to serve as a hint for a node about how to + behave in the network. Ultimately, while the node's administrator + can control how to deal with the received policy information, the + implementation SHOULD follow the method described below uniformly to + ease troubleshooting and to reduce operational costs. + +3.1. Handling Local Configurations + + [RFC6724] defines two flags (A and P) and the default policy table. + Also, users are usually able to configure the flags and the policy + table to satisfy their own requirements. + + The client implementation SHOULD provide the following choices to the + user. + + (a) replace the existing flags and active policy table with the + DHCPv6 distributed flags and policy table. + + (b) preserve the existing flags and active policy table, whether + this be the default policy table or the user configured policy. + + Choice (a) SHOULD be the default, i.e., that the policy table is not + explicitly configured by the user. + + + + +Matsumoto, et al. Standards Track [Page 5] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + +3.2. Handling Stale Distributed Flags and Policy Table + + When the information from the DHCP server goes stale, the flags and + the policy table received from the DHCP server SHOULD be deprecated. + The local configuration SHOULD be restored when the DHCP-supplied + configuration has been deprecated. In order to implement this, a + host can retain the local configuration even after the flags and the + policy table is updated by the distributed flags and policy table. + + The received information can be considered stale in several cases, + e.g., when the interface goes down, the DHCP server does not respond + for a certain amount of time, or the Information Refresh Time has + expired. + +3.3. Handling Multiple Interfaces + + The policy table, and other parameters specified in this document, + are node-global information by their nature. One reason being that + the outbound interface is usually chosen after destination address + selection. So a host cannot make use of multiple address selection + policies even if they are stored per interface. + + The policy table is defined as a whole, so the slightest addition/ + deletion from the policy table brings a change in the semantics of + the policy. + + It also should be noted that the absence of a DHCP-distributed policy + from a certain network interface should not infer that the network + administrator does not care about address selection policy at all, + because it may mean there is a preference to use the default address + selection policy. So, it should be safe to assume that the default + address selection policy should be used where no overriding policy is + provided. + + Under the above assumptions, we can specify how to handle received + policy as follows. + + In the absence of distributed policy for a certain network interface, + the default address selection policy SHOULD be used. A node should + use Address Selection options by default in any of the following two + cases: + + 1: A single-homed host SHOULD use default address selection options, + where the host belongs exclusively to one administrative network + domain, usually through one active network interface. + + + + + + +Matsumoto, et al. Standards Track [Page 6] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + 2: Hosts that use advanced heuristics to deal with multiple received + policies that are defined outside the scope of this document + SHOULD use Address Selection options. + + Implementations MAY provide configuration options to enable this + protocol on a per-interface basis. + + Implementations MAY store distributed address selection policies per + interface. They can be used effectively on implementations that + adopt per-application interface selection. + +4. Implementation Considerations + + o The value 'label' is passed as an unsigned integer, but there is + no special meaning for the value; that is, whether it is a large + or small number. It is used to select a preferred source address + prefix corresponding to a destination address prefix by matching + the same label value within the DHCP message. DHCPv6 clients + SHOULD convert this label to a representation appropriate for the + local implementation (e.g., string). + + o The maximum number of address selection rules that may be conveyed + in one DHCPv6 message depends on the prefix length of each rule + and the maximum DHCPv6 message size defined in [RFC3315]. It is + possible to carry over 3,000 rules in one DHCPv6 message (maximum + UDP message size). However, it should not be expected that DHCP + clients, servers, and relay agents can handle UDP fragmentation. + Network administrators SHOULD consider local limitations to the + maximum DHCPv6 message size that can be reliably transported via + their specific local infrastructure to end nodes; therefore, they + SHOULD consider the number of options, the total size of the + options, and the resulting DHCPv6 message size when defining their + policy table. + +5. Security Considerations + + A rogue DHCPv6 server could issue bogus address selection policies to + a client. This might lead to incorrect address selection by the + client, and the affected packets might be blocked at an outgoing ISP + because of ingress filtering, incur additional network charges, or be + misdirected to an attacker's machine. Alternatively, an IPv6 + transition mechanism might be preferred over native IPv6, even if it + is available. To guard against such attacks, a legitimate DHCPv6 + server should communicate through a secure, trusted channel, such as + a channel protected by IPsec, Secure Neighbor Discovery (SEND), and + DHCP authentication, as described in Section 21 of [RFC3315]. A + commonly used alternative mitigation is to employ DHCP snooping at + Layer 2. + + + +Matsumoto, et al. Standards Track [Page 7] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + Another threat surrounds the potential privacy concern as described + in the security considerations section of [RFC6724], whereby an + attacker can send packets with different source addresses to a + destination to solicit different source addresses in the responses + from that destination. This issue will not be modified by the + introduction of this option, regardless of whether or not the host is + multihomed. + +6. IANA Considerations + + IANA has assigned option codes to OPTION_ADDRSEL (84) and + OPTION_ADDRSEL_TABLE (85) from the "DHCP Option Codes" registry + (http://www.iana.org/assignments/dhcpv6-parameters/). + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, September 2012. + +7.2. Informative References + + [ADDR-SEL] Chown, T., Ed., and A. Matsumoto, Ed., "Considerations for + IPv6 Address Selection Policy Changes", Work in Progress, + April 2013. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + + + +Matsumoto, et al. Standards Track [Page 8] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Problem Statement for Default Address Selection in Multi- + Prefix Environments: Operational Issues of RFC 3484 + Default Rules", RFC 5220, July 2008. + + [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Requirements for Address Selection Mechanisms", RFC 5221, + July 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Matsumoto, et al. Standards Track [Page 9] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + +Appendix A. Acknowledgements + + The authors would like to thank to Dave Thaler, Pekka Savola, Remi + Denis-Courmont, Francois-Xavier Le Bail, Ole Troan, Bob Hinden, + Dmitry Anipko, Ray Hunter, Rui Paulo, Brian E. Carpenter, Tom Petch, + and the members of 6man's address selection design team for their + invaluable contributions to this document. + +Appendix B. Examples + + [RFC5220] gives several cases where address selection problems + happen. This section contains some examples for solving those cases + by using the DHCP option defined in this text to update the hosts' + policy table in a network, accordingly. There is also some + discussion of example policy tables in Sections 10.3 to 10.7 of RFC + 6724. + +B.1. Ingress Filtering Problem + + In the case described in Section 2.1.2 of [RFC5220], the following + policy table should be distributed when the Router performs static + routing and directs the default route to ISP1 as per Figure 2. By + putting the same label value to all IPv6 addresses (::/0) and the + local subnet (2001:db8:1000:1::/64), a host picks a source address in + this subnet to send a packet via the default route. + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + 2001:db8:1000:1::/64 45 1 + 2001:db8:8000:1::/64 45 14 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + +B.2. Half-Closed Network Problem + + In the case described in Section 2.1.3 of [RFC5220], the following + policy table should be distributed. By splitting the closed network + prefix (2001:db8:8000::/36) from all IPv6 addresses (::/0) and giving + different labels, the closed network prefix will only be used when + packets are destined for the closed network. + + + + + +Matsumoto, et al. Standards Track [Page 10] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + 2001:db8:8000::/36 45 14 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + +B.3. IPv4 or IPv6 Prioritization + + In the case described in Section 2.2.1 of [RFC5220], the following + policy table should be distributed to prioritize IPv6. This case is + also described in [RFC6724]. + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + ::ffff:0:0/96 100 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + +B.4. ULA or Global Prioritization + + In the case described in Section 2.2.3 of [RFC5220], the following + policy table should be distributed, or the Automatic Row Addition + flag should be set to 1. By splitting the Unique Local Address (ULA) + in this site (fc12:3456:789a::/48) from all IPv6 addresses (::/0) and + giving it higher precedence, the ULA will be used to connect to + servers in the same site. + + + + + + + + + + + + + + +Matsumoto, et al. Standards Track [Page 11] + +RFC 7078 DHCPv6 Address Selection Policy Opt January 2014 + + + Prefix Precedence Label + ::1/128 50 0 + fc12:3456:789a::/48 45 14 + ::/0 40 1 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + +Authors' Addresses + + Arifumi Matsumoto + NTT NT Lab + 3-9-11 Midori-Cho + Musashino-shi, Tokyo 180-8585 + Japan + + Phone: +81 422 59 3334 + EMail: arifumi@nttv6.net + + + Tomohiro Fujisaki + NTT NT Lab + 3-9-11 Midori-Cho + Musashino-shi, Tokyo 180-8585 + Japan + + Phone: +81 422 59 7351 + EMail: fujisaki@nttv6.net + + + Tim Chown + University of Southampton + Southampton, Hampshire SO17 1BJ + United Kingdom + + EMail: tjc@ecs.soton.ac.uk + + + + + + + + + + + +Matsumoto, et al. Standards Track [Page 12] + -- cgit v1.2.3