RFC 8539

Softwire Provisioning Using DHCPv4 over DHCPv6

📅 published March 2019, from ietf

Softwire Provisioning Using DHCPv4 over DHCPv6 ✨

Okay bestie, let's get into it 💖 This is RFC 8539, and it's giving "how do we get the IPv4 address and the IPv6 source address to the right place without anyone losing their mind" 🦋

Here's the title block tea ☕:

  • Number and title: RFC 8539, Softwire Provisioning Using DHCPv4 over DHCPv6
  • Authors: I. Farrer (Deutsche Telekom AG), Q. Sun, Y. Cui, and L. Sun (Tsinghua University) 🎀
  • Category: Standards Track, so it's an official Internet Standard in the making 👑
  • Date: March 2019
  • Updates: RFC 7598 🌸 (this doc tweaks one of its rules, more on that below!)
  • ISSN: 2070-1721

Abstract

Okay so the vibe here is DHCPv4 over DHCPv6 ([RFC7341]) 🧚. It's a way to hand out IPv4 addresses when your network is IPv6-only. Softwires are the main example of a service that rides on top of that setup 🌈

Here's the catch 🙈 For DHCP 4o6 to play nicely with certain IPv4-over-IPv6 softwire setups (like [RFC7596] or [RFC7597]), the operator has to know the IPv6 address the client will use as the source of its IPv4-in-IPv6 tunnel. That IPv6 address, plus the client's IPv4 address, plus the Port Set ID (in some deployments), gets used to build a binding table entry in the operator's softwire tunnel concentrator. Main character energy for sure 👑

So this memo defines two things ✨

  • A DHCPv6 option to carry the IPv6 parameters needed to set up the softwire tunnel 🦋
  • A DHCPv4 option (only for use with DHCP 4o6) to pass the source tunnel IPv6 address between the DHCP 4o6 client and server 💅

It's designed to run alongside the IPv4 address allocation process, so it doesn't get in its way 🫶

Then there's the update to RFC 7598 🌸. That one describes a deterministic, DHCPv6-based way to provision softwires. This doc lets OPTION_S46_BR (90) be enumerated in the DHCPv6 client's Option Request Option (ORO) request, and lets it show up directly inside messages the DHCPv6 server sends, instead of only inside container options. Iconic restructuring, honestly 💖

Status of This Memo

This is an Internet Standards Track document, so it's official and approved 🎀

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). For more on Internet Standards, see Section 2 of [RFC7841] 📚

To check the current status, any errata, or to send feedback, head to https://www.rfc-editor.org/info/rfc8539 🌈

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, since 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 come without warranty as described in the Simplified BSD License 💜

Table of Contents

Here's the roadmap so you can find your way around 🗺️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  Updating RFC 7598 to Permit the Reuse of
        OPTION_S46_BR (90)  . . . . . . . . . . . . . . . . . . .   5
5.  DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . .   6
6.  DHCP Options  . . . . . . . . . . . . . . . . . . . . . . . .   7
  6.1.  DHCPv6 Softwire Source Binding Prefix Hint Option . . . .   7
  6.2.  DHCP 4o6 Softwire Source Address Option . . . . . . . . .   8
7.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   9
  7.1.  Client Initialization . . . . . . . . . . . . . . . . . .   9
  7.2.  Renewing or Rebinding the IPv4 Address Lease and
        Softwire Source Address . . . . . . . . . . . . . . . . .  10
    7.2.1.  Changing the Bound IPv6 Softwire Source Address . . .  10
  7.3.  Releasing the IPv4 Address Lease and Softwire
        Source Address  . . . . . . . . . . . . . . . . . . . . .  11
  7.4.  OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . .  11
  7.5.  Client and Server Softwire Source Address Mismatch  . . .  11
  7.6.  Use with Dynamic, Shared IPv4 Addresses . . . . . . . . .  12
8.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .  12
  8.1.  Changing the Bound IPv6 Source Address  . . . . . . . . .  12
  8.2.  Handling Conflicts between Clients' Bound IPv6 Source
        Addresses . . . . . . . . . . . . . . . . . . . . . . . .  12
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
  9.1.  Client Privacy Considerations . . . . . . . . . . . . . .  14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
  11.2.  Informative References . . . . . . . . . . . . . . . . .  17
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction 🌸

Okay so deterministic IPv4-over-IPv6 transition technologies need elements to be preconfigured with binding rules for routing traffic to clients. That puts a constraint on the softwire source address the client uses: it has to come from a predetermined prefix, which is usually configured on the home gateway device. [RFC7598] describes a DHCPv6-based mechanism for provisioning those deterministic softwires 💅

A dynamic provisioning model, like DHCPv4 over DHCPv6 (DHCP 4o6) [RFC7341], is way more flexible about where the IPv4-over-IPv6 softwire source address lives. In this model the IPv6 address gets communicated back to the service provider dynamically, so the matching softwire configuration can be created in the border relay (BR) ✨

The DHCP 4o6 client and softwire client could run on end devices attached to a network segment, using any routable IPv6 prefix allocated to an end user, wherever they sit in an arbitrary home network topology. Dynamic allocation also helps optimize IPv4 resource usage, because only clients that are actively renewing their IPv4 lease hang on to the address 🦋

This document describes a mechanism for dynamically provisioning softwires created with DHCP 4o6. That includes provisioning the client with the address of the softwire BR, and telling the service provider about a client's binding between its dynamically allocated IPv4 address, its Port Set ID, and the IPv6 address the softwire initiator uses to reach IPv4-over-IPv6 services 🫶

The mechanism runs alongside the DHCP 4o6 message flows to pass the binding information across the IPv6-only network. The DHCP 4o6 server acts as a single point in the network that holds the current client binding information. The service provider can then use that info to provision other functional elements, like the BR(s) 👑

2. Applicability 💜

Here's the scope check 🧐 The mechanism in this document is only suitable for provisioning softwire clients via DHCP 4o6. The options described here only apply within the DHCP 4o6 message-exchange process. The current softwire technologies that can be extended to work with DHCP 4o6 and dynamic IPv4 address leasing include [RFC7597] and [RFC7596] 🎀

3. Requirements Language 📚

Here's the BCP 14 lowdown 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🌈

4. Solution Overview 🧚

Okay so to provision a softwire, both IPv6 and IPv4 configs have to get passed to the client. To fit that into the DHCP 4o6 configuration process, the IPv6 config is carried in DHCPv6 options [RFC8415], which ride inside the DHCPv6 message DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used to provision the remote IPv6 address for the softwire BR (see Section 4.1) 🦋

OPTION_S46_BIND_IPV6_PREFIX (137) is optional. The DHCP 4o6 server may send it to tell the client which IPv6 prefix to prefer for binding the received IPv4 config and sourcing tunnel traffic. That can matter if there are multiple IPv6 prefixes in use in the customer network (like Unique Local Addresses (ULAs)), or if the specific IPv4-over-IPv6 transition mechanism needs a particular prefix for any reason 💖

IPv4 config is carried in DHCPv4 messages [RFC2131] (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism described in [RFC7341] 🌸

So the client can tell the server its softwire source address, this document defines a new DHCPv4 option, OPTION_DHCP4O6_S46_SADDR (109) ✨ It gets included in DHCPREQUEST messages sent by the client, and the server stores it for the lifetime of the IPv4 address lease 🫶

4.1. Updating RFC 7598 to Permit the Reuse of OPTION_S46_BR (90) 🌸

Section 4.2 of [RFC7598] defines OPTION_S46_BR (90) for communicating remote softwire BR IPv6 address(es) to a client. But it says the option can only be used when it's wrapped inside one of the softwire container options: OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW (96). From Section 3 of [RFC7598]:

Softwire46 DHCPv6 clients that receive provisioning options that are not encapsulated in container options MUST silently ignore these options.

This document updates [RFC7598] and removes that restriction for OPTION_S46_BR (90), so it can be enumerated in the client's ORO request and appear directly within subsequent messages sent by the DHCPv6 server 💅

(Part 1 of 4. More to come, so stay tuned, bestie 🎀✨)

5. DHCP 4o6 IPv6/IPv4 Binding Message Flow ✨

Okay so, Figure 1 shows the new bits added to the regular DHCP 4o6 IPv4 allocation client/server message flow for the softwire source address function 🦋 The whole process, errors included, gets covered in Section 7, so hang tight for that 💅

In every step, the DHCPv6 part of the message and any relevant option sits above the arrow. The DHCP 4o6 stuff and its relevant options go below the arrow. All the DHCPv4 messages get wrapped up in DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) messages 🎀 Where it matters, the necessary options and their contents are shown too.

     DHCP 4o6                                              DHCP 4o6
      Client                                                Server
        |                                                      |
        |       DHCPv6 - DHCPV4-QUERY message containing       |
        |           OPTION_ORO (6) listing (90, 137)           |
 Step 1 |----------------------------------------------------->|
        |            DHCPv4 - DHCPDISCOVER message             |
        |                                                      |
        |                                                      |
        |     DHCPv6 - DHCPV4-RESPONSE message containing      |
        | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(137)  |
        |     (bind-ipv6-prefix with service provider's        |
        |                  preferred prefix)                   |
 Step 2 |<-----------------------------------------------------|
        |              DHCPv4 - DHCPOFFER message              |
        |         containing an available IPv4 address         |
        |                                                      |
        |             DHCPv6 - DHCPV4-QUERY message            |
 Step 3 |----------------------------------------------------->|
        |     DHCPv4 - DHCPREQUEST message containing the      |
        | requested IPv4 address and OPTION_DHCP4O6_S46_SADDR  |
        |   (softwire-ipv6-src-address with client's bound     |
        |            IPv6 softwire source address)             |
        |                                                      |
        |                                                      |
        |           DHCPv6 - DHCPV4-RESPONSE message           |
 Step 4 |<-----------------------------------------------------|
        |          DHCPv4 - DHCPACK message containing         |
        | the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR |
        |    (softwire-ipv6-src-address with client's bound    |
        |              IPv6 softwire source address)           |
        |                                                      |

Figure 1: IPv6/IPv4 Binding Message Flow

Step 1 The client whips up a DHCPv6 "DHCPV4-QUERY (20)" message 💜 This message holds two options: DHCPv6 OPTION_ORO (6) and OPTION_DHCPV4_MSG (87). OPTION_ORO lists "90" (OPTION_S46_BR) and "137" (OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG carries a DHCPv4 DHCPDISCOVER message.

Step 2 The server replies with a DHCPv6 "DHCPV4-RESPONSE (21)" message 🌸 This message contains an OPTION_S46_BR (90) that holds the IPv6 address of the BR for the client's softwire configuration. The message may also optionally contain OPTION_S46_BIND_IPV6_PREFIX (137). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message, and that DHCPv4 message contains an available IPv4 address.

Step 3 The client sends a DHCPv6 "DHCPV4-QUERY (20)" message containing a DHCPv4 DHCPREQUEST message with the requested IPv4 address, plus OPTION_DHCP4O6_S46_SADDR (109) holding the IPv6 address the client will use as its softwire source address 🧚

Step 4 The server sends a DHCPv6 "DHCPV4-RESPONSE (21)" message 🍓 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message with the allocated IPv4 address. OPTION_DHCP4O6_S46_SADDR, with the client's bound softwire source address, is included too.

6. DHCP Options 🎀

6.1. DHCPv6 Softwire Source Binding Prefix Hint Option

Here's the format of the DHCPv6 source binding prefix hint option 👑

   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_BIND_IPV6_PREFIX  |         option-length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |bindprefix6-len|                                               |
  +-+-+-+-+-+-+-+-+             bind-ipv6-prefix                  .
  .                            (variable length)                  .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Format of OPTION_S46_BIND_IPV6_PREFIX

  • option-code: OPTION_S46_BIND_IPV6_PREFIX (137)
  • option-length: 1 + length of bind-ipv6-prefix, specified in bytes.
  • bindprefix6-len: 8-bit field expressing the bit mask length of the IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 128.
  • bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix for the client to bind the received IPv4 configuration to. The length is (bindprefix6-len + 7) / 8. The field is padded on the right with zero bits up to the next octet boundary when bind-ipv6-prefix is not evenly divisible by 8. These padding bits are ignored by the receiver (see Section 7.4).

OPTION_S46_BIND_IPV6_PREFIX is a singleton, so Servers MUST NOT send more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option. 🙅‍♀️

6.2. DHCP 4o6 Softwire Source Address Option

Next up, the format of the DHCPv4 over DHCPv6 softwire source address option 🦋

              0                             1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |      option-code      |     option-length     |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             +           softwire-ipv6-src-address           +
             .                  (128 bits)                   .
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figure 3: Format of OPTION_DHCP4O6_S46_SADDR

  • option-code: OPTION_DHCP4O6_S46_SADDR (109)
  • option-length: 16.
  • softwire-ipv6-src-address: 16 bytes long; the IPv6 address that is associated (either being requested for binding or currently bound) with the client's IPv4 configuration.
Note: The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the DHCPv4 message's "chaddr" field or the Client Identifier (61) option, in that it provides a unique lower-layer address that the server can use for identifying the client. However, as both of these are required to remain constant throughout the address lease lifetime, they cannot be used with the mechanism described in this document. This is because the client may only be able to construct the IPv6 address to use as the source address after it has received the first DHCPV4-RESPONSE message from the server containing OPTION_S46_BIND_IPV6_PREFIX. 🙈

7. Client Behavior 💖

A client that needs dynamic softwire configuration first turns on DHCP 4o6 configuration using the method described in Section 5 of [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the corresponding REPLY message, the client MAY continue with the configuration process described below. 🫶

Before the dynamic softwire configuration process can start, the client MUST be configured with a suitable IPv6 prefix to be used as the local softwire endpoint. This could be obtained using DHCPv6, Router Advertisement (RA) / Prefix Information Option (PIO), or another mechanism. 🌈

7.1. Client Initialization

When the client builds the initial DHCP 4o6 DHCPDISCOVER message, it includes a DHCPv6 OPTION_ORO (6) within the options field of the DHCP-QUERY message. OPTION_ORO contains the option codes for OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (137).

When the DHCP 4o6 server's reply comes back (a DHCPV4-RESPONSE containing a DHCPOFFER message), the client checks the contents of the DHCPv4-RESPONSE for a valid OPTION_S46_BR option. If this option is not present, or does not contain at least one valid IPv6 address for a BR, then the client MUST discard the message, because without the address of the BR the client cannot configure the softwire and so has no interface to request IPv4 configuration for. 🙅‍♀️

The DHCPV4-RESPONSE message may also include OPTION_S46_BIND_IPV6_PREFIX, which the operator uses to indicate a preferred prefix that the client should bind IPv4 configuration to. If it's received, the client first checks the option according to Section 7.4. If it's valid, the client uses this prefix as the "IPv6 binding prefix" and follows the process described in Section 5.1 of [RFC7596] to select an active IPv6 prefix to construct the softwire. If no match is found, or the client doesn't receive OPTION_S46_BIND_IPV6_PREFIX, the client MAY select any valid IPv6 prefix (of a suitable scope) to use as the tunnel source. 🌸

Once the client has picked a suitable prefix, it MAY either use an existing IPv6 address that is already configured on an interface or create a new address specifically for use as the softwire source address (e.g., using an Interface Identifier constructed as per Section 6 of [RFC7597]). If a new address is being created, the client MUST complete configuration of the new address, performing duplicate address detection (if required) before proceeding. 🔥

The client then builds a DHCPV4-QUERY message containing a DHCPv4 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR goes in the options field of the DHCPREQUEST message, with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field. 💅

When the client gets a DHCPv4 DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process has concluded ✨ If there's a discrepancy, the process described in Section 7.5 is followed.

If the client receives a DHCPv4 DHCPNAK message from the server, the configuration process has been unsuccessful. The client then restarts the process from Step 1 of Figure 1. 💀

7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source Address

Whenever the client tries to extend the lease time of the IPv4 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field MUST be included in the DHCPREQUEST message. 🫶💜

7.2.1. Changing the Bound IPv6 Softwire Source Address 🦋

okay so the client's IPv6 address can change during the whole time it holds the leased IPv4 address, like if there's an IPv6 renumbering event 😭 (for example).

in that situation, the client MUST inform the server of the new address 💖 It does this by sending a DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.

When the client gets a DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process is done ✨ If there's a discrepancy, the process in Section 7.5 gets followed.

If the client gets a DHCPNAK message back from the server, the change of the bound IPv6 softwire source address didn't work 💀 In this case, the client MUST stop using the new IPv6 source address. It then restarts the process from Step 1 of Figure 1.

7.3. Releasing the IPv4 Address Lease and Softwire Source Address 🍓

When the client doesn't need the IPv4 resource anymore, it sends a DHCPv4 DHCPRELEASE message to the server. The options field isn't used in this message type, so OPTION_DHCP4O6_S46_SADDR isn't included. ✨

7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior 🔍

When the client receives OPTION_S46_BIND_IPV6_PREFIX, it runs these validation checks:

  • The received bindprefix6-len value is not larger than 128.
  • The number of bytes received in the bind-ipv6-prefix field is consistent with the received bindprefix6-len value (calculated as described in Section 6.1).

If either check fails, the receiver discards the invalid option and carries on trying to configure as if that option had never arrived.

The receiver MUST only use bits from the bind-ipv6-prefix field up to the value specified in the bindprefix6-len when performing the longest prefix match. bind-ipv6-prefix bits beyond this value MUST be ignored. 🧚

7.5. Client and Server Softwire Source Address Mismatch 🙈

If the client receives a DHCPACK message with an OPTION_DHCP4O6_S46_SADDR containing an IPv6 address that's different from its active softwire source address, the client SHOULD wait for a randomized time interval and then resend the DHCPREQUEST message with the correct softwire source address. Section 4.1 of [RFC2131] describes the retransmission backoff interval process.

The default minimum time for the client to attempt retransmission is 60 seconds. If, after this time has expired, the client still hasn't received a DHCPACK message with the correct bound IPv6 address, the client MAY send a DHCPRELEASE message and restart the process described in Section 7. The retry interval should be configurable and aligned with any server policy defining the minimum time interval for client address updates, as described in Section 8.1. 🌈

7.6. Use with Dynamic, Shared IPv4 Addresses 🌸

[RFC7618] describes a mechanism for using DHCPv4 to distribute dynamic, shared IPv4 addresses to clients. The mechanism in this document is compatible with IPv4 address sharing, and you can turn it on by following the process described in Section 6 of [RFC7618]. 👑

8. Server Behavior 💅

Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the server MUST also store the IPv6 softwire source address of the client in the leasing address database, alongside the IPv4 address and client identifier.

An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source address MUST be sent in every DHCPACK message the server sends.

The binding entry between the client's IPv6 softwire source address and the leased IPv4 address stays valid for as long as the IPv4 lease remains valid. 🦋

8.1. Changing the Bound IPv6 Source Address 🔥

If the server receives a DHCPREQUEST message for an active IPv4 lease containing an OPTION_DHCP4O6_S46_SADDR with an IPv6 address that differs from the one currently stored, the server updates the stored softwire source address with the new address supplied by the client. It then sends a DHCPACK message containing the updated softwire source address in OPTION_DHCP4O6_S46_SADDR.

The server MAY implement a policy enforcing a minimum time interval between a client updating its softwire source IPv6 address. If a client tries to update the softwire source IPv6 address before that minimum time has expired, the server can either silently drop the client's message or send back a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If implemented, the default minimum client source address update interval is 60 seconds. ⭐

8.2. Handling Conflicts between Clients' Bound IPv6 Source Addresses 🧚

For traffic to get forwarded correctly, each customer edge's (CE's) softwire IPv6 source address has to be unique. To make sure this happens, on receipt of every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR, the DHCP 4o6 server MUST check the received IPv6 address against all existing CE source addresses stored for active client IPv4 leases. If there's a match for any active lease other than the lease belonging to the client sending the DHCPREQUEST, then the client's IPv6 source address MUST NOT be stored or updated.

Depending on where the client and server are in the address leasing lifecycle, the DHCP 4o6 server then does the following:

  • If the DHCP 4o6 server doesn't have a current, active IPv4 address lease for the client, the DHCP address allocation process hasn't been successful. The server sends a DHCPNAK message back to the client.
  • If the DHCP 4o6 server does have a current, active IPv4 address lease, the source address update process (see Section 8.1) hasn't been successful. The DHCP 4o6 server can either silently drop the client's message or return a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.

9. Security Considerations 🚨

Security considerations that are applicable to [RFC7341] are also applicable here.

😭 Security bestie alert: a rogue client could try to use the mechanism described in Section 7.2.1 to redirect IPv4 traffic intended for another client to itself. It would do this by sending a DHCPREQUEST message for another client's active IPv4 lease, containing the attacker's softwire IPv6 address in OPTION_DHCP4O6_S46_SADDR.

For an attack like this to work, the attacker would need to know both the client identifier and the active IPv4 address lease currently in use by another client. This could be attempted in three ways:

  1. One customer learning the active IPv4 address lease and client identifier of another customer by snooping the DHCP4o6 message flow between the client and server. The mechanism described in this document is intended for use in a typical ISP network topology with a dedicated Layer 2 access network per client, meaning that snooping another client's traffic is not possible. If the access network is a shared medium, then provisioning softwire clients using dynamic DHCP4o6 as described here is NOT RECOMMENDED.
  2. Learning the active IPv4 address lease and client identifier by snooping the DHCP4o6 message flow between the client and server in the aggregation or core ISP network. In this case, the attacker requires a level of access to the ISP's infrastructure that means they can already intercept or interfere with traffic flows to the client.
  3. An attacker brute-force guessing the IPv4 lease address and client identifier tuple. The risk of this can be reduced by using a client identifier format that isn't easily guessable, for example a random-based client identifier (see Section 3.5 of [RFC7844]).

An attacker could try to redirect existing flows to a client that's unable to process the traffic. This type of attack can be prevented by implementing network ingress filtering [BCP38] in conjunction with the BR source address validation processes described in [RFC7596] Section 5.2 and [RFC7597] Section 8.1.

A client could try to overload the server by sending multiple source address update messages (see Section 7.2.1) in a short time frame. This risk can be reduced by implementing a server policy enforcing a minimum time interval between client address changes, as described in Section 8.1. 💀

9.1. Client Privacy Considerations 🙈

[RFC7844] describes anonymity profiles for DHCP clients. These considerations and recommendations are also applicable to clients implementing the mechanism described in this document. As DHCP 4o6 only uses DHCPv6 as a stateless transport for DHCPv4 messages, the "Anonymity Profile for DHCPv4" described in Section 3 is the most relevant here.

In addition to the considerations given in [RFC7844], the mechanism the client uses for constructing the interface identifier for its IPv6 softwire source address (see Section 7.1) could make the device trackable across different networks and sessions, for example if the client's softwire Interface Identifier (IID) is immutable.

This can be mitigated by constructing the softwire source IPv6 address as per Section 6 of [RFC7597]. Here, the address's IID contains only the allocated IPv4 address (and port set identifier if [RFC7618] is being used). This means no additional client information is exposed to the DHCP 4o6 server. It also means the IID will change as the leased IPv4 address changes (for example, between sessions when Section 3.5 of [RFC7844] is implemented). 🦋

10. IANA Considerations 🌈

IANA has assigned the OPTION_S46_BIND_IPV6_PREFIX (137) option code from the DHCPv6 "Option Codes" registry maintained at http://www.iana.org/assignments/dhcpv6-parameters as follows:

       Value:             137
       Description:       OPTION_S46_BIND_IPV6_PREFIX
       Client ORO:        Yes
       Singleton Option:  Yes
       Reference:         RFC 8539

IANA has assigned the OPTION_DHCP4O6_S46_SADDR (109) option code from the "BOOTP Vendor Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters as follows:

       Tag:          109
       Name:         OPTION_DHCP4O6_S46_SADDR
       Data Length:  16
       Meaning:      DHCPv4 over DHCPv6 Softwire Source Address Option
       Reference:    RFC 8539

IANA has updated the entry for DHCPv6 OPTION_S46_BR (90) in the "Option Codes" registry maintained at https://www.iana.org/assignments/dhcpv6-parameters as follows:

Old Entry:

       Value:             90
       Description:       OPTION_S46_BR
       Client ORO:        No
       Singleton Option:  No
       Reference:         [RFC7598]

New Entry:

       Value:             90
       Description:       OPTION_S46_BR
       Client ORO:        Yes
       Singleton Option:  No
       Reference:         [RFC7598], [RFC8539]

11. References 🌸

The reference entries weren't in the text I got for this part, so I haven't written any out yet. They'll come in the next chunk.

11.1. Normative References

okay so this is the bit where the RFC shows its receipts 🧾✨ these are the docs it needs you to have read first, bestie. no cap, you can't skip them 💅

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
           RFC 2131, DOI 10.17487/RFC2131, March 1997,
           <https://www.rfc-editor.org/info/rfc2131>.

[RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
           Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
           RFC 7341, DOI 10.17487/RFC7341, August 2014,
           <https://www.rfc-editor.org/info/rfc7341>.

[RFC7598]  Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
           W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
           Configuration of Softwire Address and Port-Mapped
           Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
           <https://www.rfc-editor.org/info/rfc7598>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
           Richardson, M., Jiang, S., Lemon, T., and T. Winters,
           "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
           RFC 8415, DOI 10.17487/RFC8415, November 2018,
           <https://www.rfc-editor.org/info/rfc8415>.

11.2. Informative References

and these are the "good to know" extras 🌸 not required reading, but they give you the whole picture, and honestly they're worth a look if you're obsessed with this stuff like I am 🤓💜

[BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
           Defeating Denial of Service Attacks which employ IP Source
           Address Spoofing", BCP 38, RFC 2827, May 2000,
           <https://www.rfc-editor.org/info/bcp38>.

[RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
           Farrer, "Lightweight 4over6: An Extension to the Dual-
           Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
           July 2015, <https://www.rfc-editor.org/info/rfc7596>.

[RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
           Murakami, T., and T. Taylor, Ed., "Mapping of Address and
           Port with Encapsulation (MAP-E)", RFC 7597,
           DOI 10.17487/RFC7597, July 2015,
           <https://www.rfc-editor.org/info/rfc7597>.

[RFC7618]  Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
           Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
           RFC 7618, DOI 10.17487/RFC7618, August 2015,
           <https://www.rfc-editor.org/info/rfc7618>.

[RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
           Profiles for DHCP Clients", RFC 7844,
           DOI 10.17487/RFC7844, May 2016,
           <https://www.rfc-editor.org/info/rfc7844>.

Acknowledgements 🫶

the authors wanna give a shoutout to their people, and I'm totally here for it. Ted Lemon, Lishan Li, Tatuya Jinmei, Jonas Gorski, and Razvan Becheriu all get thanked for their contributions and comments. main character energy for the supporting cast 🌟

Authors' Addresses 💌

and here's where to find the squad behind the spec 🦋 three authors, all with their contact deets, copied exactly so you can reach out 💖

Ian Farrer
Deutsche Telekom AG
Landgrabenweg 151
Bonn, NRW  53227
Germany

Email: ian.farrer@telekom.de


Qi Sun
Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: sunqi.ietf@gmail.com


Yong Cui
Tsinghua University
Beijing  100084
China

Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn


Linhui Sun
Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com

and that's a wrap on RFC 8539!! 🌈👑 you made it bestie, we're literally so proud of us 😭🎀

📦 where this page comes from