--- 1/draft-ietf-dime-4over6-provisioning-01.txt 2015-06-02 05:15:01.030923472 -0700 +++ 2/draft-ietf-dime-4over6-provisioning-02.txt 2015-06-02 05:15:01.070924447 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force C. Zhou Internet-Draft Huawei Technologies Intended status: Standards Track T. Taylor -Expires: October 23, 2015 PT Taylor Consulting +Expires: December 4, 2015 PT Taylor Consulting Q. Sun China Telecom M. Boucadair France Telecom - April 21, 2015 + June 2, 2015 Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions - draft-ietf-dime-4over6-provisioning-01 + draft-ietf-dime-4over6-provisioning-02 Abstract During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the @@ -36,21 +36,21 @@ 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 October 23, 2015. + This Internet-Draft will expire on December 4, 2015. Copyright Notice Copyright (c) 2015 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 @@ -59,29 +59,29 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Description of the Parameters Required By Each Transition Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Parameters For Dual-Stack Lite (DS-Lite) . . . . . . . . 4 - 2.2. Light Weight IPv4 Over IPv6 (LW4over6) . . . . . . . . . 5 + 2.1. Parameters For Dual-Stack Lite (DS-Lite) . . . . . . . . 5 + 2.2. Lightweight IPv4 Over IPv6 (LW4over6) . . . . . . . . . . 5 2.3. Port Set Specification . . . . . . . . . . . . . . . . . 5 2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 6 2.5. Parameters For Multicast . . . . . . . . . . . . . . . . 7 - 2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 7 + 2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 8 3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 8 3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 8 - 3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 8 + 3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 9 3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 9 3.3.1. ASM-Prefix64 AVP . . . . . . . . . . . . . . . . . . 9 3.3.2. SSM-Prefix64 AVP . . . . . . . . . . . . . . . . . . 10 3.3.3. Delegated-IPv6-Prefix AVP As uPrefix64 . . . . . . . 10 3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 10 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix . . 11 3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 11 3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 11 3.6. LW4over6-Binding . . . . . . . . . . . . . . . . . . . . 12 3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 12 @@ -111,51 +111,54 @@ Each technique requires the provisioning of some subscriber-specific information on the customer edge device. The provisioning may be by DHCPv6 [RFC3315] or by some other method. This document is indifferent to the specific provisioning technique used, but assumes a deployment in which that information is managed by AAA (Authentication, Authorization, and Accounting) servers. It further assumes that this information is delivered to intermediate network nodes for onward provisioning using the Diameter protocol [RFC6733]. - As described below, in the particular case where the Light Weight - IPv4 Over IPv6 (LW4o6) [I-D.ietf-softwire-lw4over6] transition method - has been deployed, per-subscriber-site information almost identical - to that passed to the subscriber site [I-D.ietf-softwire-map-dhcp] or - collected from it [I-D.fsc-softwire-dhcp4o6-saddr-opt] also needs to - be delivered to the border router serving that site. The Diameter - protocol may be used for this purpose too. + As described below, in the particular case where the Lightweight IPv4 + Over IPv6 (Lw4o6) [I-D.ietf-softwire-lw4over6] transition method has + been deployed, per-subscriber-site information almost identical to + that passed to the subscriber site [I-D.ietf-softwire-map-dhcp] also + needs to be delivered to the border router serving that site. The + Diameter protocol may be used for this purpose too. This document analyzes the information required to configure the customer edge equipment for the following set of transition methods: o Dual-Stack Lite (DS-Lite) [RFC6333], - o Light Weight IPv4 Over IPv6 (LW4over6) + o Lightweight IPv4 Over IPv6 (LW4over6) [I-D.ietf-softwire-lw4over6], and o Mapping of Address and Port with Encapsulation (MAP-E) [I-D.ietf-softwire-map]. - [I-D.softwire-dslite-multicast] specifies a generic solution for + [I-D.ietf-softwire-dslite-multicast] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind but it is however not limited to DS-Lite. As such, it applies also for LW4over6 and MAP-E. This document analyzes the information required to configure the customer edge equipment for the support of multicast in the context of DS-Lite, MAP, and LW4over6 in particular. On the basis of those analyses it specifies a number of attribute- value pairs (AVPs) to allow the necessary subscriber-site-specific configuration information to be carried in Diameter. + This document doesn't specify any new commands or Application-Ids and + that the AVPs could be used for any Diameter application 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 document are to be interpreted as described in [RFC2119]. The abbreviation "CE" denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. This will usually be a router, but could be a host directly connected to the network. @@ -189,21 +192,21 @@ the IPv6 address of the AFTR (border router). Optionally, it could also be configured with the IPv4 address of the B4 interface facing the tunnel, where the default value in the absence of provisioning is 192.0.0.2 and valid values are 192.0.0.2 through 192.0.0.7. Provisioning this information through AAA is problematic because it is most likely used in a case where multiple B4 instances occupy the same device. This document therefore assumes that the B4 interface address is determined by other means (implementation-dependent or static assignment). -2.2. Light Weight IPv4 Over IPv6 (LW4over6) +2.2. Lightweight IPv4 Over IPv6 (LW4over6) Light Weight IPv4 Over IPv6 (LW4over6) is documented in [I-D.ietf-softwire-lw4over6]. LW4over6 requires four items to be provisioned to the customer equipment: o IPv6 address of the border router. o IPv6 prefix used by the CE to construct the tunnel source address. In the terminology of [I-D.ietf-softwire-lw4over6], this is the IPv6 Binding Prefix. @@ -217,32 +220,25 @@ value of the offset parameter 'a' is 0. As discussed in Section 4 of [I-D.ietf-softwire-lw4over6], it is necessary to synchronize this configuration with corresponding per- subscriber configuration at the border router. The border router information consists of the same public IPv4 address and port set parameters that are passed to the CE, bound together with the full /128 IPv6 address (not just the Binding Prefix) configured as the tunnel source address at the CE. - [I-D.fsc-softwire-dhcp4o6-saddr-opt] proposes a means whereby a - DHCPv6 server can influence the choice of this address and collect it - from the CE. Depending on the provisioning architecture deployed in - a given network, it is possible that the tunnel source address is - passed to AAA as an intermediate step before the binding information - is passed on to the border router. - 2.3. Port Set Specification When an external IPv4 address is shared, LW4over6 and MAP-E restrict the CE to use of a subset of all available ports on the external - side. Both transition methods use the the algorithm defined in + side. Both transition methods use the algorithm defined in Appendix B of [I-D.ietf-softwire-map] to derive the values of the port numbers in the port set. This algorithm features three parameters, describing the positioning and value of the Port Set Identifier (PSID) within each port number of the generated set: o an offset 'a' from the beginning of the port number to the first bit of the PSID; o the length 'k' of the PSID within the port number, in bits; and @@ -297,35 +293,42 @@ The border router needs to be configured with the superset of the Mapping Rules passed to the customer sites it serves. Since this requirement does not require direct coordination with CE configuration in the way LW4over6 does, it is out of scope of the present 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 - [I-D.softwire-dslite-multicast] specifies a generic solution for + [I-D.ietf-softwire-dslite-multicast] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution can be in particular deployed in a - DS-Lite context, but is also adaptable to LW4over6 and MAP-E. - [I-D.ietf-softwire-multicast-prefix-option] specifies how DHCPv6 - [RFC3315] can be used to provision multicast-related information, - particularly: + DS-Lite context, but is also adaptable to LW4over6 and MAP-E. For + example, [I-D.ietf-softwire-multicast-prefix-option] specifies how + DHCPv6 [RFC3315] can be used to provision multicast-related + information. The following lists the multicast-related information + that needs to be provisioned: o ASM_mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the - ASM mode. + Any-Source Multicast (ASM) mode. This is achieved by + concatenating the ASM_mPrefix64 and a IPv4 multicast address; the + Pv4 multicast address is inserted in the last 32 bits of the + IPv4-embedded IPv6 multicast address. o SSM_mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the - SSM mode. + Source-Specific Multicast (SSM, [RFC4607]) mode. This is achieved + by concatenating the SSM_mPrefix64 and a IPv4 multicast address; + the Pv4 multicast address is inserted in the last 32 bits of the + IPv4-embedded IPv6 multicast address. o uPrefix64: the IPv6 unicast prefix to be used in SSM mode for constructing 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 documented in [RFC6052]. 2.6. Summary and Discussion @@ -376,42 +380,41 @@ document identifies a border router using an FQDN rather than an address. The Border-Router-Name AVP (AVP Code TBD01) is of type OctetString. The rules for encoding the FQDN are the same as those for the FQDN variant of the derived type DiameterIdentity (Section 4.3.1 of [RFC6733]). 3.3. 64-Multicast-Attributes AVP The 64-Multicast-Attributes AVP (AVP Code TBD02) is of type Grouped. It contains the multicast-related prefixes needed for providing IPv4 - multicast over IPv6 using DS-Lite, MAP-E, or LW4over6, as specified - in [I-D.softwire-dslite-multicast]. + multicast over IPv6 using DS-Lite, MAP-E, or LW4over6, as mentioned + in Section 2.5. The syntax is shown in Figure 1. 64-Multicast-Attributes ::= < AVP Header: TBD02 > [ ASM-Prefix64 ] [ SSM-Prefix64 ] [ Delegated-IPv6-Prefix ] *[ AVP ] Figure 1: 64-Multicast-Attributes AVP If either ASM-Prefix64 or SSM-Prefix64 or both are present, Delegated-IPv6-Prefix MUST also be present. 3.3.1. ASM-Prefix64 AVP The ASM-Prefix64 AVP (AVP Code TBD03) conveys the value of - ASM_mPrefix64 as identified in Section 2.1 and specified in - [I-D.softwire-dslite-multicast]. The ASM-Prefix64 AVP is of type - Grouped, as shown in Figure 2. + ASM_mPrefix64 as mentioned in Section 2.5. The ASM-Prefix64 AVP is + of type Grouped, as shown in Figure 2. ASM-Prefix64 ::= < AVP Header: TBD03 > { IP-Address } { IP-Prefix-Length } *[ AVP ] Figure 2: ASM-Prefix64 AVP IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the ASM-Prefix64 AVP, it provides the value of an @@ -420,23 +423,22 @@ 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 provides the actual length of the prefix contained in the IP-Address AVP. Within the ASM-Prefix64 AVP, valid values of the IP-Prefix-Length AVP are from 24 to 96. 3.3.2. SSM-Prefix64 AVP The SSM-Prefix64 AVP (AVP Code TBD04) conveys the value of - SSM_mPrefix64 as identified in Section 2.1 and specified in - [I-D.softwire-dslite-multicast]. The SSM-Prefix64 AVP is of type - Grouped, as shown in Figure 3. + SSM_mPrefix64 as mentioned in Section 2.5. The SSM-Prefix64 AVP is + of type Grouped, as shown in Figure 3. SSM-Prefix64 ::= < AVP Header: TBD04 > { IP-Address } { IP-Prefix-Length } *[ AVP ] Figure 3: SSM-Prefix64 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 @@ -450,22 +452,21 @@ address in the FF3x range be set to zero, meaning that the prefix length for an SSM prefix is effectively 96. However, Section 1 of [RFC4607] suggests that the lower limit of 32 bits be preserved to allow potential future use of bits 33-95. Hence applications SHOULD accept prefix lengths between 32 and 96 inclusive. 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 identified in Section 2.1 and specified in - [I-D.softwire-dslite-multicast]. The Delegated-IPv6-Prefix AVP is + 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 The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD05) conveys either the IPv6 Binding Prefix or the tunnel source address on the CE, as described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP is of type Grouped, with syntax as shown in Figure 4. One of the Delegated-IPv6-Prefix AVP or the Tunnel-Source-IPv6-Address AVP MUST @@ -490,24 +491,21 @@ and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr AVP, it conveys the IPv6 Binding Prefix assigned to the CE. Valid values in the Prefix-Length field are from 0 to 128 (full address), although a more restricted range is obviously more reasonable. 3.4.2. Tunnel-Source-IPv6-Address AVP The Tunnel-Source-IPv6-Address AVP (AVP code TBD06) is of type Address. It provides the address that the CE has assigned to its end of an LW4over6 tunnel. The AddressType field in this AVP MUST be set - to 2 (IPv6). The DHCP 4o6 server described in - [I-D.fsc-softwire-dhcp4o6-saddr-opt] can use the Tunnel-Source- - IPv6-Address AVP to report the address to AAA after Step 3 of the - binding flow shown in Section 4 of that document. + to 2 (IPv6). 3.5. Port-Set-Identifier The Port-Set-Identifier AVP (AVP Code TBD07) is a structured OctetString with four octets of data, hence a total AVP length of 12. The description of the structure which follows refers to refers to the parameters described in Section 2.3. o The first (high-order) octet is the Offset field. It is interpreted as an 8-bit unsigned integer giving the offset 'a' @@ -772,42 +770,38 @@ [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 7.2. Informative References - [I-D.fsc-softwire-dhcp4o6-saddr-opt] - Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6 - Source Address Option (Work in progress)", June 2014. + [I-D.ietf-softwire-dslite-multicast] + Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. + Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients + over an IPv6 Multicast Network", draft-ietf-softwire- + dslite-multicast-09 (work in progress), March 2015. [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Farrer, I., Perrault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients (Work in progress)", March 2014. [I-D.ietf-softwire-multicast-prefix-option] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", draft-ietf-softwire-multicast-prefix-option-08 (work in progress), March 2015. - [I-D.softwire-dslite-multicast] - Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. - Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients - over an IPv6 Multicast Network (work in progress)", March - 2014. - [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. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.