DHCPv6 Options for Mapping of Address and Port

Mapping of Address and Port (MAP) defined in is a mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network, allowing for shared or dedicated IPv4 addressing. It consists of a set of one or more MAP Border Relay (BR) routers, responsible for stateless forwarding, and one or more MAP Customer Edge (CE) routers, that collectively form a MAP Domain when configured with common MAP rule-sets. In a residential broadband deployment the CE is sometimes referred to as a Residential Gateway (RG) or Customer Premises Equipment (CPE). A typical MAP CE will serve its end-user with one WAN side interface connected to an operator domain providing a MAP service. To function in the MAP domain, the CE requires to be provisioned with the appropiate MAP service paramaters for that domain. Particularly in larger networks it is not feasible to configure such parameters manually, which forms the requirement for a dynamic MAP provisioning mechanism that is defined in this document based on the existing DHCPv6 protocol. The configuration of the MAP BR is outside of scope of this document. This document specifies the DHCPv6 options that allow MAP CE provisioning, based on the definitions of parameters provided in , and is applicable to both MAP-E and MAP-T transport variants. The definition of DHCPv6 options for MAP CE provisioning does not preclude the definition of other dynamic methods for configuring MAP devices, or supplementing such configuration, nor is the use of DHCPv6 provisioning mandatory for MAP operation. Since specification of MAP architecture is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised MAP specification. Described proposal is not a dynamic port allocation mechanism. Readers interested in deployment considerations are encouraged to read .

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 .

The following presents the information parameters that are used to configure a MAP CE: A Default Mapping Rule (DMR). This rule governs the default forwarding/mapping behaviour of the MAP CE, ie it informs the CE of the BR router's address or prefix that is typically used as a default. The DMR is a mandatory parameter for a MAP CE. A Basic Mapping Rule (BMR). This rule governs the MAP configuration of the CE, including that of completing the CE's MAP IPv6 address, as well as deriving the CEs IPv4 parameters. Key parameters of a BMR include: i) The IPv4 Prefix - Used to derive the CE's IPv4 address; ii) The Embedded Address bit length - Used to derive how many, if any, of the CE's IPv6 address is mapped to the IPv4 address. iii) The IPv6 prefix - used to determine the CE's IPv6 MAP domain prefix that is to form the base for the CE's MAP address. The BMR is an optional rule for a MAP CE. A Forward Mapping Rule (FMR). This rule governs the MAP CE-CE forwarding behaviour for IPv4 destinations covered by the rule. The FMR is effectively a special type of an BMR, given that it shares exactly the same configuration parameters, except that these parameters are only applied for setting up forwarding. Its presence enables a given CE to communicate directly in "mesh mode" with other CEs. The FMR is an optional rule, and the absence of such a rule indicates that the CE is to simply use its default mapping rule for all destinations. Transport mode; encapsulation (MAP-E) or translation (MAP-T) modes to be used for the MAP CE Domain. Additional parameters. The MAP specification allows great flexibility in the level of automation a CE uses to derive its IPv4 address and port-sharing (PSID), ranging from full derivation of these parameters from the CE's IPv6 prefix, to full parametrization of MAP configuration independent of the CE's IPv6 prefix. Optional parameters such as the PSID allow this flexibility.

The DHCPv6 protocol is used for MAP CE provisioning following regular DHCPv6 notions, with the MAP CE assuming a DHCPv6 client role, and the MAP parameters provided by the DHCPv6 server following server side policies. The format and usage of the MAP options is defined in the following sections. Discussion: As the exact parameters required to configure MAP rules and MAP in general are expected to change, this section is expected to be updated and follow change in the . Discussion: It should be noted that initial concept of 4rd/MAP provisioning was presented in DHC working group meeting. It used one complex option to convey all required parameters. Strong suggestion from DHC WG was to use several simpler options. Options (possibly nested) are preferred over conditional option formatting. See DHCP option guidelines document ). Server that supports MAP configuration and is configured to provision requesting CE MUST include exactly one OPTION_MAP option in a REPLY message for each MAP domain. It is envisaged that in typical network, there will be only one MAP domain deployed.

This MAP Option specifies the container option used to group all rules for a specified MAP domain.

option-code: OPTION_MAP (TBD1) option-length: 1 + Length of the sub-options flags: This 8-bits long conveys the MAP Option Flags. The meaning of specific bits is explained in . sub-options: options associatied to this MAP option. The sub options field encapsulates those options that are specific to this MAP Option. For example, all of the MAP Rule Options are in the sub-options field. A DHCP message may contain multiple MAP Options. The Format of the MAP Option Flags field is:

Reserved: 7-bits reserved for future use. T: 1 bit field that specifies transport mode to use: translation (0) or encapsulation (1). It was suggested to also provision information whether MAP network is working in hub and spoke or mesh mode. That is not necessary, as mesh mode is assumed when there is at least one FMR present.

Figure X shows the format of the MAP Rule option used for conveying the BMR and FMR. Server includes one or more MAP Rule Options in MAP Flags option. Server MAY send more than one MAP Rule Option, if it is configured to do so. Clients MUST NOT send MAP Rule Option.

option-code: OPTION_MAP_RULE (TBD2) option-length: length of the option, excluding option-code and option-length fields, including length of all sub-options. prefix6-len: 8 bits long field expressing the bit mask length of the IPv6 prefix specified in the rule-ipv6-prefix field. ea-len: 8-bits long field that specifies the Embedded-Address (EA) bit length. Values allowed range from 0 to 48. prefix4-len: 8 bits long field expressing the bit mask length of the IPv4 prefix specified in the rule-ipv4-prefix field. rule-flags: 8 bit long field carrying flags applicable to the rule. The meaning of specific bits is explained in . rule-ipv4-prefix: a 32 bit fixed length field that specifies the IPv4 prefix for the MAP rule. rule-ipv6-prefix: a variable length field that specifies the IPv6 domain prefix for the MAP rule. The field is padded with zeros up to the nearest octet boundary when prefix6-len is not divisible by 8. rule sub-options: a variable field that may contain zero or more options that specify additional parameters for this MAP BMR/FMR rule. Currently there is only one option defined that may appear in rule sub-options field, eg the OPTION_MAP_PORTPARAMS, defined in section . The value of the EA-len and prefix4-len SHOULD be equal to or greater than 32. The Format of the MAP Rule Flags field is:

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). 0x0 = This rule is NOT used as an FMR. 0x1 = This rule is also an FMR. Note: BMR rules can be also FMR rules by setting the F flag. BMR rules are determined by a match of the Rule-IPv6-prefix against the CPE's prefix(es). It is expected that in a typical MAP deployment scenarios, there will be a single DMR and a single BMR, which could also be designated as an FMR using the F-Flag.

Figure X shows the format of the MAP Rule option used for conveying the DMR.

option-code: OPTION_MAP_DMR (TBD3) option-length: 1 + length of dmr-ipv6-prefix + sub-options in bytes dmr-prefix6-len: T8 bits long field expressing the bit mask length of the IPv6 prefix specified in the dmr-ipv6-prefix field. dmr-ipv6-prefix: a variable length field that specifies the IPv6 prefix or address for the MAP BR. This field is padded with zeros up to the nearest octet boundary when prefix4-len is not divisible by 8. sub options: options associatied to this MAP DMR option.

Port Parameters Option specifies optional Rule Port Parameters that MAY be provided as part of the Mapping Rule. It MAY appear as sub-option in OPTION_MAP_RULE option. It MUST NOT appear directly in a message. See , Section 5.1 for detailed description of Port mapping algorithm.

option-code: OPTION_MAP_PORTPARAMS (TBD4) option-length: 4 rsvd: This 4-bits long field is currently not used and MUST be set to 0 by server. Its value MUST be ignored by clients. offset: (PSID offset) 4 bits long field that specifies the numeric value for the MAP algorithm's excluded port range/offset bits (A-bits), as per section 5.1.1 in . Default must be set to 4. PSID-len: Bit length value of 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 valid of PSID. Subsequently, the address sharing ratio would be 2 ^k. PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value algorithmically identifies a set of ports assigned to a CE. The first k-bits on the left of this 2-octets field is the PSID value. The remaining (16-k) bits on the right are padding zeros. When receiveing the Port Parameters option with an explicit PSID, the client MUST use this explicit PSID in configuring its MAP interface.

DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) will convey the following MAP options in its messages:

RFC 3315 Section 17.2.2 describes how a DHCPv6 client and server negotiate configuration values using the ORO. As a convenience to the reader, we mention here that a server will by default not reply with a MAP Rule Option if the client has not explicitly enumerated it on its Option Request Option. A Server following this specification MUST allow the configuration of one or more MAP Rule Options, and SHOULD send such options grouped under a single MAP_OPTION. Server MUST transmit all configured instances of the Mapping Rule Options with all sub-options, if client requested it using OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST transmit MAP Flags Option if client requested OPTION_MAP in its ORO. The server MUST be capable of following per client assignment rules when assigning MAP options.

A MAP CE acting as DHCPv6 client will request MAP configuration to be assigned by the DHCPv6 server located in the ISP network. A client supporting MAP functionality SHOULD request OPTION_MAP, OPTION_MAP_RULE and OPTION_MAP_DMR options in its ORO in SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages. When processing received MAP options the following behaviour is expected: A client MUST support processing multiple received OPTION_MAP_RULE options in a OPTION_MAP option A client receiving an unsupported MAP option, or an unrecognized parameter value SHOULD discard the entire OPTION_MAP. Only one OPTION_MAP_DMR is allowed per OPTION_MAP option. The client MUST be capable of applying the received MAP option parameters for the configuration of the local MAP instance. Note that system implementing MAP CE functionality may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for MAP, and some may be connected to networks that are using normal dual stack or other means. The MAP CE system should approach this specification on an interface-by-interface basis. For example, if the CE system is attached to multiple networks that provide the MAP Mapping Rule Option, then the CE system MUST configure a MAP connection (i.e. a translation or encapsulation) for each interface separately as each MAP provides IPv4 connectivity for each distinct interface. Means to bind a MAP configuration to a given interface in a multiple interfaces device are out of scope of this document.

The defined MAP options contain a number of flags and parameters that are intended to provide full flexibility in the configuration of a MAP CE. Some usage examples are: A MAP CE receiving an OPTION_MAP option with the T flag set to 1 will assume a MAP-E (encapsulation) mode of operation for the domain and all associated rules. Conversely, when the received option has the T flag set to 0, the CE will assume a MAP-T (stateless NAT46 translation) mode of operation. The presence of a OPTION_MAP_RULE option, along with IPv4 prefix parameters, indicates to the MAP CE that NAPT44 mode of operation is expected, following the address mapping rules defined in . Conversely, the absence of an OPTION_MAP_RULE option indicates that NAT44 mode is not required, and that the MAP CE is to plainly encapsulate (MAP-E mode) or statelessly translate using NAT64 (MAP-T mode) any IPv4 traffic sent following the DMR. The MAP domain ipv6-prefix in the BMR should correspond to a service prefix assigned to the CPE by the operator, with the latter being assigned using regular IPv6 means, eg DHCP PD or SLAAC. This parameter allows the CPE to select the prefix for MAP operation. The EA_LEN parameter, along with the length of the IPv4 prefix in the BMR option, allows the MAP CE to determine whether address sharing is in effect, and what is the address sharing ratio. Eg: A prefix4-len of 16 bits, and EA-len of 18 combines to a 32 bit IPv4 address with a sharing ratio of 4. The use of the F(orward) flag in the BMR allows a CE to apply a received BMR as an FMR, thereby enabling mesh-mode for the domain covered by the BMR rule. In the absence of a BMR, the presence of the mandatory DMR indicates to the CPE the address or prefix of a BR, and makes the MAP CE fully compatible with DS-Lite and stateful or stateless NAT64 core nodes. Eg a MAP CE configured in MAP-E mode, with just a DMR and a BR IPv6 address equivalent to that of the AFTR, effectively acts as a DS-Lite B4 element. For more discussion about MAP deployment considerations, see .

Usage of PSID Option should be avoided if possible and PSID embedded in the delegated prefix should be used instead. This allows MAP deployment to not introduce any additional state in DHCP server. PSID Option must be assigned on a per CE basis, thus requiring more complicated server configuration. In a typical environment, there will be only one MAP domain, so server will provide only a single instance of MAP option that acts a container for MAP Rule Options and other options that are specific to that MAP domain. In case of multiple provisioning domains, as defined in , one server may be required to provide information about more than one MAP domain. In such case, server will provide two or more instances of MAP Options, each with its own set of sub-option that define MAP rules for each specific MAP domain. Details of mulitple provisioning domains are discussed in Section 4.1 of .

IANA is kindly requested to allocate DHCPv6 option codes for TBD1 for OPTION_MAP, TBD2 for OPTION_MAP_RULE, TBD3 for OPTION_MAP_DMR, and TBD4 for OPTION_MAP_Port. All values should be added to the DHCPv6 option code space defined in Section 24.3 of .

Implementation of this document does not present any new security issues, but as with all DHCPv6-derived configuration state, it is completely possible that the configuration is being delivered by a third party (Man In The Middle). As such, there is no basis to trust that the access over the MAP can be trusted, and it should not therefore bypass any security mechanisms such as IP firewalls. Readers concerned with security of MAP provisioning over DHCPv6 are encouraged to familiarize with . Section XX of discusses security issues of the MAP mechanism. Section 23 of discusses DHCPv6-related security issues.

This document was created as a product of a MAP design team. Following people were members of that team: Congxiao Bao, Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, Leaf Yeh and Jan Zorz. Former MAP design team members are: Remi Despres.