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-code          |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  prefix6-len  |                                               |
+-+-+-+-+-+-+-+-+           ipv6-prefix                         |
|                       (variable length)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Option with IPv6 Prefix

The following description of the fields can be included in the draft:

• prefix6-len: 8 bits long field expressing the bit mask length of the IPv6 prefix specified in the ipv6-prefix field.
• ipv6-prefix: a variable length field that specifies the IPv6 prefix for (explain purpose of the prefix). The field is padded with zeros up to the nearest octet boundary when prefix6-len is not divisible by 8.

It should be pointed out that similar optimization does not provide useful savings in case of IPv4 prefixes. IPv4 prefixes should be sent as a 32 bits fields.

6. Avoid Conditional Formatting

Placing a octet at the start of the option which informs the software how to process the remaining octets of the option may appear simple to the casual observer. But the only conditional formatting methods that are in widespread use today are 'protocol' class options. So conditional formatting requires new code to be written, as well as introduces an implementation problem; as it requires that all speakers implement all current and future conditional formats.

Conditional formatting is not recommended, except in cases where the DHCPv6 option has already been deployed experimentally, and all but one conditional format is deprecated.

7. Avoid Aliasing

Options are said to be aliases of each other if they provide input to the same configuration parameter. A commonly proposed example is to configure the location of some new service ("my foo server") using a binary IP address, a domain name field, and a URL. This kind of aliasing is undesirable, and is not recommended.

In this case, where three different formats are supposed, it more than triples the work of the software involved, requiring support for not merely one format, but support to produce and digest all three. Furthermore, code development and testing must cover all possible combinations of defined formats. Since clients cannot predict what values the server will provide, they must request all formats... so in the case where the server is configured with all formats, DHCPv6 option space is wasted on option contents that are redundant.

It also becomes unclear which types of values are mandatory, and how configuring some of the options may influence the others. For example, if an operator configures the URL only, should the server synthesize a domain name and IP address?

A single configuration value on a host is probably presented to the operator (or other software on the machine) in a single field or channel. If that channel has a natural format, then any alternative formats merely make more work for intervening software in providing conversions.

So the best advice is to choose the one method that best fulfills the requirements, be that for simplicity (such as with an IP address and port pair), late binding (such as with DNS), or completeness (such as with a URL).

8. Choosing between FQDN and address

Some parameters may be specified as FQDN or an address. It is not allowed to define both option types at the same time (see section Section 7), so one of them must be chosen. This section is intended as a help to make an informed decision in that regard.

On the specific subject of desiring to configure a value using a FQDN instead of a binary IP address, note that most DHCPv6 server implementations will happily accept a Domain Name entered by the administrator, and use DNS resolution to render binary IP addresses in DHCPv6 replies to clients. Consequently, consider the extra packet overhead incurred on the client's end to perform DNS resolution itself. The client may be operating on a battery and packet transmission is a non-trivial use of power, and the extra RTT delays the client must endure before the service is configured are at least two factors to consider in making a decision on format.

Unless there are specific reasons to do otherwise, address should be used. It is simpler to use, its validation is trivial (length of 16 constitutes a valid option), is explicit and does not allow any ambiguity. It is faster (does not require extra resolution efforts), so it is more efficient, which can be especially important for energy restricted devices.

FQDN does require a resolution into an actual address. This implies number of questions that should be answered. First is when should the resolution be taken. There are couple possible answers: a) by the server, when it is started, b) by the server, when it is about to send an option, c) by the client, immediately after receiving an option, d) by the client, when the content of the option is actually consumed. For a), b) and possibly c), the option should really convey an address, not FQDN. The only real incentive to use FQDN is case d). It is the only case that allows possible changes in the DNS to be picked up by clients.

FQDN imposes number of additional failure modes and issues that should be dealt with:

• The client must have a knowledge about available DNS servers. That typically means that option DNS_SERVERS is mandatory. This should be mentioned in the draft that defines new option. It is possible that the server will return FQDN option, but not the DNS Servers option. There should be a brief discussion about it;
• The DNS may not be reachable;
• DNS may be available, but may not have appropriate information (e.g. no AAAA records for specified FQDN)
• Address family must be specified (A, AAAA or any);
• What should the client do if there are multiple records available (use only the first one, use all, use one and switch to the second if the first fails for whatever reason, etc.);
• Multi-homed devices may be connected to different administrative domains with each domain providing a different information in DNS (e.g. an enterprise network exposing private domains). Client may send DNS queries to a different DNS server;
• It should be mentioned if Internationalized Domain Names are allowed. If they are, what kind of DNS option encoding should be specified.

9. Suboptions in DHCPv6

Most options are conveyed in a DHCPv6 message directly. Although there is no codified normative language for such options, they are often referred to as top-level options. Many options may include other options. Such inner options are often referred to as sub-options. It should be noted that, contrary to DHCPv4, there is no shortage of option numbers. Therefore all options share a common option space. For example option type 1 meant different things in DHCPv4, depending if it was located in top-level or inside of Relay Agent Information option. There is no such ambiguity in DHCPv6 (with the exception of [RFC5908]).

Such encapsulation mechanism is not limited to one level. There is at least one defined option that is encapsulated twice: Identity Association for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such delegated prefix may contain an excluded prefix range that is represented by PD_EXCLUDE option that is conveyed as sub-option inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward to refer to such options as sub-sub-option, therefore "sub-option" term is typically used, regardless of the nesting level.

When defining configuration means for more complex mechanisms, it may be tempting to simply use sub-options. That should usually be avoided, as it increases complexity of the parser. It is much easier, faster and less error prone to parse larger number of options on a single (top-level) scope, than parse options on several scopes. The use of sub-options should be avoided as much as possible but it is better to use sub-options rather than conditional formatting.

It should be noted that currently there is no clear way defined for requesting sub-options. Most known implementations are simply using top-level ORO for requesting both top-level options and sub-options.

10. Additional States Considered Harmful

DHCP is a protocol designed for provisioning nodes. Less experienced protocol designers often assume that it is easy to define an option that will convey a different parameter for each node in a network. Such problems arose during designs of MAP [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While it would be easier for provisioned nodes to get ready to use per node option values, such requirement puts exceedingly large loads on the server side. Alternatives should be considered, if possible. As an example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all nodes are provisioned with the same set of MAP options and each provisioned node uses its unique address and delegated prefix to generate node-specific information. Such solution does not introduce any additional state for the server and therefore scales better.

It also should be noted that contrary to DHCPv4, DHCPv6 keeps several timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) contains T1 and T2 timers that designate time after which client will initiate renewal. Those timers apply only to its own IA containers. For renewing other parameters, please use Information Refresh Time Option (defined in [RFC4242]). Introducing additional timers make deployment unnecessarily complex. Please try to avoid it.

11. Is DHCPv6 dynamic?

DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. Contrary to its name, is many contexts it is not dynamic. While designing DHCPv6 options, it is worth noting that there is no reliable way to instantly notify clients that something has happened, e.g. parameter value has changed. There is a RECONFIGURE mechanism, but it has several serious drawbacks that makes its use difficult. First, its support is optional and many client implementations do not support it. To use reconfigure mechanism, server must use its secret nonce. That means that provisioning server is the only one that can initiate reconfiguration. Other servers do not know it and cannot trigger reconfiguration. Therefore the only reliable way for clients to refresh their configuration is to wait till T1 expires.

12. Multiple provisioning domains

In some cases there could be more than one DHCPv6 server on a link, with each provisioning a different set of parameters. One notable example of such case is a home network with a connection to two independent ISPs.

DHCPv6 was not initially designed with multiple provisioning domains. Although [RFC3315] states that a client that receives more than one ADVERTISE message, may respond to one or more, such capability was never observed in any known implementations. Existing clients will pick one server and will continue configuration process with that server, ignoring all other servers.

This is a generic DHCP protocol issue and should not be dealt within each option separately. This issue is better dealt with using a protocol-level solution and fixing this problem should not be attempted on a per option basis.

13. Considerations for Creating New Formats

If the option simply will not fit into any existing work by using fragments, the last recourse is to create a new format to fit.

When doing so, it is not enough to gauge whether or not the option format will work in the context of the option presently being considered. It is equally important to consider if the new format's fragments might reasonably have any other uses, and if so, to create the option with the foreknowledge that its parts may later become a common fragment.

One specific consideration to evaluate is whether or not options of a similar format would need to have multiple or single values encoded (whatever differs from the current option), and how that might be accomplished in a similar format.

14. Option Size

DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through its use of link-local addresses, it steps aside many of the deployment problems that plague DHCPv4, and is actually an UDP over IPv6 based protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly refers readers to RFC 2460 Section 5, which describes an MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. It's feasible to suggest that DHCPv6 is capable of having larger options deployed over it, and at least no common upper limit is yet known to have been encoded by its implementors. It is impossible to describe any fixed limit that cleanly divides those too big from the workable.

It is advantageous to prefer option formats which contain the desired information in the smallest form factor that satisfies the requirements.

DHCPv6 does allow for multiple instances of a given option, and they are treated as distinct values following the defined format, however this feature is generally preferred to be restricted to protocol class features (such as the IA_* series of options). In such cases, it is better to define an option as an array if it is possible. It is recommended to clarify (with normative language) whether a given DHCPv6 option may appear once or multiple times.

15. Clients Request their Options

The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option that serves two purposes - to inform the server what options the client supports and is willing to consume.

It doesn't make sense for some options to appear on this Option Request Option, such as those formed by elements of the protocol's internal workings, or are formed on either end by DHCPv6-level software engaged in some exchange of information. When in doubt, it is prudent to assume that any new option must be present on the relevant option request list if the client desires to receive it.

It is a frequent mistake of option draft authors, then, to create text that implies that a server will simply provide the new option, and clients will digest it. Generally, it's best to also specify that clients MUST place the new option code on the Option Request Option list, clients MAY include the new option in their packets to servers with hints as values they desire, and server MAY include the option when the client requested it (and the server has been so configured).

Example: Clients MUST place the foo option code on the Option Request Option list, clients MAY include option foo in their packets as hints for the server as values the desire, and servers MAY include option foo when the client requested it (and the server has been so configured).

Creators of DHCPv6 options MUST NOT require special ordering of options either in the relevant request option, or in the order of options within the packet. Although it is reasonable to expect that options will be processed in the order they appear in ORO, server software is not required to sort DHCPv6 options into the same order in reply messages. It should be noted that any requirement regarding option ordering will break down most existing implementations, as "order is not important" was one of the design priciples of DHCPv6 and many implementations follow it. For example, there are existing implementations that use hash maps for storing options, so forcing any particular order is not feasible without great deal of work. If options must be processed in any specific order (e.g. due to inter-dependency), use of option encapsulation should be considered.

16. Transition Technologies

Transition from IPv4 to IPv6 is progressing, albeit at somewhat disappointing pace. Many transition technologies are proposed to speed it up. As a natural consequence there are also DHCP options proposed to provision those proposals. The inevitable question is that whether the required parameters should be delivered over DHCPv4 or DHCPv6. Authors often don't give much thought about it and simply pick DHCPv6 without realizing the consequences. IPv6 is expected to stay with us for many decades, and so is DHCPv6. There is no mechanism available to deprecate an option in DHCPv6, so any options defined will stay with us as long as DHCPv6 protocol itself. It seems likely that such options defined to transition from IPv4 will outlive IPv4 by many decades. From that perspective it is better to implement provisioning of the transition technologies in DHCPv4, which will be obsoleted together with IPv4.

17. Security Considerations

DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes it possible for DHCPv6 software to discriminate between authentic endpoints and men in the middle. Other authentication mechanisms may optionally be deployed. For example, the Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated Addresses (CGA) [RFC3972], can provide source address ownership validation, message origin authentication and message integrity without requiring symmetric key pairs or supporting from any key management system. However, as of now, the mechanism is not widely deployed. It also does not provide end-to-end encryption.

So, while creating a new option, it is prudent to assume that the DHCPv6 packet contents are always transmitted in the clear, and actual production use of the software will probably be vulnerable at least to man-in-the-middle attacks from within the network, even where the network itself is protected from external attacks by firewalls. In particular, some DHCPv6 message exchanges are transmitted to multicast addresses that are likely broadcast anyway.

If an option is of a specific fixed length, it is useful to remind the implementer of the option data's full length. This is easily done by declaring the specific value of the 'length' tag of the option. This helps to gently remind implementers to validate option length before digesting them into likewise fixed length regions of memory or stack.

If an option may be of variable size (such as having indeterminate length fields, such as domain names or text strings), it is advisable to explicitly remind the implementor to be aware of the potential for long options. Either define a reasonable upper limit (and suggest validating it), or explicitly remind the implementor that an option may be exceptionally long (to be prepared to handle errors rather than truncate values).

For some option contents, out of bound values may be used to breach security. An IP address field might be made to carry a loopback address, or local broadcast address, and depending on the protocol this may lead to undesirable results. A domain name field may be filled with contrived contents that exceed the limitations placed upon domain name formatting... as this value is possibly delivered to "internal configuration" records of the system, it may be implicitly trusted without being validated.

So it behooves an option's definition to contain any validation measures as can reasonably be made.

18. IANA Considerations

This document has no actions for IANA.

19. Acknowledgements

Authors would like to thank Simon Perreault, Bernie Volz and Ted Lemon for their comments.

20. Informative 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.
[RFC3319]	Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3633]	Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3646]	Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3898]	Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3972]	Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC4075]	Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4242]	Venaas, S., Chown, T. and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4280]	Chowdhury, K., Yegani, P. and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005.
[RFC4704]	Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC5908]	Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", RFC 5908, June 2010.
[RFC5970]	Huth, T., Freimann, J., Zimmer, V. and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC6334]	Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6603]	Korhonen, J., Savolainen, T., Krishnan, S. and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6610]	Jang, H., Yegin, A., Chowdhury, K., Choi, J. and T. Lemon, "DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[I-D.ietf-dhc-secure-dhcpv6]	Jiang, S and S Shen, "Secure DHCPv6 Using CGAs", Internet-Draft draft-ietf-dhc-secure-dhcpv6-07, September 2012.
[I-D.ietf-softwire-map-dhcp]	Mrugalski, T, Troan, O, Bao, C, Dec, W and L Yeh, "DHCPv6 Options for Mapping of Address and Port", Internet-Draft draft-ietf-softwire-map-dhcp-01, August 2012.
[I-D.ietf-softwire-4rd]	Jiang, S, Despres, R, Penno, R, Lee, Y, Chen, G and M Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", Internet-Draft draft-ietf-softwire-4rd-04, October 2012.

Authors' Addresses