| Softwire WG | T. Mrugalski, Ed. |
| Internet-Draft | ISC |
| Intended status: Standards Track | M. Boucadair |
| Expires: July 25, 2012 | X. Deng |
| France Telecom | |
| O. Troan | |
| Cisco | |
| C.X. Bao | |
| Tsinghua University | |
| January 24, 2012 |
DHCPv6 Options for Mapping of Address and Port
draft-mdt-softwire-map-dhcp-option-02
Generic mechanism for mapping between an IPv4 prefix, address or parts of thereof, and transport layer ports and an IPv6 prefix or address is specified in [I-D.mdt-softwire-mapping-address-and-port]. This is a companion document that specifies provisioning mechanism of MAP rules. It defines DHCPv6 options which are meant to be used between Customer Edge (CE) devices and DHCPv6 server to obtain necessary parameters to configure MAP rules. Since specification of MAP architecture is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised MAP specification.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.
Mapping of Address and Port (MAP) defined in [I-D.mdt-softwire-mapping-address-and-port] is a mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network. It defines both MAP Border Relay (BR) router that is located at the edge of a MAP domain and MAP Customer Edge (CE) that typically deployed at customers' location. In a residential broadband deployment, CE is sometimes referred to as a Residential Gateway (RG) or Customer Premises Equipment (CPE). A MAP CE may also be referred to simply as a "CE" within the context of MAP.
A typical CE adopting MAP rules will serve a residential site with one WAN side interface and one or more LAN side interfaces. To operate properly, it requires one or more MAP rules and additional informations. In larger networks it is infeasible to configure such parameters manually. Therefore provisioning mechanism is required. Such mechanism is defined in this document. It leverages existing DHCPv6 [RFC3315] protocol to deliver necessary parameters to CE.
This document defines several DHCPv6 options that allow delivery of required information to configure CE. Configuration of the BR is outside of scope of this document. Definitions of used parameters are provided in [I-D.mdt-softwire-mapping-address-and-port].
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.
Reader interested in deployment considerations is encouraged to read [map-d].
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].
A typical MAP CE usually acts as a DHCPv6 client and requests options that are being provided by a DHCPv6 server located somewhere in ISP network. This server provides typical information to configured nodes: namely IPv6 address (in IA_NA option) and delegates a prefix (in IA_PD option). Server also provides additional parameters that are MAP specific. In particular, it provides the following information:
DHCPv6 protocol is used for CE provisioning. Several new options are defined for conveying MAP-specific parameters. Their format and usage 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 or even rewritten completely.
Discussion: Proposed layout assumes that several simple options are used. Such approach simplifies implementation as it is much easier for implementors to reuse existing code handling such options. This design choice comes at a cost, however. Clients must perform checks if provided set of options is complete. Alternatively, it would be possible to define one complex option that contains all mandatory parameters.
Discussion: It should be noted that initial concept of 4rd 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 [I-D.ietf-dhc-option-guidelines]).
MAP rule is defined in [I-D.mdt-softwire-mapping-address-and-port], Section 4.
Discussion: If you want additional parameter added to the OPTION_MAP_RULE option (or any other option), please update [I-D.mdt-softwire-mapping-address-and-port] first.
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.
OPTION_MAP option MUST include one or more OPTION_MAP_RULE options.
This option specifies MAP flags and is used to group all rules for specified MAP domain. Currently the only defined flag is T that describes transport mode. Other flags that affect all mapping rules or the whole MAP domain may be specified here at a later date.
Each OPTION_MAP option MUST contain one or more MAP Rule Options.
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_MAP | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |T| .
+-+-+-+-+-+-+-+-+ .
. sub-options (variable length) .
+---------------------------------------------------------------+
It was suggested to also provision information whether MAP network is working in hub and spoke or full mesh mode. That is not necessary, as this information can be derived from provisioned MAP rules. In the hub and spoke mode, all traffic should be forwarded using DMR. Hub and spoke mode is achieved with a BMR IPv4 rule prefix length of 32 and no further FMR.
MAP Rule Option option represents a single MAP Rule. Depending on deployment mode, each CE may require one or more MAP Rules to operate properly.
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.
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_MAP_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix4-len | ea-len | prefix6-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | rule-ipv6-prefix | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . rule sub-options (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Explicit parameters are:
There are also number of implicit parameters that may be derived from content of MAP and other options. In particular, End-User IPv6 Prefix (or Delegated prefix, specified in IA_PD option, see [RFC3633]) and assigned IPv6 address (specified in IA_NA option, see [RFC3315]) are needed. Even though these values are not provided explicitely, they are required for proper MAP rule configuration. Following implicit parameters may be calculated:
It is expected that in a typical simple scenarios, there will be a single BMR with a single DMR (that will also work as FMR). For detailed discussion about MAP deployment considerations, see [map-d].
Note that the DMR is a simplified version of BMR. While it reuses the same DHCPv6 option format, DMR uses only Rule IPv6 prefix, Rule IPv6 Prefix Length and IPv4 address that denotes BR IPv4 address. All other parameters are ignored for Default Mapping Rule. Client MUST ignore those parameters for DMR and server MUST set those parameters to zero.
Port Parameters Option specifies optional Rule Port Paramters 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 [I-D.mdt-softwire-mapping-address-and-port], Section 4.1 for detailed description of Port mapping algorithm.
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_MAP_PORTPARAMS | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | excluded-ports | rsv | off | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TODO: Ole pointed out that excluded-ports are related to the offset. with a = 6, j > 0 you exclude 0-1023; with a = 4, j > 0 you exclude 0-4095; with a = 0, no ports excluded and number of systems ports per user given by PSID/PSID length the flag would allow j = 0.
Map Port Parameters Option is optional. If it is not present, the following default values are assumed:
If administrator wants to provision only one of those parameters, remaining fields SHOULD be set to their default value.
DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) will convey the following MAP options in its messages:
TODO: Reflect example in section 4.2 of MAP draft
TODO: Reflect example in section 4.3 of MAP draft
TODO: Reflect example in section 4.4 of MAP draft
RFC 3315 Section 17.2.2 [RFC3315] 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 not reply with a MAP Rule Option if the client has not explicitly enumerated it on its Option Request Option.
Server conformant to this specification MUST allow configuration of one or more MAP Rule Options.
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.
Rules assignment is a stateless process from the server's perspective. Server does not need to maintain a state of rules provisioned to clients, track lifetimes, expire outdated rules etc. Server SHOULDs assign the same set of rules to all CEs in one MAP Domain, unless there are several classes of CEs defined, e.g. regular and premium users. In such case, each class of CEs is expected to get the same set of rules. Server is not expected to track MAP rules on a per CE basis. Exact assignment of specific rules to a specific CEs is outside of scope of this document.
Although other use cases are allowed, in a typical use case CE will act as DHCPv6 client and will request MAP configuration to be assigned by the DHCPv6 server located in the ISP network. A client that supports MAP CE functionality and conforms to this specfication MUST include OPTION_MAP_RULE and OPTION_MAP in its ORO.
For proper operation, MAP CE client MUST also request IPv6 address (OPTION_IA_NA, defined in [RFC3315]) and prefix delegation (OPTION_IA_PD, defined in [RFC3633]). MAP CE client SHOULD NOT initiate DHCPv4 configuration for the purpose of MAP configuration as all parameters are delivered over DHCPv6.
Client supporting MAP functionality SHOULD request OPTION_MAP_RULE and OPTION_MAP options in SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.
If client receives more than one OPTION_MAP_RULE option, it MUST use all received instances. It MUST NOT use only the first one, while discarding remaining ones.
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.
IANA is kindly requested to allocate DHCPv6 option code TBD1 to the OPTION_MAP,TBD2 to OPTION_MAP_RULE and TBD3 to OPTION_MAP_PORTPARAMS. All three values should be added to the DHCPv6 option code space defined in Section 24.3 of [RFC3315].
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 [I-D.ietf-dhc-secure-dhcpv6].
Section XX of [I-D.mdt-softwire-mapping-address-and-port] discusses security issues of the MAP mechanism.
Section 23 of [RFC3315] discusses DHCPv6-related security issues.
Section 6 of [I-D.murakami-softwire-4rd] discusses 4rd related security issues that are partially applicable to MAP mechanism.
The current members of the MAP design team are: 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.
Authors would like to thank Jacni Qin, Qiong Sun and Remi Despres for their comments and suggestions.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.mdt-softwire-mapping-address-and-port] | Troan, O, "Mapping of Address and Port (MAP)", Internet-Draft draft-mdt-softwire-mapping-address-and-port-01, October 2011. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. |
| [map-d] | Chen, M, Sun, Q and G Chen, "Mapping of Address and Port (MAP) - Deployment Considerations", draft-mdt-softwire-map-deployment 00, 12 2012. |
| [I-D.ietf-dhc-option-guidelines] | Hankins, D, "Guidelines for Creating New DHCP Options", Internet-Draft draft-ietf-dhc-option-guidelines-07, October 2011. |
| [I-D.mrugalski-dhc-dhcpv6-4rd] | Mrugalski, T, "DHCPv6 Options for IPv4 Residual Deployment (4rd)", Internet-Draft draft-mrugalski-dhc-dhcpv6-4rd-00, July 2011. |
| [I-D.boucadair-dhcpv6-shared-address-option] | Boucadair, M, Levis, P, Grimault, J, Savolainen, T and G Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Internet-Draft draft-boucadair-dhcpv6-shared-address-option-01, December 2009. |
| [I-D.ietf-dhc-secure-dhcpv6] | Jiang, S and S Shen, "Secure DHCPv6 Using CGAs", Internet-Draft draft-ietf-dhc-secure-dhcpv6-03, June 2011. |
| [I-D.murakami-softwire-4rd] | Murakami, T, Troan, O and S Matsushima, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", Internet-Draft draft-murakami-softwire-4rd-01, September 2011. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |