RFC 7678

Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions

📅 published October 2015, from ietf

📜 RFC 7678: Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions 🎀

okay bestie, title block time 💅✨ this one is an Internet Standards Track doc 🔥 (category: Standards Track), so it's a real official spec and not just vibes 🫶

  • Number: RFC 7678 🌸
  • Date: October 2015 🍓
  • Authors: C. Zhou (Huawei Technologies), T. Taylor (PT Taylor Consulting), Q. Sun (China Telecom), and M. Boucadair (France Telecom) 👑
  • ISSN: 2070-1721 💜
  • Obsoletes / Updates: the title block doesn't list either one, so there's nothing to call out here 🙈

The whole point of this doc is giving you a list of AVPs (Attribute-Value Pairs) for Diameter, so customer equipment can get the info it needs for IPv4-over-IPv6 transition methods. The methods covered are DS-Lite, lw4o6, and MAP-E 🦋. Diameter is defined in RFC 6733 🧚

Status of This Memo ✨

This is an Internet Standards Track document 🌈

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 🫶

Errata and feedback info lives at http://www.rfc-editor.org/info/rfc7678 🔥

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 were on the publication date. Please actually read those, bestie, because they explain your rights and restrictions 🙈 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🎀

Table of Contents 🌸

Here's the outline, page numbers and all 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
2.  Description of the Parameters Required by Each Transition
    Method  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Parameters for Dual-Stack Lite (DS-Lite)  . . . . . . . .   6
  2.2.  Lightweight 4over6 (lw4o6)  . . . . . . . . . . . . . . .   6
  2.3.  Port Set Specification  . . . . . . . . . . . . . . . . .   7
  2.4.  Mapping of Address and Port with Encapsulation (MAP-E)  .   7
  2.5.  Parameters for Multicast  . . . . . . . . . . . . . . . .   8
  2.6.  Summary and Discussion  . . . . . . . . . . . . . . . . .   9
3.  Attribute-Value Pair Definitions  . . . . . . . . . . . . . .   9
  3.1.  IP-Prefix-Length AVP  . . . . . . . . . . . . . . . . . .  10
  3.2.  Border-Router-Name AVP  . . . . . . . . . . . . . . . . .  10
  3.3.  64-Multicast-Attributes AVP . . . . . . . . . . . . . . .  10
    3.3.1.  ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . .  11
    3.3.2.  SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . .  11
    3.3.3.  Delegated-IPv6-Prefix AVP as uPrefix64  . . . . . . .  12
  3.4.  Tunnel-Source-Pref-Or-Addr AVP  . . . . . . . . . . . . .  12
    3.4.1.  Delegated-IPv6-Prefix as the IPv6 Binding Prefix  . .  12
    3.4.2.  Tunnel-Source-IPv6-Address AVP  . . . . . . . . . . .  12
  3.5.  Port-Set-Identifier . . . . . . . . . . . . . . . . . . .  13
  3.6.  Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . .  13
    3.6.1.  Lw4o6-External-IPv4-Addr AVP  . . . . . . . . . . . .  14
  3.7.  MAP-E-Attributes  . . . . . . . . . . . . . . . . . . . .  14
  3.8.  MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . .  15
  3.9.  MAP-Mapping-Rule  . . . . . . . . . . . . . . . . . . . .  15
    3.9.1.  Rule-IPv4-Addr-Or-Prefix AVP  . . . . . . . . . . . .  16
    3.9.2.  Rule-IPv6-Prefix AVP  . . . . . . . . . . . . . . . .  16
    3.9.3.  EA-Field-Length AVP . . . . . . . . . . . . . . . . .  17
4.  Attribute-Value Pair Flag Rules . . . . . . . . . . . . . . .  18
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
  6.1.  Man-In-The-Middle (MITM) Attacks  . . . . . . . . . . . .  19
  6.2.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  20
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  21
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction 🦋

okay so the big idea 💅 IPv4 packets need to get from hosts to IPv4 networks, but they have to cross an IPv6 network in the middle, and the whole goal is to use as few public IPv4 addresses as possible 😭 different operators pick different tech, and sometimes one operator uses more than one, depending on what their gear supports and other technical and economic stuff 🫶

Each technique needs some subscriber-specific info provisioned on the customer edge device 🎀 That provisioning might come through DHCPv6 [RFC3315] or some other method. This doc doesn't care which one you use 🙈 It does assume the info is managed by AAA (Authentication, Authorization, and Accounting) servers, and that the info gets delivered to intermediate network nodes for onward provisioning using the Diameter protocol [RFC6733] 💖

In the lw4o6 case [RFC7596], per-subscriber-site info that's almost identical to what goes to the subscriber site [RFC7598] also has to get delivered to the border router serving that site 🌈 Diameter can be used for that too 🧚

This doc analyzes the info needed to configure customer edge equipment for these transition methods:

  • Dual-Stack Lite (DS-Lite) [RFC6333]
  • Lightweight 4over6 (lw4o6) [RFC7596]
  • Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597]

[DSLITE-MULTICAST] is a generic solution for delivering IPv4 multicast services to IPv4 clients over an IPv6 multicast network 🔥 It was built with DS-Lite in mind, but it isn't limited to DS-Lite, so it applies to lw4o6 and MAP-E too 👑 This doc looks at the info needed for multicast support in the context of DS-Lite, MAP-E, and lw4o6 in particular ✨

Based on those analyses, the doc specifies a bunch of AVPs so the subscriber-site configuration info can be carried in Diameter 💅

This doc doesn't specify any new commands or Application IDs 🙈 The AVPs could be used by any Diameter application that's suitable for provisioning 🌸

1.1. Requirements Language 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 🫶

CPE stands for Customer Premise Equipment 🏠 It's the gear at the customer edge that terminates the customer end of an IPv6 transitional tunnel 🦋 This is usually a router, but it could be a host plugged directly into the network 🎀 Some docs (like [RFC7597]) call this same thing CE (Customer Edge) 🌸

The term "tunnel source address" means the IPv6 source address used in the outer header of packets the CPE sends through an lw4o6 transitional tunnel to the border router 🧚

2. Description of the Parameters Required by Each Transition Method 🌈

This section goes through the parameters that need provisioning for each transition method listed above 🔥 This list is the justification for the AVPs in the next section 💖

A means is REQUIRED to say which transition method(s) a subscriber wants to use 👑 This doc handles that by specifying Grouped AVPs for lw4o6 and MAP-E 💅 The operator controls which of those two a subscriber uses by making sure AAA passes only the Grouped AVP for that method ✨ A Grouped AVP isn't needed for DS-Lite, since AAA only has to provide the FQDN (Fully Qualified Domain Name) of the DS-Lite AFTR (Address Family Transition Router) 🙈 See Section 2.1 🫶 So if there's no Grouped AVP for lw4o6 or MAP-E and only the AFTR's FQDN is present, that means the subscriber equipment uses DS-Lite 🦋 Provisioning multicast is a separate thing, since it doesn't depend on the transition method 🎀

2.1. Parameters for Dual-Stack Lite (DS-Lite) 🌸

DS-Lite is documented in [RFC6333] 🧚 The Basic Bridging BroadBand (B4) element at the customer premises NEEDS to discover the IPv6 address of the AFTR (border router) 🔥 Hmm, wait, I need to fix that: the original says this is a need, so here it is properly: the B4 element at the customer premises needs to discover the IPv6 address of the AFTR (border router) 💖 For the reasons in Section 3.2, the AAA server provisions the B4 element with the AFTR's FQDN, which gets passed to a B4's IP resolution library 🌈 The AFTR's FQDN is carried in the Border-Router-Name AVP (see Section 3.2) 👑

The B4 element could also be configured with the IPv4 address of the B4 interface facing the tunnel 💅 Valid values run from 192.0.0.2 to 192.0.0.7, and the default is 192.0.0.2 when nothing is provisioned ✨ Provisioning that through AAA is a problem, because it's most likely used when multiple B4 instances live on the same device 🙈 So this doc assumes the B4 interface address is determined by other means than AAA (implementation dependent or static assignment) 🫶

(Part 1 of 4 — more to come, bestie! 🎀✨)

2.2. Lightweight 4over6 (lw4o6) ✨

okay so lw4o6 is documented in [RFC7596] 🦋 and it needs four items provisioned to the customer equipment (CPE). bestie, these are the whole vibe:

  • an IPv6 address of the border router.
  • an IPv6 prefix the CPE uses to build the tunnel source address. In the [RFC7596] terminology, this is the IPv6 Binding Prefix. 💜
  • an IPv4 address to use on the external side of the CPE.
  • if the IPv4 address is shared, a port set the subscriber site is allowed to use. see Section 2.3 for the deets 🎀 For lw4o6, all three of the parameters 'a', 'k', and the Port Set Identifier (PSID) described in that section are required. The default value of the offset parameter 'a' is 0.

As discussed in Section 4 of [RFC7596], this config has to be synced with the matching per-subscriber config at the border router 🫶 The border router side has the same public IPv4 address and port set parameters that get passed to the CPE, bound together with the full /128 IPv6 address (not just the Binding Prefix) that's configured as the tunnel source address at the CPE. it's giving matching outfits 👯‍♀️

2.3. Port Set Specification 🌸

okay so when an external IPv4 address is shared, lw4o6 and MAP-E both restrict the CPE to a subset of all the available ports on the external side. 🙈 Both transition methods use the algorithm defined in Appendix B of [RFC7597] to work out the port numbers in the port set. The algorithm has three parameters that describe where the PSID sits in each port number of the generated set and what its value is:

  • an offset 'a' from the beginning of the port number to the first bit of the PSID;
  • the length 'k' of the PSID within the port number, in bits; and
  • the value of the PSID itself.

2.4. Mapping of Address and Port with Encapsulation (MAP-E) 🧚

Mapping of Address and Port with Encapsulation (MAP-E) is described in [RFC7597] ✨ MAP-E needs the following per-subscriber info provisioned at the customer edge device:

  • the IPv6 address of one or more border routers, or in MAP-E terminology, MAP-E border relays.
  • the unique end-user IPv6 prefix for the customer edge device. This may come from AAA or be acquired by other means.
  • the Basic Mapping Rule for the customer edge device. this includes:
    • the Rule IPv6 prefix and length.
    • the Rule IPv4 prefix and length. A prefix length of 0 means the entire IPv4 address or prefix is coded in the Extended Address (EA) bits of the end-user IPv6 prefix instead of in the mapping rule. 🍓
    • the number of EA bits included in the end-user IPv6 prefix.
    • port set parameters giving the set of ports the CPE is allowed to use when the IPv4 address is shared. Check Section 2.3 for these. At a minimum, the offset parameter 'a' is required. For MAP-E, this has the default value 6. The parameters 'k' and PSID are needed if they can't be derived from the mapping rule info and the EA bits (final case of Section 5.2 of [RFC7597]).
  • whether the device is to operate in Mesh or Hub-and-Spoke mode.
  • in mesh mode only, zero or more Forwarding Mapping Rules described by the same set of parameters as the Basic Mapping Rule.

As the first bullet in Section 5 of [RFC7597] points out, a MAP CPE can be provisioned with multiple end-user IPv6 prefixes, each linked to its own Basic Mapping Rule. 👑 This doesn't change the basic requirement for representing that info as Diameter AVPs, but it adds a potential need for multiple instances of this info in the Diameter message, differing in the value of the end-user IPv6 prefix (unlike the Forward Mapping Rule instances).

The border router needs to be configured with the superset of the Mapping Rules passed to the customer sites it serves. Since this doesn't require direct coordination with CPE config the way lw4o6 does, it's out of scope for this document 💅 However, the AVPs defined here may be useful if a separate Diameter application is used to configure the border router.

2.5. Parameters for Multicast 📡

[DSLITE-MULTICAST] is a generic solution for delivering IPv4 multicast services to IPv4 clients over an IPv6 multicast network. It can be deployed in a DS-Lite context but is also adaptable to lw4o6 and MAP-E. For example, [PREFIX-OPTION] shows how DHCPv6 [RFC3315] can be used to provision multicast-related info. Here's the multicast info that needs to be provisioned:

  • ASM-mPrefix64: the IPv6 multicast prefix used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Any-Source Multicast (ASM) mode. This is done by concatenating the ASM-mPrefix64 and an IPv4 multicast address. The IPv4 multicast address goes in the last 32 bits of the IPv4-embedded IPv6 multicast address. 🦄
  • SSM-mPrefix64: the IPv6 multicast prefix used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Source-Specific Multicast (SSM) [RFC4607] mode. This is done by concatenating the SSM-mPrefix64 and an IPv4 multicast address. The IPv4 multicast address goes in the last 32 bits of the IPv4-embedded IPv6 multicast address.
  • uPrefix64: the IPv6 unicast prefix used in SSM mode to construct the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. uPrefix64 may also be used to extract the IPv4 address from the received multicast data flows. The address mapping follows the guidelines in [RFC6052].

2.6. Summary and Discussion 🎀

Two items are common to the different transition methods, and the matching AVPs that carry them can be reused:

  • a representation of the IPv6 address of a border router.
  • a set of prefixes for delivering multicast services to IPv4 clients over an IPv6 multicast network.

[RFC6519] sets the precedent of representing a border router's IPv6 address as an FQDN. The provisioning system can resolve this to one or more IP addresses before passing it to the customer equipment, or leave it as an FQDN like in [RFC6334] 🌈

The remaining requirements are specific to each transition method:

  • for lw4o6, a representation of a binding between (1) either the IPv6 Binding Prefix or a full /128 IPv6 address, (2) a public IPv4 address, and (3) (if the IPv4 address is shared) a port set identifier.
  • for MAP-E, a representation of the unique end-user IPv6 prefix for the CPE, if it isn't provided by other means.
  • for MAP-E, a representation of a Mapping Rule.
  • for MAP-E, an indication of whether Mesh mode or Hub-and-Spoke mode is to be used.

3. Attribute-Value Pair Definitions 💖

This section gives the specs for the AVPs needed to meet the requirements summarized in Section 2.6. ✨

3.1. IP-Prefix-Length AVP 🍓

The IP-Prefix-Length AVP (AVP code 632) is of type Unsigned32. It gives the length of an IPv4 or IPv6 prefix. Valid values are from 0 to 32 for IPv4 and from 0 to 128 for IPv6. Tighter limits are given below for particular contexts of use of this AVP.

Note that the IP-Prefix-Length AVP is only relevant when it's associated with an IP-Address AVP in a Grouped AVP. 🙈

3.2. Border-Router-Name AVP 🌷

Following the precedent set by [RFC6334] and [RFC6519], this document identifies a border router using an FQDN rather than an address. The Border-Router-Name AVP (AVP Code 633) is of type OctetString. The FQDN encoding MUST follow the Name Syntax defined in [RFC1035], [RFC1123], and [RFC2181], and it is represented in ASCII form. 🔥 Note, if Internationalized Domain Names (IDNs) are used, A-labels defined in [RFC5891] must be used (see Appendix D of [RFC6733]).

3.3. 64-Multicast-Attributes AVP 🦋

The 64-Multicast-Attributes AVP (AVP Code 634) is of type Grouped. It contains the multicast-related IPv6 prefixes needed for providing IPv4 multicast over IPv6 using DS-Lite, MAP-E, or lw4o6, as mentioned in Section 2.5. 🧚

The syntax is shown in Figure 1.

        64-Multicast-Attributes  ::= < AVP Header: 634 >
                                     [ ASM-mPrefix64 ]
                                     [ SSM-mPrefix64 ]
                                     [ Delegated-IPv6-Prefix ]
                                    *[ AVP ]

                Figure 1: 64-Multicast-Attributes AVP

The 64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the SSM-mPrefix64 AVP, and it MAY include both. 💅

The Delegated-IPv6-Prefix AVP MUST be present when the SSM-mPrefix64 AVP is present. The Delegated-IPv6-Prefix AVP MAY be present when the ASM-mPrefix64 AVP is present. 🫶

3.3.1. ASM-mPrefix64 AVP 🌸

The ASM-mPrefix64 AVP (AVP Code 635) conveys the value of ASM-mPrefix64 as mentioned in Section 2.5. The ASM-mPrefix64 AVP is of type Grouped, as shown in Figure 2.

          ASM-mPrefix64  ::= < AVP Header: 635 >
                             { IP-Address }
                             { IP-Prefix-Length }
                            *[ AVP ]

                     Figure 2: ASM-mPrefix64 AVP

IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the ASM-mPrefix64 AVP, it provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the ASM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver. 🔥

The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the ASM-mPrefix64 AVP, valid values of the IP-Prefix-Length AVP are from 24 to 96. 🍓

3.3.2. SSM-mPrefix64 AVP 👑

The SSM-mPrefix64 AVP (AVP Code 636) conveys the value of SSM-mPrefix64 as mentioned in Section 2.5. The SSM-mPrefix64 AVP is of type Grouped, as shown in Figure 3.

          SSM-mPrefix64  ::= < AVP Header: 636 >
                             { IP-Address }
                             { IP-Prefix-Length }
                            *[ AVP ]

                     Figure 3: SSM-mPrefix64 AVP

IP-Address (AVP code 518) provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the SSM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver. 💜

The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. 🌈

3.3.3. Delegated-IPv6-Prefix AVP as uPrefix64 🧁

Within the 64-Multicast-Attributes AVP, the Delegated-IPv6-Prefix AVP (AVP Code 123) conveys the value of uPrefix64, a unicast IPv6 prefix, as mentioned in Section 2.5. The Delegated-IPv6-Prefix AVP is defined in [RFC4818]. As specified by [RFC6052], the value in the Prefix-Length field MUST be one of 32, 48, 56, 64, or 96. ✨

3.4. Tunnel-Source-Pref-Or-Addr AVP ✨

Okay bestie, the Tunnel-Source-Pref-Or-Addr AVP (AVP Code 637) is the one carrying either the IPv6 Binding Prefix or the tunnel source address on the CPE, like we covered in Section 2.2 🦋. It's type Grouped with the syntax in Figure 4. It MUST contain either the Delegated-IPv6-Prefix AVP or the Tunnel-Source-IPv6-Address AVP, not both 💅

Tunnel-Source-Pref-Or-Addr  ::= < AVP Header: 637 >
                                [ Delegated-IPv6-Prefix ]
                                [ Tunnel-Source-IPv6-Address ]
                               *[ AVP ]

Figure 4: Tunnel-Source-Pref-Or-Addr AVP

So why is this one its own AVP and not just stuffed inside lw4o6-Binding? 🤔 It's kept separate so the tunnel source address can be moved from the provisioning system to AAA with some flexibility, while still letting the lw4o6 border router get a complete binding 🌸

3.4.1. Delegated-IPv6-Prefix as the IPv6 Binding Prefix

The Delegated-IPv6-Prefix AVP (AVP code 123) is type OctetString and it's defined in [RFC4818] 📦 Inside the Tunnel-Source-Pref-Or-Addr AVP, it carries the IPv6 Binding Prefix assigned to the CPE. Valid values in the Prefix-Length field go from 0 to 128 (full address) ✨

3.4.2. Tunnel-Source-IPv6-Address AVP

The Tunnel-Source-IPv6-Address AVP (AVP code 638) is type Address. It gives the address the CPE assigned to itself as its local end of an lw4o6 tunnel 🦋 The AddressType field in this AVP MUST be set to 2 (IPv6) 💖

3.5. Port-Set-Identifier

The Port-Set-Identifier AVP (AVP Code 639) is a structured OctetString with four octets of data, so the total AVP length is 12 🎀 It's built from the parameters in Section 2.3 (check Figure 5 👀).

  • The first (high-order) octet is the Offset field. It's an 8-bit unsigned integer that gives the offset 'a' from the start of a port number to the start of the PSID that port belongs to. Valid values are from 0 to 15 🌈
  • The next octet, the PSIDLength, is also an 8-bit unsigned integer, and it gives the length 'k' in bits of the PSID. Valid values are from 0 to (16 - a). A value of 0 means the PSID is not present (the probable case for MAP-E, see Section 2.4), and the PSIDValue field MUST be ignored 🙈
  • The final two octets hold the PSIDValue field. That's the PSID's actual value, right justified inside the field, so the PSID lives in the 'k' lowest-order bits of PSIDValue 🧚
 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Offset     |    Length     |        PSID  Value            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Port Set

3.6. Lw4o6-Binding AVP

The Lw4o6-Binding AVP (AVP Code 640) is type Grouped 🍓 It holds the config bits that make up the binding between an lw4o6 tunnel and the IPv4 packets sent through that tunnel, as described in Section 2.2. Check the layout in Figure 6:

Lw4o6-Binding  ::= < AVP Header: 640 >
                   { Tunnel-Source-Pref-Or-Addr }
                   { Lw4o6-External-IPv4-Addr }
                   [ Port-Set-Identifier ]
                  *[ AVP ]

Figure 6: Lw4o6-Binding AVP

The Tunnel-Source-Pref-Or-Addr AVP is defined in Section 3.4 and gives either the Binding Prefix or the full IPv6 tunnel source address 💅

The Lw4o6-External-IPv4-Addr AVP is defined in Section 3.6.1 🦋

The Port-Set-Identifier AVP is defined in Section 3.5. It identifies the specific set of ports given to the lw4o6 tunnel when the IPv4 address is being shared 🌸

3.6.1. Lw4o6-External-IPv4-Addr AVP

The Lw4o6-External-IPv4-Addr AVP (AVP Code 641) uses the Address derived data format from Section 4.3.1 of [RFC6733] 📚 It gives the CPE's external IPv4 address inside the lw4o6 tunnel tied to that binding. The AddressType field MUST be set to 1 (IPv4), and the total length of the AVP MUST be 14 octets 💖

3.7. MAP-E-Attributes

The MAP-E-Attributes AVP (AVP Code 642) is type Grouped 💜 It holds the config data from Section 2.4 for all the mapping rules (Basic and Forwarding) in a single MAP domain. If the CPE belongs to multiple MAP domains, you'll see multiple instances of this AVP 🌈

MAP-E-Attributes  ::= < AVP Header: 642 >
                1*{ Border-Router-Name }
                1*{ MAP-Mapping-Rule }
                  [ MAP-Mesh-Mode ]
                  [ Delegated-IPv6-Prefix ]
                 *[ AVP ]

Figure 7: MAP-E-Attributes AVP

The Border-Router-Name AVP is defined in Section 3.2. It gives the FQDN of a MAP border relay at the edge of the MAP domain that this MAP-E-Attributes AVP is about. At least one instance of this AVP MUST be present 🫶

The MAP-Mapping-Rule AVP is defined in Section 3.9. At least one instance of this AVP MUST be present. If the MAP-E domain supports Mesh mode (shown by the MAP-Mesh-Mode AVP being there), additional MAP-Mapping-Rule instances MAY be present. If the MAP-E domain is operating in Hub-and-Spoke mode; additional MAP-Mapping-Rule instances MUST NOT be present 🙅‍♀️

The MAP-Mesh-Mode AVP is defined in Section 3.8. If the Mesh mode indicator attribute is absent, the CPE is required to operate in Hub-and-Spoke mode 🎀

The Delegated-IPv6-Prefix AVP (AVP Code 123) gives the end-user IPv6 prefix assigned to the CPE for the MAP domain this MAP-E-Attributes AVP is about. The AVP is defined in [RFC4818]. Valid values of the Prefix-Length field range from 0 to 128 🌸

The Delegated-IPv6-Prefix AVP is optional, because depending on the deployment, the end-user IPv6 prefix may be provided by AAA or by other means 🧚 If multiple instances of the MAP-E-Attributes AVP contain the Delegated-IPv6-Prefix AVP, each instance of the latter MUST have a different value 🍓

3.8. MAP-Mesh-Mode

The MAP-Mesh-Mode AVP (AVP Code 643) is type Enumerated, and it says whether the CPE has to operate in Mesh or Hub-and-Spoke mode when using MAP-E 💅 These values are supported:

0 MESH
1 HUB_AND_SPOKE

If the Mesh mode indicator attribute is absent, the CPE is required to operate in Hub-and-Spoke mode 🙈

3.9. MAP-Mapping-Rule

The MAP-Mapping-Rule AVP (AVP Code 644) is type Grouped, and it's only used with MAP-based transition methods 🌈 Mapping rules are required by both the MAP border relay and the CPE. The parts of the MAP-Mapping-Rule AVP carry the contents of a mapping rule, as described in Section 2.4 ✨

MAP-Mapping-Rule  ::= < AVP Header: 644 >
                      { Rule-IPv4-Addr-Or-Prefix }
                      { Rule-IPv6-Prefix    }
                      { EA-Field-Length     }
                      { Port-Set-Identifier }
                     *[ AVP ]

Figure 8: MAP-Mapping-Rule AVP

The Rule-IPv4-Addr-Or-Prefix, Rule-IPv6-Prefix, EA-Field-Length, and Port-Set-Identifier AVPs MUST all be present 🫶

The Port-Set-Identifier AVP gives info to pin down the specific set of ports assigned to the CPE. For more, see Sections 2.4 and 2.3. The Port-Set-Identifier AVP itself is defined in Section 3.5 🦋

3.9.1. Rule-IPv4-Addr-Or-Prefix AVP

The Rule-IPv4-Addr-Or-Prefix AVP (AVP Code 645) carries the Rule IPv4 prefix and length as described in Section 2.4. It's type Grouped, as shown in Figure 9 💖

Rule-IPv4-Addr-Or-Prefix  ::= < AVP Header: 645 >
                              { IP-Address }
                              { IP-Prefix-Length }
                             *[ AVP ]

Figure 9: Rule-IPv4-Addr-Or-Prefix AVP

IP-Address (AVP code 518) is defined in [RFC5777] and is type Address. Inside the Rule-IPv4-Addr-Or-Prefix AVP, it gives the value of a unicast IPv4 address or prefix 🌸 The AddressType field in IP-Address MUST have value 1 (IPv4). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver 🧚

The IP-Prefix-Length AVP (AVP code 632) gives the actual length of the prefix in the IP-Address AVP. Inside the Rule-IPv4-Addr-Or-Prefix AVP, valid values of the IP-Prefix-Length AVP are from 0 to 32 (full address), based on the different cases in Section 5.2 of [RFC7597] 📚

3.9.2. Rule-IPv6-Prefix AVP

The Rule-IPv6-Prefix AVP (AVP Code 646) carries the Rule IPv6 prefix and length as described in Section 2.4. It's type Grouped, as shown in Figure 10 🌈

Rule-IPv6-Prefix  ::= < AVP Header: 646 >
                      { IP-Address }
                      { IP-Prefix-Length }
                     *[ AVP ]

Figure 10: Rule-IPv6-Prefix AVP

IP-Address (AVP code 518) is defined in [RFC5777] and is type Address. Inside the Rule-IPv6-Prefix AVP, it gives the value of a unicast IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver 🎀

The IP-Prefix-Length AVP (AVP code 632) gives the actual length of the prefix in the IP-Address AVP. Inside the Rule-IPv6-Prefix AVP, the minimum valid prefix length is 0. The maximum is capped by the length of the end-user IPv6 prefix tied to the mapping rule, if there's one in the form of the Delegated-IPv6-Prefix AVP in the enclosing MAP-E-Attributes AVP. Otherwise, the maximum value is 128 👑

3.9.3. EA-Field-Length AVP

The EA-Field-Length AVP (AVP Code 647) is type Unsigned32. Valid values range from 0 to 48 🍓 For how this parameter gets used to derive IPv4 address and port number config, see Section 5.2 of [RFC7597] 🦋

4. Attribute-Value Pair Flag Rules 🎀

okay bestie, this is the flag cheat sheet ✨ The table lists every AVP from this doc with its code, the section it's defined in, and its value type, plus the flag rules on the right. The V sits in the far-right flag column for every single AVP 💅

                                                             +---------+
                                                             |AVP flag |
                                                             |rules    |
                                                             +----+----+
                                  AVP   Section              |    |MUST|
      Attribute Name              Code  Defined  Value Type  |MUST| NOT|
     +-------------------------------------------------------+----+----+
     |IP-Prefix-Length            632    3.1     Unsigned32  |    | V  |
     +-------------------------------------------------------+----+----+
     |Border-Router-Name          633    3.2     OctetString |    | V  |
     +-------------------------------------------------------+----+----+
     |64-Multicast-Attributes     634    3.3     Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |ASM-mPrefix64               635    3.3.1   Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |SSM-mPrefix64               636    3.3.2   Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |Tunnel-Source-Pref-Or-Addr  637    3.4     Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |Tunnel-Source-IPv6-Address  638    3.4.2   Address     |    | V  |
     +-------------------------------------------------------+----+----+
     |Port-Set-Identifier         639    3.5     OctetString |    | V  |
     +-------------------------------------------------------+----+----+
     |Lw4o6-Binding               640    3.6     Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |Lw4o6-External-IPv4-Addr    641    3.6.1   Address     |    | V  |
     +-------------------------------------------------------+----+----+
     |MAP-E-Attributes            642    3.7     Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |MAP-Mesh-Mode               643    3.8     Enumerated  |    | V  |
     +-------------------------------------------------------+----+----+
     |MAP-Mapping-Rule            644    3.9     Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |Rule-IPv4-Addr-Or-Prefix    645    3.9.1   Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |Rule-IPv6-Prefix            646    3.9.2   Grouped     |    | V  |
     +-------------------------------------------------------+----+----+
     |EA-Field-Length             647    3.9.3   Unsigned32  |    | V  |
     +-------------------------------------------------------+----+----+

As the Diameter base protocol [RFC6733] explains, the application can define the M-bit usage for a given AVP in a given command 🧚

5. IANA Considerations 🦋

IANA registered these Diameter AVP codes in the "AVP Codes" registry, and every single one points back to this document 🌸

        +------+----------------------------+---------------+
        | Code | Attribute Name             | Reference     |
        +------+----------------------------+---------------+
        | 632  | IP-Prefix-Length           | This document |
        | 633  | Border-Router-Name         | This document |
        | 634  | 64-Multicast-Attributes    | This document |
        | 635  | ASM-mPrefix64              | This document |
        | 636  | SSM-mPrefix64              | This document |
        | 637  | Tunnel-Source-Pref-Or-Addr | This document |
        | 638  | Tunnel-Source-IPv6-Address | This document |
        | 639  | Port-Set-Identifier        | This document |
        | 640  | Lw4o6-Binding              | This document |
        | 641  | Lw4o6-External-IPv4-Addr   | This document |
        | 642  | MAP-E-Attributes           | This document |
        | 643  | MAP-Mesh-Mode              | This document |
        | 644  | MAP-Mapping-Rule           | This document |
        | 645  | Rule-IPv4-Addr-Or-Prefix   | This document |
        | 646  | Rule-IPv6-Prefix           | This document |
        | 647  | EA-Field-Length            | This document |
        +------+----------------------------+---------------+

Table 1: Diameter AVP Codes

6. Security Considerations 🔥

Okay this section is not playing around, so read it carefully 💀

6.1. Man-In-The-Middle (MITM) Attacks

The AVPs in this document face two threats, and both depend on man-in-the-middle (MITM) attacks on the Diameter delivery path 😭

The first threat is denial-of-service (DoS) through changing the AVP contents so things get misconfigured. For example, a subscriber may fail to reach its connectivity service if an invalid IP address was configured, or its traffic can get intercepted by a misbehaving node if a fake Border Node was configured. Yikes 🙈

The second threat is that Diameter security is currently provided hop by hop (see Section 2.2 of [RFC6733]). At the time of writing, the Diameter end-to-end security problem has not been solved, so MITM attacks by Diameter peers along the path are possible. Diameter-related security considerations are discussed in Section 13 of [RFC6733] 🔐

6.2. Privacy

These AVPs reveal privacy-related info, like subscriber addresses, which can be used for tracking purposes, so all of them are treated as security sensitive 👀 That means the considerations in Section 13.3 of [RFC6733] MUST be followed for Diameter messages that contain these AVPs 💜

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

Huawei Technologies funded Tom Taylor's work on earlier draft versions of this document 💖

Special thanks to Lionel Morand for the detailed review 🌈

Many thanks to Russ Housley, Tim Chown, Spencer Dawkins, and Ben Campbell for the review and comments ⭐

Authors' Addresses 💅

Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
China

Email: cathy.zhou@huawei.com


Tom Taylor
PT Taylor Consulting
Ottawa
Canada

Email: tom.taylor.stds@gmail.com


Qiong Sun
China Telecom
China

Phone: 86 10 58552936
Email: sunqiong@ctbri.com.cn


Mohamed Boucadair
France Telecom
Rennes  35000
France

Email: mohamed.boucadair@orange.com
📦 where this page comes from