RFC 6334

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite

📅 published August 2011, from ietf

RFC 6334: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite 🎀

(part 1 of 2)

Title block tea 🍓

  • RFC: 6334
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: August 2011
  • Authors: D. Hankins (Google) and T. Mrugalski (Gdansk University of Technology)
  • Obsoletes / Updates: the header has no Obsoletes or Updates line, so this doc doesn't list anything it replaces or changes.

Abstract ✨

okay so this doc defines a DHCPv6 option that a Dual-Stack Lite Basic Bridging BroadBand (B4) element uses to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). 🦋

Status of This Memo 💅

This one is a full Internet Standards Track document, no cap 🏆

It's a product of the Internet Engineering Task Force (IETF) and 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 Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6334.

Copyright (c) 2011 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................2
2. Requirements Language ...........................................2
3. The AFTR-Name DHCPv6 Option .....................................2
4. DHCPv6 Server Behavior ..........................................4
5. DHCPv6 Client Behavior ..........................................4
6. Security Considerations .........................................5
7. IANA Considerations .............................................6
8. Acknowledgements ................................................6
9. Normative References ............................................6

1. Introduction 🦋

Dual-Stack Lite [RFC6333] is the solution that gives customers both IPv4 and IPv6 connectivity when they're only addressed with an IPv6 prefix (no IPv4 address is assigned to the attachment device). 💖 One of its key parts is an IPv4-over-IPv6 tunnel, usually called a softwire. A DS-Lite "Basic Bridging BroadBand" (B4) device won't know whether the network it's attached to offers Dual-Stack Lite. Even if it did, it wouldn't know the remote endpoint of the tunnel needed to set up a softwire. 😭

To tell the B4 where the Address Family Transition Router's (AFTR) location is, a DNS [RFC1035] hostname may be used. Once that info is conveyed, the presence of the configuration showing the AFTR's location also tells a host to start Dual-Stack Lite (DS-Lite) service and become a softwire initiator. 👑

To deliver that configuration, one single DHCPv6 [RFC3315] option is used, which expresses the AFTR's Fully Qualified Domain Name (FQDN) to the B4 element. 🎀

How the B4 actually sets up an IPv4-in-IPv6 softwire to the AFTR is out of scope for this document. 🙈

2. Requirements Language 📜

These are the key words that tell you how strict a rule is. 🙈 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 RFC 2119 [RFC2119].

3. The AFTR-Name DHCPv6 Option 💖

The AFTR-Name option has option-code and option-len fields (like all DHCPv6 options do), plus a variable-length tunnel-endpoint-name field. That field holds a fully qualified domain name that refers to the AFTR the client MAY connect to.

The AFTR-Name option SHOULD NOT appear in any DHCPv6 messages other than the following: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. 🚫

Here's what the format looks like: 👀

      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_AFTR_NAME: 64       |          option-len           |
     +-------------------------------+-------------------------------+
     |                                                               |
     |                  tunnel-endpoint-name (FQDN)                  |
     |                                                               |
     +---------------------------------------------------------------+

         OPTION_AFTR_NAME: 64

               option-len: Length of the tunnel-endpoint-name field in
                           octets.

     tunnel-endpoint-name: A fully qualified domain name of the AFTR
                           tunnel endpoint.

                 Figure 1: AFTR-Name DHCPv6 Option Format

The tunnel-endpoint-name field has to be formatted as required in DHCPv6 [RFC3315] Section 8 ("Representation and Use of Domain Names"). Quick version: it's a single octet holding the length of one DNS label (max 63 octets), followed by the label contents. This repeats until all the labels in the FQDN are used up, ending with a terminating zero-length label. Any updates to Section 8 of DHCPv6 [RFC3315] also apply to encoding this field. ✨ Figure 2 shows an example for the FQDN "aftr.example.com.".

      +------+------+------+------+------+------+------+------+------+
      | 0x04 |   a  |   f  |   t  |   r  | 0x07 |   e  |   x  |   a  |
      +------+------+------+------+------+------+------+------+------+
      |   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
      +------+------+------+------+------+------+------+------+------+

                  Figure 2: Example tunnel-endpoint-name

In the specific case of the example tunnel-endpoint-name (Figure 2), the tunnel-endpoint-name is 18 octets long, so an option-len field value of 18 would be used. 🧮

The option gets validated by checking that all of the following conditions are met: 🔍

  1. the option-len is greater than 3;
  2. the option-len is less than or equal to the remaining number of octets in the DHCPv6 packet;
  3. the individual label lengths do not exceed the option length;
  4. the tunnel-endpoint-name is of valid format as described in DHCPv6 Section 8 [RFC3315];
  5. there are no compression tags;
  6. there is at least one label of nonzero length.

4. DHCPv6 Server Behavior 🧚

A DHCPv6 server SHOULD NOT send more than one AFTR-Name option. It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option. Both of these conditions are handled as exceptions by the client, so an operator using software that doesn't do these validations should be careful not to configure multiple domain names. 😬

RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request option (OPTION_ORO). Just so you know, a server won't reply with an AFTR-Name option if the client hasn't explicitly listed it in its Option Request option. 💅

5. DHCPv6 Client Behavior 🌸

A client that supports the B4 functionality of DS-Lite (defined in [RFC6333]) and conforms to this specification MUST include OPTION_AFTR_NAME on its OPTION_ORO. 🫶

Because it needs a DNS name for address resolution, the client MAY also wish to include the OPTION_DNS_SERVERS [RFC3646] option on its OPTION_ORO. 🌈

If the client receives the AFTR-Name option, it MUST verify the option contents as described in Section 3. ✅

In different environments, the B4 element and DHCPv6 client may be integrated, joined, or separated by a third piece of software. For this specification, we say "B4 system" when we're talking about implementation steps that might happen at any stage of integration between the DHCPv6 client software and the B4 element it's configuring. 🧩

If the B4 system receives more than one AFTR-Name option, it MUST use only the first instance of that option. 1️⃣

If the AFTR-Name option contains more than one FQDN, as shown by multiple root labels, the B4 system MUST use only the first FQDN listed in the configuration. 🙅‍♀️

The B4 system does standard DNS resolution using the provided FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and STD 13 ([RFC1034], [RFC1035]). 🔎

If any DNS response contains more than one IPv6 address, the B4 system picks only one IPv6 address and uses it as a remote tunnel endpoint for the interface being configured in the current message exchange. The B4 system MUST NOT establish more than one DS-Lite tunnel at the same time per interface. For a redundancy and high-availability discussion, see Appendix A.3 ("High Availability") of [RFC6333]. 🛟

A B4 system may have multiple network interfaces, and those interfaces may be configured differently. Some might be on networks that call for DS-Lite, and others might be on networks using normal dual stack or other means. The B4 system should approach this specification on an interface-by-interface basis. For example, if the B4 system is attached to multiple networks that provide the AFTR-Name option, then the B4 system MUST configure a tunnel for each interface separately, since each DS-Lite tunnel provides IPv4 connectivity for each distinct interface. 🦋 How to bind an AFTR-Name and DS-Lite tunnel configuration to a given interface in a multiple-interface device is out of scope for this document.

6. Security Considerations 💀

This document doesn't present any new security issues. But, as with all DHCPv6-derived configuration state, it is completely possible that the configuration is being delivered by a third party (Man in the Middle). So there's no basis for trusting the access level represented by the DS-Lite softwire connection, and DS-Lite should therefore not bypass any security mechanisms such as IP firewalls. 🚨 Please take this one seriously, bestie.

[RFC3315] discusses DHCPv6-related security issues.

[RFC6333] discusses DS-Lite-related security issues.

7. IANA Considerations 🧾

IANA has allocated a single DHCPv6 option code, 64, referencing this document, delineating OPTION_AFTR_NAME. 🎉

8. Acknowledgements 🫶

The authors would like to thank Alain Durand, Rob Austein, Dave Thaler, Paul Selkirk, Ralph Droms, Mohamed Boucadair, Roberta Maglione, and Shawn Routhier for their valuable feedback and suggestions. 💜 The authors also acknowledge significant support for this work, provided by Internet Systems Consortium, Inc.

This work has been partially supported by the Polish Ministry of Science and Higher Education under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet Engineering Project). 🇵🇱

9. Normative References ✨

okay bestie, this is the reading list 📚 the spec is built on top of these, so you'd need them to fully get what's going on 💅

  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌸
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🧚
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
  • [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🎀
  • [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. 🦋
  • [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. 💖
  • [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. 🔥

Authors' Addresses 🫶

these are the people who wrote it, so you know exactly who to thank (or blame) 😭

David W. Hankins
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA  94043
USA

EMail: dhankins@google.com


Tomasz Mrugalski
Gdansk University of Technology
ul. Storczykowa 22B/12
Gdansk  80-177
Poland

Phone: +48 698 088 272
EMail: tomasz.mrugalski@eti.pg.gda.pl
📦 where this page comes from