RFC 7598

DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients

📅 published July 2015, from ietf

DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients 🎀

okay bestie, let's get into RFC 7598 🫶

  • RFC number: 7598 (ISSN 2070-1721) 🔢
  • Date: July 2015 📅
  • Category: Standards Track, aka an Internet Standards Track document 💅
  • Authors: T. Mrugalski (ISC), O. Troan (Cisco Systems), I. Farrer (Deutsche Telekom AG), S. Perreault (Jive Communications), W. Dec (Cisco Systems), C. Bao (Tsinghua University), L. Yeh (Freelancer Technologies), and X. Deng (The University of New South Wales) 👯‍♀️
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙅‍♀️

Abstract ✨

okay so this doc defines a set of DHCPv6 options called Softwire46 options 🦋 Their whole job is to provision Softwire46 Customer Edge (CE) devices. Softwire46 is the umbrella term for architectures built on IPv4 Address plus Port (A+P), which give you IPv4 connectivity across an IPv6 network. it's giving main character energy 💖

Status of This Memo 📜

this is an Internet Standards Track document, so it's official 💅

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 send feedback, go to http://www.rfc-editor.org/info/rfc7598 🔗

Copyright (c) 2015 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 they stand on the publication date. please actually read these, bestie, because they explain what rights and restrictions you have with this document 🙈

if you extract Code Components from this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. they're also provided without warranty, as described in the Simplified BSD License 🫶

Table of Contents 🧚

1. Introduction ....................................................3
2. Conventions .....................................................3
3. Softwire46 Overview .............................................4
4. Common Softwire46 DHCPv6 Options ................................5
   4.1. S46 Rule Option ............................................5
   4.2. S46 BR Option ..............................................7
   4.3. S46 DMR Option .............................................8
   4.4. S46 IPv4/IPv6 Address Binding Option .......................9
   4.5. S46 Port Parameters Option ................................10
5. Softwire46 Containers ..........................................11
   5.1. S46 MAP-E Container Option ................................11
   5.2. S46 MAP-T Container Option ................................12
   5.3. S46 Lightweight 4over6 Container Option ...................13
6. Softwire46 Options Encapsulation ...............................14
7. DHCPv6 Server Behavior .........................................14
8. DHCPv6 Client Behavior .........................................14
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. References ....................................................16
   11.1. Normative References .....................................16
   11.2. Informative References ...................................17
Acknowledgements ..................................................18
Authors' Addresses ................................................19

1. Introduction 🌸

okay so a bunch of the architecture proposals from the IETF Softwire Working Group use Address plus Port (A+P) [RFC6346] as their base tech. the goal is giving IPv4 to end users through Customer Edge (CE) devices sitting across a service provider's IPv6 network. and it's giving flexibility, because CEs can share IPv4 addressing or get dedicated IPv4 addressing 🦋

one example is Mapping of Address and Port with Encapsulation (MAP-E), defined in [RFC7597]. MAP has one or more MAP Border Relay (BR) routers doing stateless forwarding between a MAP IPv6 domain and an IPv4 network. it also has one or more MAP Customer Edge (CE) routers forwarding between a user's IPv4 network and the MAP IPv6 network domain. the MAP CE and BR form a domain when they're configured with common service parameters. this trait is shared by all the Softwire46 mechanisms ✨

so a CE needs the right A+P service parameters for its domain to work 💅 those are mostly the CE's IPv4 address and its transport-layer port range(s). you also have to specify the IPv6 transport mode, which is either encapsulation or translation. other IPv4 config that doesn't come straight from the A+P service parameters is NOT covered here 🙅‍♀️ that stuff keeps using DHCPv4 [RFC2131], as expected.

this memo specifies a set of DHCPv6 [RFC3315] options that provision Softwire46 config to CE routers. the focus is delivering IPv4 service to an end-user network, like a home network, but it works just as well for a single host acting as a CE. configuring the BR is out of scope for this doc 🫶

2. Conventions 📖

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]. these are the capital-letter rules words, so read them carefully, bestie 🔥

3. Softwire46 Overview 🦋

this section describes a set of common DHCPv6 options for configuring three mechanisms: Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596]. for terminology, check the terminology sections in [RFC7597], [RFC7599], and [RFC7596] 📚

MAP-E, MAP-T, and Lightweight 4over6 basically do the same job: they give IPv4 service to a CE router over an IPv6-only access network 💖 MAP-E and MAP-T can embed parts of the IPv4 address in IPv6 prefixes. that lets many clients share a fixed set of mapping rules, and it enables Mesh mode, where CEs talk directly to each other. MAP-E and MAP-T CEs can also be provisioned in hub-and-spoke mode and in 1:1 mode, where there are no embedded address bits 🌈

the difference between MAP-E and MAP-T is how they reach the IPv6 domain. MAP-E uses IPv4-over-IPv6 tunneling [RFC2473], while MAP-T uses IPv4-to-IPv6 translation based on [RFC6145]. Lightweight 4over6 is a hub-and-spoke IPv4-over-IPv6 tunneling mechanism with complete independence between IPv4 and IPv6 addressing, meaning zero embedded address bits 🧚

the DHCPv6 options here tie the provisioning parameters, and so the IPv4 service itself, to the End-user IPv6 prefix lifetime. this means a Softwire46's IPv4 address, prefix, or shared IPv4 address, plus its port set, plus any authorization and accounting, all last only as long as its associated End-user IPv6 prefix does ⏳

to support more than one mechanism at a time, and to allow switching between them, the DHCPv6 Option Request Option (ORO) [RFC3315] is used 🔁 each mechanism has its own DHCPv6 container option. a DHCPv6 client asks for a particular mechanism by putting that container option's option code in its ORO. the provisioning parameters for the mechanism get embedded inside the matching container option, using the common-format options 🎀

here's the important bit: all the provisioning options only show up inside the container options. Softwire46 DHCPv6 clients that receive provisioning options NOT wrapped in a container option MUST silently ignore those options 🙈 DHCPv6 server admins are advised to make sure their servers send these options in the proper encapsulation 🫶

this document is organized with the common encapsulated options first (Section 4), followed by the three container options (Section 5). some encapsulated options are mandatory in some containers, some are optional, and some are not permitted at all. this is shown in Table 1 (Section 6) 💅

4. Common Softwire46 DHCPv6 Options 🌟

the DHCPv6 protocol is used for Softwire46 CE provisioning following the regular DHCPv6 notions. the CE takes on the role of a DHCPv6 client, and the DHCPv6 server provides options following its own server-side policies. the format and usage of each option are defined in the subsections that follow 📦

every CE needs enough info to calculate its IPv4 address, IPv4 prefix, or shared IPv4 address 🧮 MAP-E and MAP-T use the OPTION_S46_RULE option, while Lightweight 4over6 uses the OPTION_S46_V4V6BIND option. a CE that needs to talk outside the A+P domain also needs the address or prefix of the BR. MAP-E and Lightweight 4over6 use the OPTION_S46_BR option to communicate the BR's IPv6 address 🌐

MAP-T builds an IPv6 destination address by embedding an IPv4 destination address into the BR's IPv6 prefix. that prefix is conveyed through the OPTION_S46_DMR option ✨ optionally, every mechanism can include the OPTION_S46_PORTPARAMS option to specify parameters and port sets for the port-range algorithm 🦋

one more thing: Softwire46 options use addresses instead of Fully Qualified Domain Names (FQDNs). if you want the reasoning behind that design choice, see Section 8 of [RFC7227] 🧠💜

4.1. S46 Rule Option ✨

okay bestie, this is the S46 Rule option (OPTION_S46_RULE) 💖 It's how we carry the Basic Mapping Rule (BMR) and the Forwarding Mapping Rule (FMR) 🦋

This option follows the behavior from Sections 17.1.1 and 18.1.1 of [RFC3315] 🎀 Clients can send those options, wrapped in their container options, with specific values as hints for the server 🧚 The server gets to decide what it does with the hints based on its configuration and policy, so it may accept or ignore them 🙈 Clients MUST be able to process received values that are different than the hints they sent earlier, so no crying if the server says "nah" 😭 See Section 5 for details.

   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_S46_RULE        |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     flags     |     ea-len    |  prefix4-len  | ipv4-prefix   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (continued)                  |  prefix6-len  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           ipv6-prefix                         |
  |                       (variable length)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                        S46_RULE-options                       .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: S46 Rule Option

  • option-code: OPTION_S46_RULE (89) 🔥
  • option-length: length of the option, excluding the option-code and option-length fields, including the length of all encapsulated options; expressed in octets 📏
  • flags: 8 bits long 🏳️ carries flags that apply to the rule; the meanings of the specific bits are explained in Figure 2
  • ea-len: 8 bits long; specifies the Embedded Address (EA) bit length 💫 allowed values range from 0 to 48
  • prefix4-len: 8 bits long; expresses the prefix length of the Rule IPv4 prefix specified in the ipv4-prefix field 🌸 allowed values range from 0 to 32
  • ipv4-prefix: a fixed-length 32-bit field that specifies the IPv4 prefix for the S46 rule 🫶 the bits in the prefix after prefix4-len number of bits are reserved and MUST be initialized to zero by the sender and ignored by the receiver
  • prefix6-len: 8 bits long; expresses the length of the Rule IPv6 prefix specified in the ipv6-prefix field 💜 allowed values range from 0 to 128
  • ipv6-prefix: a variable-length field that specifies the IPv6 domain prefix for the S46 rule 🧁 the field is padded on the right with zero bits up to the nearest octet boundary when prefix6-len is not evenly divisible by 8
  • S46_RULE-options: a variable-length field that may contain zero or more options that specify additional parameters for this S46 rule 👑 this document specifies one such option: OPTION_S46_PORTPARAMS

The format of the S46 Rule Flags field is:

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |Reserved     |F|
                         +-+-+-+-+-+-+-+-+

Figure 2: S46 Rule Flags

  • Reserved: 7 bits; reserved for future use as flags 🌈
  • F-flag: 1-bit field that specifies whether the rule is to be used for forwarding (FMR) ⭐ if set, this rule is used as an FMR; if not set, this rule is a BMR only and MUST NOT be used for forwarding 🙅‍♀️
Note: A BMR can also be used as an FMR for forwarding if the F-flag is set. The BMR is determined by a longest-prefix match of the Rule IPv6 prefix against the End-user IPv6 prefix(es). 💅

It is expected that in a typical mesh deployment scenario there will be a single BMR, which could also be designated as an FMR using the F-flag 🦋

4.2. S46 BR Option 🌷

The S46 BR option (OPTION_S46_BR) is used to convey the IPv6 address of the Border Relay 🚪 Here's what it 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_S46_BR         |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      br-ipv6-address                          |
  |                                                               |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: S46 BR Option

  • option-code: OPTION_S46_BR (90) 🫧
  • option-length: 16
  • br-ipv6-address: a fixed-length field of 16 octets that specifies the IPv6 address for the S46 BR 💎

BR redundancy can be implemented by using an anycast address for the BR IPv6 address 🌐 Multiple OPTION_S46_BR options MAY be included in the container; this document does not further explore the use of multiple BR IPv6 addresses 🤷‍♀️

4.3. S46 DMR Option 🍓

The S46 DMR option (OPTION_S46_DMR) is used to convey values for the Default Mapping Rule (DMR) 🎀 Figure 4 shows the format of the OPTION_S46_DMR option used for conveying a DMR.

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

Figure 4: S46 DMR Option

  • option-code: OPTION_S46_DMR (91) 🌟
  • option-length: 1 + length of dmr-ipv6-prefix specified in octets 📐
  • dmr-prefix6-len: 8 bits long; expresses the bitmask length of the IPv6 prefix specified in the dmr-ipv6-prefix field 🫶 allowed values range from 0 to 128
  • dmr-ipv6-prefix: a variable-length field specifying the IPv6 prefix or address for the BR 🧃 this field is right-padded with zeros to the nearest octet boundary when dmr-prefix6-len is not divisible by 8

4.4. S46 IPv4/IPv6 Address Binding Option 🦢

The S46 IPv4/IPv6 Address Binding option (OPTION_S46_V4V6BIND) MAY be used to specify the full or shared IPv4 address of the CE 🫧 The IPv6 prefix field is used by the CE to identify the correct prefix to use for the tunnel source 🚇

   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_S46_V4V6BIND      |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         ipv4-address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |bindprefix6-len|             bind-ipv6-prefix                  |
  +-+-+-+-+-+-+-+-+             (variable length)                 |
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                      S46_V4V6BIND-options                     .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: S46 IPv4/IPv6 Address Binding Option

  • option-code: OPTION_S46_V4V6BIND (92) 💜
  • option-length: length of the option, excluding the option-code and option-length fields, including the length of all encapsulated options; expressed in octets 📏
  • ipv4-address: a fixed-length field of 4 octets specifying an IPv4 address 🌼
  • bindprefix6-len: 8 bits long; expresses the bitmask length of the IPv6 prefix specified in the bind-ipv6-prefix field 🍬 allowed values range from 0 to 128
  • bind-ipv6-prefix: a variable-length field specifying the IPv6 prefix or address for the S46 CE 🪞 this field is right-padded with zeros to the nearest octet boundary when bindprefix6-len is not divisible by 8
  • S46_V4V6BIND-options: a variable-length field that may contain zero or more options that specify additional parameters 🎁 this document specifies one such option: OPTION_S46_PORTPARAMS

4.5. S46 Port Parameters Option 🌸

The S46 Port Parameters option (OPTION_S46_PORTPARAMS) specifies optional port set information that MAY be provided to CEs 🦋 See Section 5.1 of [RFC7597] for a description of the MAP algorithm and a detailed explanation of all of the parameters 📖

   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_S46_PORTPARAMS     |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   offset      |    PSID-len   |              PSID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: S46 Port Parameters Option

  • option-code: OPTION_S46_PORTPARAMS (93) 🎀
  • option-length: 4
  • offset: Port Set Identifier (PSID) offset 🫶 8 bits long; specifies the numeric value for the S46 algorithm's excluded port range/offset bits (a-bits), as per Section 5.1 of [RFC7597] 🔢 allowed values are between 0 and 15 💫 default values for this field are specific to the softwire mechanism being implemented and are defined in the relevant specification document
  • PSID-len: 8 bits long; specifies the number of significant bits in the PSID field (also known as 'k') 🧮 when set to 0, the PSID field is to be ignored 🙈 after the first 'a' bits, there are k bits in the port number representing the value of the PSID 🌈 consequently, the address-sharing ratio would be 2^k 🍓
  • PSID: 16 bits long 🦄 the PSID value algorithmically identifies a set of ports assigned to a CE 🧁 the first k bits on the left of this field contain the PSID binary value 🫧 the remaining (16 - k) bits on the right are padding zeros

When receiving the OPTION_S46_PORTPARAMS option with an explicit PSID, the client MUST use this explicit PSID when configuring its softwire interface 🔥 The OPTION_S46_PORTPARAMS option with an explicit PSID MUST be discarded if the S46 CE isn't configured with a full IPv4 address (e.g., IPv4 prefix) 🚫

The OPTION_S46_PORTPARAMS option is contained within an OPTION_S46_RULE option or an OPTION_S46_V4V6BIND option 💅

5. Softwire46 Containers ✨

5.1. S46 MAP-E Container Option 💖

okay so the S46 MAP-E Container option (OPTION_S46_CONT_MAPE) is the container that groups together all the rules and optional port parameters for one domain. it's giving organized folder energy 📁✨

   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_S46_CONT_MAPE   |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .            encapsulated-options (variable length)             .
  .                                                               .
  +---------------------------------------------------------------+

                Figure 7: S46 MAP-E Container Option
  • option-code: OPTION_S46_CONT_MAPE (94) 🎀
  • option-length: the length of the encapsulated options, expressed in octets.
  • encapsulated-options: the options associated with this Softwire46 MAP-E domain.

the encapsulated-options field carries the options that are specific to OPTION_S46_CONT_MAPE. right now there are two of them: OPTION_S46_RULE and OPTION_S46_BR. there MUST be at least one OPTION_S46_RULE option and at least one OPTION_S46_BR option. no skipping, bestie 🙅‍♀️

other options that apply to a domain may be defined in the future 🔮. and a DHCPv6 message MAY include multiple OPTION_S46_CONT_MAPE options, one for each domain. multi-domain queen behavior 👑

5.2. S46 MAP-T Container Option 🌸

the S46 MAP-T Container option (OPTION_S46_CONT_MAPT) is also a container, and it also groups all the rules and optional port parameters for one domain. same job, different vibe 💅

   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_S46_CONT_MAPT      |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .            encapsulated-options (variable length)             .
  .                                                               .
  +---------------------------------------------------------------+

                Figure 8: S46 MAP-T Container Option
  • option-code: OPTION_S46_CONT_MAPT (95) 🦋
  • option-length: the length of the encapsulated options, expressed in octets.
  • encapsulated-options: the options associated with this Softwire46 MAP-T domain.

encapsulated-options holds the options specific to OPTION_S46_CONT_MAPT. there are two of them: OPTION_S46_RULE and OPTION_S46_DMR. there MUST be at least one OPTION_S46_RULE option and exactly one OPTION_S46_DMR option. ngl that's a very specific guest list 🎀

5.3. S46 Lightweight 4over6 Container Option 🧚

the S46 Lightweight 4over6 Container option (OPTION_S46_CONT_LW) groups all the rules and optional port parameters for one domain. yep, it's the same concept again, just for Lightweight 4over6 🫶

   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_S46_CONT_LW       |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +            encapsulated-options (variable length)             .
  .                                                               .
  +---------------------------------------------------------------+

          Figure 9: S46 Lightweight 4over6 Container Option
  • option-code: OPTION_S46_CONT_LW (96) 💜
  • option-length: the length of the encapsulated options, expressed in octets.
  • encapsulated-options: the options associated with this Softwire46 Lightweight 4over6 domain.

the encapsulated-options field carries the options specific to OPTION_S46_CONT_LW. there are two: OPTION_S46_V4V6BIND and OPTION_S46_BR. there MUST be at most one OPTION_S46_V4V6BIND option and at least one OPTION_S46_BR option. so one bind option max, but at least one BR. very precise, very iconic 💅

6. Softwire46 Options Encapsulation 🍓

so this table shows which encapsulated options are mandatory, optional, or not permitted in each container option. basically the seating chart for every container 🪑

+-----------------------+-------+-------+--------------------+
| Option                | MAP-E | MAP-T | Lightweight 4over6 |
+-----------------------+-------+-------+--------------------+
| OPTION_S46_RULE       |   M   |   M   |        N/P         |
| OPTION_S46_BR         |   M   |  N/P  |         M          |
| OPTION_S46_PORTPARAMS |   O   |   O   |         O          |
| OPTION_S46_DMR        |  N/P  |   M   |        N/P         |
| OPTION_S46_V4V6BIND   |  N/P  |  N/P  |         O          |
+-----------------------+-------+-------+--------------------+

       M - Mandatory, O - Optional, N/P - Not Permitted

            Table 1: Options for Container Mappings

Softwire46 DHCPv6 clients that receive container options that break any of the above rules MUST silently ignore those container options. 🙈 no drama, just vibes check failed ❌

7. DHCPv6 Server Behavior 🌈

Section 17.2.2 of [RFC3315] explains how a DHCPv6 client and server negotiate configuration values using the ORO. just so you know, by default a server will not reply with a Softwire46 container option if the client didn't explicitly list one in its ORO. so ask for it or don't get it 🫠

a CE router might support several mechanisms, or even all of them. if the client asks for multiple mechanisms in its ORO, the server will reply with the matching Softwire46 container options for which it has configuration information. bestie, that's a whole buffet 🍱✨

8. DHCPv6 Client Behavior 🦋

an S46 CE acting as a DHCPv6 client will ask the DHCPv6 server in the IPv6 network for S46 configuration parameters. this client MUST request, in its ORO, the S46 container option(s) it is configured for, in SOLICIT, REQUEST, RENEW, REBIND, and INFORMATION-REQUEST messages. no ORO, no config 💀

when it's processing received S46 container options, here's what's expected:

  • A client MUST support processing multiple received OPTION_S46_RULE options in a container OPTION_S46_CONT_MAPE or OPTION_S46_CONT_MAPT option. 🔥
  • A client receiving an unsupported S46 option or an invalid parameter value SHOULD discard that S46 container option and log the event. 📝

the behavior of a client that supports multiple Softwire46 mechanisms is out of scope for this document. [Unified-v4-in-v6] describes client behavior for prioritizing and handling multiple mechanisms at the same time. that's a whole other chapter, babe 📖

quick aside: a system doing CE work might have multiple network interfaces, and those interfaces might be configured differently. some could be connected to networks using a Softwire46 mechanism, and some could be on normal dual-stack or other setups. so the CE should approach this specification on an interface-by-interface basis. for example, if the CE system is MAP-E capable and is attached to multiple networks that provide the OPTION_S46_CONT_MAPE option, then the CE MUST configure MAP-E for each interface separately. every interface gets its own main character moment 🎬👑

failure modes are out of scope for this document, and failure recovery mechanisms may be defined in the future 🔮. see Section 5 of [RFC7597] for a discussion of valid MAP Rule combinations. see Section 11 of [RFC7227] and Sections 18.1.3, 18.1.4, and 19.1 of [RFC3315] for the parameter-update mechanisms in DHCPv6 that can be used to update configuration after a failure. 🛠️

9. Security Considerations 🚨

warning, this section is dramatic and it's supposed to be 😭

Section 23 of [RFC3315] discusses DHCPv6-related security issues. please read it, it's important.

as with all DHCPv6-derived configuration states, it's possible that configuration is actually being delivered by a third party (Man in the Middle). which means there's no basis on which access over MAP or Lightweight 4over6 can be trusted. so softwires should not bypass any security mechanisms, like IP firewalls. 🔐

in IPv6-only networks that don't have IPv4 firewalls, a device that supports MAP could be tricked into enabling its IPv4 stack and sending IPv4 traffic to the attacker. that would expose it to IPv4 attack vectors that were previously infeasible. this one is scary, bestie 💀

Section 10 of [RFC7597] discusses security issues related to the MAP-E mechanism. Section 9 of [RFC7596] discusses security issues related to the Lightweight 4over6 mechanism. Section 13 of [RFC7599] discusses security issues related to the MAP-T mechanism. go read all of them, no skipping 📚🫶

readers who care about the security of Softwire46 provisioning over DHCPv6 are encouraged to read [Secure-DHCPv6]. stay safe out there, babes 🛡️

10. IANA Considerations 🧾

IANA has allocated the following DHCPv6 option codes:

  • 89 for OPTION_S46_RULE 🎀
  • 90 for OPTION_S46_BR 🌸
  • 91 for OPTION_S46_DMR 🦋
  • 92 for OPTION_S46_V4V6BIND 💖
  • 93 for OPTION_S46_PORTPARAMS ✨
  • 94 for OPTION_S46_CONT_MAPE 🍓
  • 95 for OPTION_S46_CONT_MAPT 🧚
  • 96 for OPTION_S46_CONT_LW 💜

all of these values have been added to the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" option code space defined in Section 24.3 of [RFC3315]. registry slay 🗂️👑

11. References 📚

11.1. Normative References

11.2. Informative References

Okay bestie, these are the "nice to read but not required" references 📚✨ Here they all are, every detail intact:

Acknowledgements 🫶

Huge shoutout to the MAP design team! 🌈 This doc was created as a product of that team, and the members were Congxiao Bao, Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni Korhonen, Xing Li, Satoru Matsushima, Tomek Mrugalski, Tetsuya Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, Leaf Yeh, and Jan Zorz. ✨

The authors also thanked Bernie Volz and Tom Taylor for their insightful comments and suggestions. They were literally the MVPs 👑

Authors' Addresses 💌

Here's where to find the authors, if you want to reach out and say hi 🦋

Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA  94063
United States

Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com
URI:   http://www.isc.org/
Ole Troan
Cisco Systems
Philip Pedersens vei 1
Lysaker  1366
Norway

Email: ot@cisco.com
Ian Farrer
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
Bonn, NRW  53227
Germany

Email: ian.farrer@telekom.de
Simon Perreault
Jive Communications
Quebec, QC
Canada

Email: sperreault@jive.com
Wojciech Dec
Cisco Systems, Inc.
The Netherlands

Email: wdec@cisco.com
URI:   http://cisco.com
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing  100084
China

Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Leaf Y. Yeh
Freelancer Technologies
China

Email: leaf.y.yeh@hotmail.com
Xiaohong Deng
The University of New South Wales
Sydney  NSW 2052
Australia

Email: dxhbupt@gmail.com
URI:   https://www.unsw.edu.au/

And that's a wrap on RFC 7598! 🌈💖 You made it, bestie, we did it 😭🎀

📦 where this page comes from