RFC 7078
Distributing Address Selection Policy Using DHCPv6
RFC 7078: Distributing Address Selection Policy Using DHCPv6 🎀
okay bestie, let's get into it 💅 This one is from the IETF (Internet Engineering Task Force), and it's by A. Matsumoto and T. Fujisaki from NTT, with T. Chown from the University of Southampton. It's dated January 2014 and sits in the Standards Track category, with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a fresh standalone spec 🦋
Abstract ✨
okay so [RFC6724] is the thing that decides which address a computer picks when it has a bunch of IPv6 source or destination addresses to choose from. It gives nodes default rules for that, but it also says there should be a way for admins to configure the address selection policy on purpose. This doc is that way 🧚 It defines a brand new DHCPv6 option so a site admin can push out their own address selection policy. That policy overrides the default parameters and the default policy table, which means the admin gets to control how every node in their site picks addresses. main character energy for network admins fr 👑
Status of This Memo
this is an Internet Standards Track document 🌈
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. please read those carefully, because they spell out your rights and restrictions for this doc 🧾 any Code Components pulled out of this doc have to include Simplified BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty, per that same license.
this doc might include material from IETF Documents or IETF Contributions published or made public before November 10, 2008. the people who control the copyright on some of that stuff might not have let the IETF Trust allow modifications outside the IETF Standards Process. so unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
1. Introduction 🦋
[RFC6724] describes the default algorithms a node uses to pick an address when it has multiple destination and/or source addresses, using an address selection policy. this spec defines a new DHCPv6 option for configuring that default policy table 💖
some problems came up with the default address selection policy as first defined in [RFC3484]. so RFC 3484 got updated and obsoleted by [RFC6724] 🙈 that update fixed a bunch of issues people found from running it in the real world. but honestly, no single default policy is going to suit every scenario, so mechanisms to control the source address selection policy are going to be needed. the requirements for those mechanisms are in [RFC5221], and the solutions are discussed in [ADDR-SEL]. both of those docs helped shape the improvements to the default algorithm in [RFC6724] and also the requirements for the DHCPv6 option defined here ✨
this option is basically a hint for a node about how to act on the network. the node's admin can decide how to handle the policy info they get, but the implementation SHOULD follow the method below uniformly, so troubleshooting is easier and operating costs go down 💅
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]. 🎀
1.2. Terminology 🧚
this doc uses the terminology defined in [RFC2460] and the DHCPv6 specification defined in [RFC3315].
2. Address Selection Options 💜
the Address Selection option holds the address selection policy table plus some other config parameters 🍓
an Address Selection option can contain zero or more policy table options. multiple policy table options inside one Address Selection option make up a single policy table. if an Address Selection option has no policy table option, it can just be used to send the A and P flags for Automatic Row Additions and Privacy Preference 🌈
here's the format of the Address Selection option:
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 Formatthe fields, in order:
option-code:OPTION_ADDRSEL(84) 🔥option-len: the total length of the Reserved field, the A and P flags, and the POLICY TABLE OPTIONS, in octets 📏Reserved: a reserved field. the server MUST set this value to 0, and the client MUST ignore its content 🙈A: the 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 doesn't change client host behavior. so a client MAY automatically add additional site-specific rows to the policy table. if it's 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 has a POLICY TABLE option, this flag is meaningless, and automatic row addition SHOULD NOT be performed against the distributed policy table. this flag SHOULD be set to 0 only when Automatic Row Addition at client hosts is harmful for site-specific reasons 😭P: the 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 doesn't change client host behavior, so a client will prefer temporary addresses [RFC4941]. if it's 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 temporary addresses shouldn't be preferred for site-specific reasons 🌸POLICY TABLE OPTIONS: zero or more Address Selection Policy Table options, as described below. each one corresponds to a row in the policy table defined in Section 2.1 of [RFC6724] 🧚
here's the format of the Address Selection Policy Table option:
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 Formatthe fields in this one:
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 correlating source address prefixes and destination address prefixes. this field delivers a label value in the [RFC6724] policy table 💖precedence: an 8-bit unsigned integer. this value is used for sorting destination addresses. this field delivers a precedence value in the [RFC6724] policy table ✨prefix-len: an 8-bit unsigned integer. it's 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 holding 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 gets padded with zeros up to the nearest octet boundary when prefix-len isn't divisible by 8. you can work it out with this 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 explains how a DHCPv6 client should process a received Address Selection option 🦋
the option is basically a hint for a node about how to act on the network. the node's admin can decide how to handle the policy info they get, but the implementation SHOULD follow the method below uniformly, so troubleshooting is easier and operating costs go down 💅
3.1. Handling Local Configurations 🌸
[RFC6724] defines two flags (A and P) and the default policy table. users can usually configure the flags and the policy table to match their own requirements too 🧚
the client implementation SHOULD provide users with these choices:
- (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 that's 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. 💖
3.2. Handling Stale Distributed Flags and Policy Table 🕰️
okay so when the info from the DHCP server goes stale 😭, the flags and the policy table that came from the server SHOULD be deprecated. Then the local configuration SHOULD be restored once the DHCP-supplied configuration has been deprecated. To make that work, a host can keep its local configuration even after the distributed flags and policy table update it. bestie, that's the backup plan we love to see 💅
The received info can be considered stale in a few situations, like when the interface goes down, when the DHCP server doesn't respond for a certain amount of time, or when the Information Refresh Time has expired ⏳
3.3. Handling Multiple Interfaces 🌐
The policy table, and the other parameters in this document, are node-global information by nature 🧠 One reason is that the outbound interface is usually picked after destination address selection. So a host can't use multiple address selection policies even if they're stored per interface. no cap, it's giving logic 🫶
The policy table is defined as a whole, so even the slightest addition or deletion changes the semantics of the policy 🎀
It's also worth noting that a DHCP-distributed policy being missing from a certain network interface doesn't mean the network administrator doesn't care about address selection policy at all 🙈 It may mean they prefer the default address selection policy. So it should be safe to assume that the default address selection policy should be used wherever no overriding policy is provided.
With those assumptions in mind, here's how to handle received policy:
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 either of the following two cases:
- 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.
- 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 ✨
- The value
labelis passed as an unsigned integer, but the value has no special meaning, meaning whether it's a big number or a small one 🔢 It's used to pick a preferred source address prefix that matches a destination address prefix, by matching the same label value within the DHCP message. DHCPv6 clients SHOULD convert this label to a representation that fits the local implementation (e.g., string). - The maximum number of address selection rules that can be sent in one DHCPv6 message depends on the prefix length of each rule and the maximum DHCPv6 message size defined in [RFC3315]. It's possible to carry over 3,000 rules in one DHCPv6 message (maximum UDP message size). However, it shouldn't 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 their specific local infrastructure can reliably transport 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 🚨
okay this part is serious bestie 😭 A rogue DHCPv6 server could issue bogus address selection policies to a client. That might lead to incorrect address selection by the client, and the affected packets might get blocked at an outgoing ISP because of ingress filtering, rack up additional network charges, or get misdirected to an attacker's machine 💀 Alternatively, an IPv6 transition mechanism might be preferred over native IPv6, even when native IPv6 is available.
To guard against these 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 use DHCP snooping at Layer 2 🛡️
Another threat is the potential privacy concern described in the security considerations section of [RFC6724]. An attacker can send packets with different source addresses to a destination, to get that destination to send responses using different source addresses 🕵️♀️ Introducing this option won't change that issue, 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.
[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.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 has 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's 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 on 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 12B.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 them different labels, the closed network prefix will only be used when packets are destined for the closed network 🔐
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 12B.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 12B.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 👑
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 12Authors' 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📦 where this page comes from
- ietf: rfc7078 2014-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms