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         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               DNS Wire Format Domain Name List                |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Option with DNS Wire Format Domain Name List

Examples of use:

• SIP Servers Domain Name List [RFC3319] (many domains)
• NIS Domain Name (many domains) [RFC3898] (many domains)
• DS-Lite AFTR location [RFC6334] (a single FQDN)
• Home Network Identifier [RFC6610] (a single FQDN)
• Home Agent FQDN [RFC6610] (a single FQDN)

6. Avoid Conditional Formatting

Placing an 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. Therefore conditional formatting requires new code to be written and complicates future interoperability should new conditional formats be added; and existing code has to ignore conditional format that it does not support.

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 an 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 message bandwidth is wasted on option contents that are redundant. Also, the DHCPv6 option space is wasted, as three new option codes are required, rather than one.

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 to help 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 options are discouraged for options intended to configure hosts, because hosts may have multiple provisioning domains (see Section 12), and may get a different answer from the DNS depending on the provisioning domain. This is particularly a problem when the normal expected use of the option makes sense with private DNS zone(s), as might be the case with a corporate VPN.

FQDN does require a resolution into an actual address. This implies the question when the FQDN resolution should be taken. There are a couple of 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 a number of additional failure modes and issues that should be dealt with:

1. 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;
2. The DNS may not be reachable;
3. DNS may be available, but may not have appropriate information (e.g. no AAAA records for specified FQDN);
4. Address family must be specified (A, AAAA or any);
5. 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.);
6. Multi-homed devices may be connected to different administrative domains with each domain providing different information in DNS (e.g. an enterprise network exposing private domains). Client may send DNS queries to a different DNS server;
7. It should be mentioned if Internationalized Domain Names are allowed. If they are, what kind of DNS option encoding should be specified.

9. Encapsulated options 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 encapsulated or nested options. Those options are sometimes called sub-options, but this term actually means something else, and therefore should never be used to describe encapsulated options. It is recommended to use term "encapsulated" as this terminology is used in [RFC3315]. The difference between encapsulated and sub-options are that the former uses normal DHCPv6 option space codes, while the latter uses option space specific to a given parent option. It should be noted that, contrary to DHCPv4, there is no shortage of option numbers. Therefore almost 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 unfortunate exception of [RFC5908], which never got proper review from the DHC working group and contains many errors, and should not under any circumstances be used as a template for future DHCP option definitions).

From the implementation perspective, it is easier to implement encapsulated options rather than sub-options, as the implementers do not have to deal with separate option spaces and can use the same buffer parser in several places throughout the code.

Such encapsulation 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 encapsulated inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward to refer to such options as sub-sub-option or doubly encapsulated option, therefore "encapsulated 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 be avoided, as it increases complexity of the parser. It is much easier, faster and less error prone to parse a 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 encapsulated options.

10. Additional States Considered Harmful

DHCP is a protocol designed for provisioning clients. Less experienced protocol designers often assume that it is easy to define an option that will convey a different parameter for each client 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 clients to get ready to use per client option values, such requirement puts exceedingly large loads on the server side. The new extensions may introduce new implementation complexity and additional database state on the server. Alternatives should be considered, if possible. As an example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all clients are provisioned with the same set of MAP options and each provisioned client uses its unique address and delegated prefix to generate client-specific information. Such a 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. Refreshing other parameters should be initiated after a time specified in the Information Refresh Time Option (defined in [RFC4242]), carried in the Reply message and returned in response to Information-Request message. Introducing additional timers make deployment unnecessarily complex and SHOULD be avoided.

11. Configuration changes occur at fixed times

In general, DHCPv6 clients only refresh configuration data from the DHCP server when the T1 timer expires. Although there is a RECONFIGURE mechanism that allows a DHCP server to request that clients initiate reconfiguration, support for this mechanism is optional and cannot be relied upon.

Even when DHCP clients refresh their configuration information, not all consumers of DHCP-sourced configuration data notice these changes. For instance, if a server is started using parameters received in an early DHCP transaction, but does not check for updates from DHCP, it may well continue to use the same parameter indefinitely. Modern notification systems take care of reconfiguring services when the client moves to a new network, but it's worth bearing in mind that a renew may not actually result in the client taking up new configuration information that it receives.

In light of the above, when designing an option you should take into consideration the fact that your option may hold stale data that will only be updated at an arbitrary time in the future.

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 a 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 of them, 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. Chartering Requirements and Advice for Responsible ADs

Adding a simple DHCP option is straightforward, and generally something that any working group can do, perhaps with some help from designated DHCP experts. However, when new fragment types need to be devised, this requires the attention of DHCP experts, and should not be done in a working group that doesn't have a quorum of such experts. This is true whether the new fragment type has the same structure as an existing fragment type, but has different semantics. It is equally true when the new format has a new structure.

Responsible Area Directors for working groups that wish to add a work item to a working group charter to define a new DHCP option should get clarity from the working group as to whether the new option is a simple DHCP option with no new fragment type or new fragment semantics, or whether it in fact will require new fragment types. A working group charter item should explicitly state which of these two types is required; if it is not known at the time of chartering, the charter should state that the working group will study the question and recharter or seek help elsewhere if a new fragment type is to be defined.

If a working group needs a new fragment type, it is preferable to seek out a working group whose members already have sufficient expertise to evaluate the new work and try to come up with a new format that generalizes well and can be reused, rather than a single-use fragment type. If such a working group is available, the work should be chartered in that working group as a separate draft that documents the new fragment type. The working group that needs the new fragment type can then define their new option referencing the new fragment type document. This work can generally be done in parallel so as not to delay the process significantly.

In the event that there is no working group with DHCP expertise that can define the new fragment type, the responsible AD should seek out help from known DHCP experts within the IETF to provide advice and frequent early review as the working group defines the new fragment type. The new fragment type should still be done in a separate document, even if it's done in the same working group, so as to foster reuse of the new fragment type. The responsible AD should work with the working group chairs and designated DHCP experts to ensure that new fragment type document has in fact been carefully reviewed by the experts and appears satisfactory.

Responsible area directors for working groups that are considering defining options that actually update the DHCP protocol, as opposed to simple options, should go through a process similar to that described above when trying to determine where to do the work. Under no circumstances should a working group be given a charter deliverable to define a new DHCP option, and then on the basis of that charter item actually make updates to the DHCP protocol.

14. Considerations for Creating New Formats

When defining new options, 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.

When defining a new option, it is best to synthesize the option format using fragment types already in use. However, in some cases there may be no fragment type that accomplishes the intended purpose.

The matter of size considerations and option order are further discussed in Section 15 and Section 17.

15. Option Size

DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through its use of link-local addresses, it avoids 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. Common sense still applies here. It is better to split distinct values into separate octets rather than propose overly complex bit shifting operations to save several bits (or even an octet or two) that would be padded to the next octet boundary anyway.

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. The default assumption is only once.

Relay agents have to do fragment reassembly and fragmentation on transmission. So while fragmentation is allowed, if a new option results in significant fragmentation, it probably isn't a good choice for DHCP configuration; instead DHCP should simply point to a URI where the configuration information can be obtained.

16. Singleton options

Although [RFC3315] states that each option type MAY appear more than once, the original idea was that multiple instances are reserved for stateful options, like IA_NA or IA_PD. For most other options it is usually expected that they will appear at most once. Such options are called singleton options. Sadly, it is often not clearly specified in RFCs that were published up to this date whether only one or more option instances are allowed. Documents that define new defined options SHOULD state whether new options are singletons or not. Unless otherwise specified, new defined options are singletons.

When deciding whether a single or multiple option instances are allowed in a message, take into consideration how the content of the option will be used. Depending on the service being configured it may or may not make sense to have multiple values configured. If multiple values make sense, it is better to explicitly allow that by using option format that allows multiple values within one option instance.

Allowing multiple option instances often leads to confusion. Consider the following example. Basic DS-Lite architecture assumes that the B4 element (DHCPv6 client) will receive AFTR option and establish a single tunnel to configured tunnel termination point (AFTR). During standardization process of [RFC6334] there was a discussion whether multiple instances of DS-Lite tunnel option should be allowed. This created an unfounded expectation that the clients receiving multiple instances of the option will somehow know when one tunnel endpoint goes off-line and do some sort of failover between other values provided in other instances of the AFTR option. Others assumed that if there are multiple options, the client will somehow do a load balancing between provided tunnel endpoints. Neither failover nor load balancing was defined for DS-Lite architecture, so it caused confusion. It was eventually decided to allow only one instance of the AFTR option.

17. Option Order

Option order, either the order among many DHCPv6 options or the order of multiple instances of the same option, SHOULD NOT be significant and MUST NOT be assumed. An exception may be security relevant options, which are often created last and put at the last position, or whose location indicates the protected range.

As there is no explicit order for multiple instance of the same option, an option definition SHOULD instead restrict the order within the option by using a list of items rather than a single item.

18. Relay Options

In DHCPv4, all relay options are organized as sub-options within DHCP Relay Agent Information Option[RFC3046]. And an independent number space called "DHCP Relay Agent Sub-options" is maintained by IANA. Different from DHCPv4, in DHCPv6, Relay options are defined in the same way as client/server options, and they too use the same number space as client/server options. Future DHCPv6 Relay options MUST be allocated from this single DHCPv6 Option code space.

However, the Relay-Supplied Options Option [RFC6422] may also contain some DHCPv6 options as permitted, such as the EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].

19. 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 to inform what options the client is willing to consume.

It doesn't make sense for some options to be requested using 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 tempting to add text that requires the client to include a new option in Option Request Option list, similar to this text: "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 MUST include option foo when the client requested it (and the server has been so configured)". Such text is discouraged as there are several issues with it. First, it assumes that client implementation that supports a given option will always want to use it. This is not true. The second and more important reason is that such text essentially duplicates mechanism already defined in [RFC3315]. It is better to simply refer to the existing mechanism rather than define it again. See Section 21 for proposed examples on how to do that.

Creators of DHCPv6 options should 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 also be noted that options values are never aligned within the DHCP packet, even the option code and option length may appear on odd byte boundaries.

20. Transition Technologies

Transition from IPv4 to IPv6 is progressing. 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 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.

When the network infrastructure becomes IPv6-only, the support for IPv4-only nodes may still be needed. In this scenario, provisioning IPv4 configuration over IPv6-only networks [I-D.ietf-dhc-v4configuration] may be needed.

21. Recommended sections in the new document

There are three major entities in DHCPv6 protocol: server, relay agent, and client. It is very helpful for implementers to include separate sections that describe operation for those three major entities. Even when a given entity does not participate, it is useful to have a very short section stating that it must not send a given option and must ignore it when received.

There is also a separate entity called requestor, which is a special client-like type that participates in leasequery protocol [RFC5007] and [RFC5460]. A similar section for the requestor is not required, unless the new option has anything to do with requestor (or it is likely that the reader may think that is has). It should be noted that while in the majority of deployments, requestor is co-located with relay agent, those are two separate entities from the protocol perspective and they may be used separately. There are stand-alone requestor implementations available.

The following sections include proposed text for such sections. That text is not required to appear, but it is appropriate in most cases. Additional or modified text specific to a given option is often required.

Although requestor is somewhat uncommon functionality, its existence should be noted, especially when allowing or disallowing options to appear in certain message or being sent by certain entities. Additional message types may appear in the future, besides types defined in [RFC3315]. Therefore authors are encouraged to familiarize themselves with a list of currently defined DHCPv6 messages available on IANA website [iana].

Typically new options are requested by clients and assigned by the server, so there is no specific relay behavior. Nevertheless it is good to include a section for relay agent behavior and simply state that there are no additional requirements for relays. The same applies for client behavior if the options are to be exchanged between relay and server.

Sections that contain option definitions MUST include formal verification procedure. Often it is very simple, e.g. option that conveys IPv6 address must be exactly 16 bytes long, but sometimes the rules are more complex. It is recommeded to refer to existing documents (e.g. section 8 of RFC3315 for domain name encoding) rather than trying to repeat such rules.

21.1. DHCPv6 Client Behavior Text

Clients MAY request option foo, as defined in [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in Option Request Option.

Optional text (if client's hints make sense): Client also MAY include option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a hint for the server regarding preferred option values.

Optional text (if the option contains FQDN): If the client requests an option that conveys an FQDN, it is expected that the contents of that option will be resolved using DNS. Hence the following text may be useful: Clients that request option foo SHOULD also request option OPTION_DNS_SERVERS specified in [RFC3646].

Clients MUST discard option foo if it is invalid (i.e. did not pass validation steps defined in Section X.Y).

Optional text (if option foo in expected to be exchanged between relays and servers): Option foo is exchanged between relays and servers only. Clients are not aware of the usage of option foo. Clients MUST ignore received option foo.

21.2. DHCPv6 Server Behavior Text

Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and the client requested it.

Optional text: Option foo is a singleton. Servers MUST NOT send more than one instance of foo option.

Optional text (if server is never supposed to receive option foo): Servers MUST ignore incoming foo option.

21.3. DHCPv6 Relay Agent Behavior Text

It's never appropriate for a relay agent to add options to a message heading toward the client, and relay agents don't actually construct Relay-Reply messages anyway.

Optional text (if foo option is exchanged between clients and server or between requestors and servers): There are no additional requirements for relays.

Optional text (if relays are expected to insert or consume option foo): Relay agents MAY include option foo in a Relay-Forw when forwarding packets from clients to the servers.

22. Should the new document update existing RFCs?

Authors often ask themselves a question whether their proposal updates exist RFCs, especially 3315. In April 2013 there were about 80 options defined. Had all documents that defined them also updated RFC3315, comprehension of such a document set would be extremely difficult. It should be noted that "extends" and "updates" are two very different verbs. If a new draft defines a new option that clients request and servers provide, it merely extends current standards, so "updates 3315" is not required in the new document header. On the other hand, if a new document replaces or modifies existing behavior, it should be noted that it updates the other document. For example, [RFC6644] clearly updates [RFC3315] as it replaces existing with new text.

23. Security Considerations

DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes it possible for DHCPv6 software to discriminate between authentic endpoints and man-in-the-middle. Other authentication mechanisms may optionally be deployed.

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 multicast 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.

Authors of drafts defining new DHCP options are therefore strongly advised to explicitly define validation measures that recipients of such options are required to do before processing such options. However, validation measures already defined by RFC3315 or other specifications referenced by the new option document are redundant, and can introduce errors, so authors are equally strongly advised to refer to the base specification for any such validation language rather than copying it into the new specification.

24. IANA Considerations

This document has no actions for IANA.

25. Acknowledgements

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

26. References

26.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.

26.2. Informative References

[RFC3046]	Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[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.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 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.
[RFC4833]	Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 4833, April 2007.
[RFC5007]	Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460]	Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[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.
[RFC6422]	Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.
[RFC6440]	Zorn, G., Wu, Q. and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 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.
[RFC6644]	Evans, D., Droms, R. and S. Jiang, "Rebind Capability in DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[I-D.ietf-softwire-map-dhcp]	Mrugalski, T., Troan, O., Bao, C., Dec, W., Yeh, L. and X. Deng, "DHCPv6 Options for Mapping of Address and Port", Internet-Draft draft-ietf-softwire-map-dhcp-02, February 2013.
[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.
[I-D.ietf-dhc-v4configuration]	Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Over IPv6 Only Networks", Internet-Draft draft-ietf-dhc-v4configuration-01, May 2013.
[iana]	IANA, , "DHCPv6 parameters (IANA webpage)", November 2003.

Authors' Addresses