Relay-Supplied DHCPv6 Precedence OptionsCisco Systems, Inc.Cessna Business Park, Varthur HobliSarjapur Marathalli Outer Ring RoadBangaloreKarnataka560103Indiatireddy@cisco.comCisco Systems, Inc.Cessna Business Park, Varthur HobliSarjapur Marthalli Outer Ring RoadBangaloreKarnataka560103Indiapraspati@cisco.comCisco Systems, Inc.170 West Tasman DriveSan JoseCalifornia95134USAdwing@cisco.comMIF Working GroupNetwork configuration of hosts is currently relatively static with
little consideration of dynamic network characteristics. The network
infrastructure is aware of dynamic network characteristics. This
specification extends DHCPv6 so that the DHCPv6 relay agent can
influence a host's configuration.DHCPv6 allows relatively static information to be configured in
hosts, which is somewhat limiting. On a dynamic network, the DHCPv6
relay agent can observe characteristics of a network -- such as IPv6
multihoming which might be temporarily unavailable or need load
balancing of traffic towards each upstream ISPs. By including additional
information in relayed DHCPv6 messages, the DHCPv6 relay agent can
influence the DHCPv6 server to provide answers that are better suited to
the host's configuration on the network.In this document we propose new DHCPv6 options to be added by the
DHCPv6 relay agent when it generates a Relay-Forwarded message. These
new DHCPv6 options convey information about the host and about dynamic
network characteristics to influence the DHCPv6 server to generate a
reply that is appropriate for that host and the current network
characteristics.An initial desire is to influence the DHCPv6 server's responses that
modify the host's address policy table based on observed network
characteristics.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 .The DHCPv6 extension described in this document is useful with IPv6
multihoming and with IP address-based authentication.There are two multihoming scenarios where the Absolute Precedence
option is useful.The first scenario is in multihoming with provider-aggregatable
(PA) address space, a host is given an IPv6 address from each ISP. It
is often desirable to provide some load balancing between those ISPs.
This can be accomplished by the relay agent using the Absolute
Precedence option described in the document. The relay agent can add
an Absolute Precedence option to the DHCPv6 request suggesting the
desired source prefix and prioritized destination prefixes as per the
network's load balancing schema. ISP destination prefixes can be
prioritized by setting Precedence value in the Absolute Precedence
option, i.e the prefix with higher precedence will be preferred over
the prefix with lower precedence.The second scenario is when a private link exists between two
businesses, it can be desirable for certain high-value traffic to use
that link rather than using the Internet. To use this link, the host
needs to prefer the IPv6 prefix that causes its traffic to be routed
on that link. Policy may influence which hosts are supposed to use
that link (e.g., access type, time of day).For example consider two sites, A and B, which are connected to the
Internet and also have a private, high-speed link between them. Site A
has prefix 2001:aaaa:aaaa::/48 from the high-performance network and
prefix 2007:0:aaaa::/48 from its Internet-connected service provider.
Site B has prefix 2001:bbbb:bbbb::/48 from the high-performance
network and prefix 2007:0:bbbb::/48 from its Internet-connected
service provider. The high-performance ISP is expensive and the two
sites wish to use it only for their business-critical traffic with
each other. All hosts have two IPv6 addresses and two AAAA records in
DNS. Using the new DHCPv6 options described in this document, the DHCP
relay agent would determine a host should be allowed to use the
high-performance link, so the DHCPv6 relay agent would add the
Absolute Precedence Option to the DHCPv6 request from that host. The
Absolute Precedence Option would set a higher precedence for the
high-speed prefix, destination prefix 2001:bbbb:bbbb::/48. This would
request the DHCPv6 server return a response that influences the host's
prefix policy table.Discussion: The second scenario seems solvable by grouping hosts
into separate VLANs. However, this is undesirable because segregating
using VLANs becomes cumbersome with a large number of VLANs. It also
required to configure static policy tables in the DHCPv6 server for
each VLAN, which is not commonly done today. This problem can be
better solved using the Absolute Precedence option defined in this
document. Based on various attributes, the relay agent could add an
Absolute Precedence option to the DHCPv6 request indicating the
desired source prefixes to be assigned based on the host
characteristics and destination prefixes with precedence value set
accordingly to pick the right link thus providing a cleaner solution
to the problem.Some managed networks authenticate hosts with an authentication
supplicant or, for hosts lacking the supplicant, address-based
authentication. When Address-based authentication is used,
re-authentication occurs for each address obtained by the host,
which can create a lot of authentication transactions. To reduce
this chatter, it can be useful to disable IPv6 Privacy Addresses on those hosts using
address-based authentication.The relay agent may be configured with the external prefixes that
will be assigned to the host. In that case, the relay agent would
use the Absolute Prefecedence option. In the case where the relay
agent is unaware of the external prefixes that will be assigned to
the host, the relay agent uses the Relative Precedence option.
Details for processing those options are described later in the
document.Whenever either of those options is used, a DHCPv6 server that
understands those options will ignore the IA_TA options in the
DHCPv6 request, effectively disabling the use of temporary addresses
for that host.In addition, there are known issues in managing privacy
extensions in certain scenarios. These are described in managing privacy
extensions. In such scenarios, conditionally disabling
temporary addresses allows administrators to better manage
deployments.To realize the functions described above, this document defines two
new DHCPv6 options, Relay-Supplied Prefix and Absolute Precedence. These
DHCPv6 options are added by the DHCPv6 relay agent when it relays a
DHCPv6 message, and both MAY appear together in the same DHCPv6
message.Relay-Supplied Prefix option carries host and network information
observed by the DHCPv6 relay agent such as host does not support 802.1x
supplicant and will be subjected to web-authentication. The Absolute
Precedence option allows prioritizing among a list of prefixes the
DHCPv6 relay agent expects the DHCPv6 server to provide to the host,
useful for load balancing among multiple IPv6 prefixes. Absolute
Precedence can also be used to assign different prefixes to hosts using
the same VLAN ID based on the host characteristics like device type,
health of the host, access type, etc.The Relay-Supplied Prefix option is defined below:Length of the option.8-bit unsigned integer.Must be 0 and ignored by the server.The Policy Flag is defined below, and the actions taken by the
DHCPv6 server based on this flag are described in .The layout of the Absolute Precedence is below:The fields are described below:Option LengthAn 8-bit unsigned integer. This value is
used for sorting destination addresses.8-bit unsigned integer. The number of
leading bits in the Prefix that are valid.A value of 1 indicates that the relay agent wants
the DHCPv6 server to ignore any IA_TA options in the DHCPv6
request, as if the IA_TA options were not present. This
effectively disables privacy extensions . A value of 0 indicates the IA_TA
options, if present in the DHCPv6 request, are processed normally
by the DHCPv6 server. This value has no impact on destination
prefixes.A variable-length field containing the
prefix of an IPv6 address.Must be 0 and ignored by the server.DHCPv6 relay agents that implement this specification MUST be
configurable for sending the Relay-Supplied Prefix option and the
Absolute Precedence option. Relay agents SHOULD have separate
configuration for each option to determine if it is to be added to
DHCPv6 request. A relay agent will include these options in the option
payload of a Request message. DHCPv6 relay agent should set
Relay-Supplied Prefix option when it receives DHCPv6 request from a host
with specific characteristics like authenticated using address based
mechanism. Relative Precedence option is used when the relay agent is
unaware of the external prefixes to be assigned to the host. DHCPv6
relay agent should set Absolute Precedence when there is a need to
change the precedence value for prefixes in scenario's discussed in
and/or disable IPv6 temporary
addresses for the host. Discussion: To reduce end-user configuration of the DHCPv6 relay
agent, the DHCPv6 relay agent can use the mechanism specified in
to automatically learn the IPv6
prefixes that will be delegated to DHCPv6 clients. DHCPv6 relay
agent in future can use leasequery-like capability discussed in
section 3.2 of RFC to learn the
prefix information from DHCPv6 server.Upon receiving a DHCPv6 request containing the Relay-Supplied Prefix
Option or the Absolute Precedence Option, the DHCPv6 server processing
is described below:The Relay-Supplied Prefix Option contains flags that defines the
characteristics of the host. IPV6_DIS_TEMP_ADDR - This flag indicates that Temporary IPv6
address allocation is to be disabled for the host. The DHCPv6
server should ignore any IA_TA options in the DHCPv6 request.Absolute Precedence Option - The DHCPv6 server should send a reply
to the host with the prefixes received from DHCPv6 relay agent along
with Precedence. If the option has "N" bit set to 1, the server SHOULD
ignore the IA_TA options in the DHCPv6 request, effectively disabling
the use of temporary addresses for that prefix. The DHCPv6 server will
ignore the "N" bit for destination prefixes.Note : If DHCPv6 servers receives both options with conflicting
flags IPV6_DIS_TEMP_ADDR and "N" bit then it SHOULD treat it as
mis-configuration on the relay agent and discard these options.Relay-Supplied Prefix and Absolute Precedence options are exchanged
only between the DHCPv6 relay agent and DHCPv6 server, section 21.1 of
provides details on securing DHCPv6
messages sent between servers and relay agents. And, section 23 of provides general DHCPv6 security
considerations.It is possible for a DHCPv6 client to include the Relay-Supplied
Prefix option or the Absolute Precedence option, which would be received
by a DHCPv6 server. This would cause the DHCPv6 client to receive a
different DHCPv6 response than it would have otherwise received.IANA is requested to assign option codes to OPTION_RS_PREFIX and
OPTION_ABSOLUTE_PRECEDENCE from the option-code space as defined in
section "DHCPv6 Options" of .