Internet Engineering Task Force C. Zhou
Internet-Draft T. Taylor
Intended status: Standards Track Huawei Technologies
Expires: April 21, 2014 Q. Sun
China Telecom
M. Boucadair
France Telecom
October 18, 2013
Attribute-Value Pairs For Provisioning Customer Equipment Supporting
IPv4-Over-IPv6 Transitional Solutions
draft-zhou-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 or
are currently being defined for carrying IPv4 packets over IPv6.
Work is currently in progress to enumerate 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 extent that the provisioning is done
dynamically, AAA support is needed to provide the information to the
network server responsible for passing the information to the
customer equipment. This document specifies Diameter attribute-value
pairs to be used for that purpose.
Status of This Memo
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 April 21, 2014.
Copyright Notice
Zhou, et al. Expires April 21, 2014 [Page 1]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
Copyright (c) 2013 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Description of the Parameters Required By Each Transition
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Parameters For Dual-Stack Lite . . . . . . . . . . . . . 4
2.2. Public IPv4 Over IPv6 . . . . . . . . . . . . . . . . . . 4
2.3. Light Weight IPv4 Over IPv6 (LW4o6) . . . . . . . . . . . 5
2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 5
2.5. Summing Up . . . . . . . . . . . . . . . . . . . . . . . 6
3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 6
3.1. DS-Lite Attributes . . . . . . . . . . . . . . . . . . . 6
3.1.1. ASM-Prefix64 . . . . . . . . . . . . . . . . . . . . 7
3.1.2. SSM-Prefix64 . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Unicast-Prefix64 . . . . . . . . . . . . . . . . . . 8
3.2. Public Unshared IPv4 Address . . . . . . . . . . . . . . 8
3.3. Light-Weight 4over6 Attributes . . . . . . . . . . . . . 8
3.4. MAP-E Attributes . . . . . . . . . . . . . . . . . . . . 9
3.5. Mapping Rule . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1. EA Field Length . . . . . . . . . . . . . . . . . . . 10
3.5.2. PSID Offset . . . . . . . . . . . . . . . . . . . . . 11
3.6. Border Router IPv6 Address . . . . . . . . . . . . . . . 11
3.7. IPv4 Prefix or Address . . . . . . . . . . . . . . . . . 11
3.8. IPv6 Prefix or Address . . . . . . . . . . . . . . . . . 11
3.9. Port Set Identifier . . . . . . . . . . . . . . . . . . . 11
3.10. Mesh Or Hub And Spoke . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Zhou, et al. Expires April 21, 2014 [Page 2]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
1. Introduction
A number of transition technologies have been or are being defined to
allow IPv4 packets to pass between hosts and IPv4 networks over an
intervening IPv6 network while minimizing the number of public IPv4
addresses that need to be consumed by the hosts. Different operators
will deploy different technologies, and sometimes one operator will
use more than one technology, depending on what is supported by the
available equipment and upon other factors both technical and
economic.
Each technique requires the provisioning of some subscriber-specific
information on the customer edge device. The provisioning may be by
DHCP or by some other method. This document is indifferent to the
specific provisioning technique used, but assumes that the
information originates in the AAA infrastructure because in some
networks, the user configuration information may be managed by AAA
(Authentication, Authorization, and Accounting) servers. In a fixed
line broadband network, the Broadband Network Gateways (BNGs) act as
the access gateway of users. When the BR and BNG are co-located in
one device, the approach defined in [I-D.ietf-softwire-map-radius]
could be used to acquire the subscriber-specific information via
RADIUS. In some deployments when the location of the BR is higher
than BNG, the subscriber-specific information will be pushed from AAA
server to the BR actively via Diameter [RFC6733]. To allow the
information to be carried in Diameter , this document specifies a
number of attribute-value pairs (AVPs) for the purpose.
This document takes as its scope the set of transition methods
provided for by [I-D.ietf-softwire-unified-cpe]. That document
enumerates the information that must be provisioned in the customer
edge router to support Dual-Stack Lite [RFC6333], Public IPv4 Over
IPv6 [I-D.ietf-softwire-public-4over6], Light Weight IPv4 Over IPv6
(LW4o6) [I-D.ietf-softwire-lw4over6], and Mapping of Address and Port
with Encapsulation (MAP-E) [I-D.ietf-softwire-map].
Several documents provide related specifications for RADIUS
[RFC2865], for individual transition methods. Potentially there
could be a reconciliation between the contents of those documents and
the present one, but that has not been done in the present version of
this document.
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 RFC 2119 [RFC2119].
Zhou, et al. Expires April 21, 2014 [Page 3]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
2. Description of the Parameters Required By Each Transition Method
This section reviews the parameters that need to be provisioned for
each of the transition methods listed above. This enumeration
provides the justification for the AVPs defined in the next section.
Since most of the transition methods dealt with here are works in
progress, this section is subject to modification in future versions.
A means is required to indicate which transition method(s) a given
subscriber is allowed to use. [I-D.ietf-softwire-unified-cpe]
specifies how to infer the intended method from other DHCP parameters
received. The approach taken in this document is to specify grouped
AVPs specific to the individual transition methods. The operator can
control which transition method a given subscriber uses by ensuring
that AAA passes only the grouped AVP relevant to that method.
2.1. Parameters For Dual-Stack Lite
Dual-Stack Lite is documented in [RFC6333]. It requires the
following parameters to be provisioned at the B4 at the customer
premises. This enumeration does not include the normal provisioning
of an IPv6 prefix to the customer equipment. The section numbers
shown are where these requirements are indicated in [RFC6333].
o IPv6 address of the border router (AFTR) (sec. 5.4);
o IPv6 address of a DNS recursive server (sec. 5.5). This is
probably supplied already independently of transition technology,
so does not have to be covered here.
o optionally, 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 (sec.
5.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. Public IPv4 Over IPv6
Public IPv4 Over IPv6 is described in
[I-D.ietf-softwire-public-4over6]. Besides the usual IPv6 prefix or
address information, it requires two parameters to be provisioned to
the customer equipment:
o a public IPv4 address;
Zhou, et al. Expires April 21, 2014 [Page 4]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
o IPv6 address of the border router
It also requires per-subscriber provisioning on the border router:
o binding between the customer IPv4 address and the customer IPv6
prefix, for routing of incoming packets to the correct tunnel.
2.3. Light Weight IPv4 Over IPv6 (LW4o6)
Light Weight IPv4 Over IPv6 (LW4o6) is documented in
[I-D.ietf-softwire-lw4over6]. Its provisioning requirements are
exactly the same as those for Public 4over6 with one addition:
o both the customer equipment and the border router are provided
with a port set identifier identifying the set of ports to which
the subscriber's incoming and outgoing packets on the public side
are restricted. The port selection algorithm and port set
identifier as such are not discussed in the draft. For the
present version of this document, it is assumed that the algorithm
is known in advance and the port set identifier has the form of an
index ranging from zero to the number of subscribers sharing a
given address less 1. This is similar to the port set identifier
in MAP-E, described next.
2.4. Mapping of Address and Port with Encapsulation (MAP-E)
Mapping of Address and Port with Encapsulation (MAP-E) is described
in [I-D.ietf-softwire-map]. MAP-E requires the provisioning of the
following per-subscriber information at the customer edge device:
o whether the device is to operate in mesh or hub-and-spoke mode;
o the IPv6 address of one or more border routers;
o the specially constructed End-user IPv6 prefix for the customer
edge device. [I-D.ietf-softwire-map] suggests that this would be
supplied as part of normal IPv6 provisioning, so it can be ignored
as a requirement here.
o the Basic Mapping Rule for the customer edge device. This
includes the following parameters:
* the rule IPv6 prefix and length;
* the rule IPv4 prefix and length;
* the number of "Extended Address" (EA) bits included in the End-
user IPv6 prefix;
Zhou, et al. Expires April 21, 2014 [Page 5]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
* of those Extended Address bits, the number that precede the
port set identifier. The default value is 6.
o in mesh mode only, zero or more Forwarding Mapping Rules,
containing the same parameters as the Basic Mapping rule.
o optionally, the port set identifier if the EA bits do not carry
it.
The border router needs to be configured with the superset of the
Forwarding MAP Rules passed to the customer sites it serves. Since
this is not subscriber-specific, even though it introduces no new
requirements to this document, it is out of scope.
2.5. Summing Up
It appears that the following items are common to two or more methods
and the corresponding AVPs to carry them can be reused:
o the IPv6 address of the border router;
o an IPv4 prefix and length (could be a /32);
o a port set identifier.
The remaining requirements are method-specific:
o for Public 4over6 and LW4o6, a binding between a customer IPv6
prefix or address and an IPv4 address;
o for MAP-E, the indication of whether mesh mode or hub-and-spoke
mode is to be used;
o for MAP-E, a Grouped AVP expressing a MAP Rule.
3. Attribute-Value Pair Definitions
This section provides the specifications for the AVPs needed to meet
the requirements summarized in Section 2.5. Within the context of
their usage, all of these AVPs MUST have the M bit set and the V bit
cleared.
3.1. DS-Lite Attributes
The DS-Lite-Attributes AVP is of type Grouped. It contains the IPv6
address of the AFTR and optionally the multicast-related prefixes
needed for providing native IPv4 multicast over IPv6 using DS-Lite,
as specified in [I-D.softwire-dslite-multicast].
Zhou, et al. Expires April 21, 2014 [Page 6]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
DS-Lite-Attributes ::= < AVP Header: TBD01 >
{ Border-Router-IPv6-Address }
0*1[ ASM-Prefix64 ]
0*1[ SSM-Prefix64 ]
0*1[ Unicast-Prefix64 ]
*[ AVP ]
Figure 1
The Border-Router-IPv6-Address AVP is defined in Section 3.6. Within
the DS-Lite-Attributes AVP, it provides the IPv6 address of the AFTR.
This AVP MUST be present.
The remaining AVPs are defined in this section, and MAY be included
if the subscriber is to receive native IPv4 multicast service over
IPv6 using DS-Lite. If either ASM-Prefix64 or SSM-Prefix64 or both
are present, Unicast-Prefix64 MUST also be present.
3.1.1. ASM-Prefix64
The ASM-Prefix64 AVP (AVP Code TBD02) is derived from base type
OctetString. It is a discriminated union representing the
combination of the prefix length (number of bits) in the first octet,
followed by the prefix itself, most significant octet first, padded
with zeroes at the low-order end to an octet boundary. Valid values
of the prefix length are from 0 to 96, where 0 indicates that the
prefix is absent.
This AVP conveys the IPv6 multicast prefix to be used to synthesize
the IPv4-embedded IPv6 addresses of the multicast groups in the Any-
Source Multicast (ASM) mode. The conveyed multicast IPv6 prefix MUST
belong to the ASM range.
3.1.2. SSM-Prefix64
The SSM-Prefix64 AVP (AVP Code TBD03) is derived from base type
OctetString. It is a discriminated union representing the
combination of the prefix length (number of bits) in the first octet,
followed by the prefix itself, most significant octet first, padded
with zeroes at the low-order end to an octet boundary. Valid values
of the prefix length are 0 and 96, where 0 indicates that the prefix
is absent.
This AVP conveys the IPv6 multicast prefix to be used to synthesize
the IPv4-embedded IPv6 addresses of the multicast groups in the
Source-Specific Multicast [RFC4607] mode. The conveyed multicast
IPv6 prefix MUST belong to the SSM range. This prefix is likely to
be a /96.
Zhou, et al. Expires April 21, 2014 [Page 7]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
3.1.3. Unicast-Prefix64
The Unicast-Prefix64 AVP (AVP Code TBD04) is derived from base type
OctetString. It is a discriminated union representing the
combination of the prefix length (number of bits) in the first octet,
followed by the prefix itself, most significant octet first, padded
with zeroes at the low-order end to an octet boundary. Valid values
of the prefix length are 0, 32, 48, 56, 64 and 96, where 0 indicates
that the prefix is absent.
This AVP conveys 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.
Unicast-Prefix64 may also be used to extract the IPv4 address from
the received multicast data flows. The address mapping must follow
the guidelines documented in [RFC6052].
3.2. Public Unshared IPv4 Address
The Public-Unshared-IPv4-Address AVP (AVP Code TBD05) is of type
Address as defined in Section 4.3 of [RFC6733]. It provides an
unshared IPv4 address assigned to the customer edge device. It
applies to Public 4over6 (always) and to LW4o6 and MAP-E in the case
of 1-1 mapping. The recipient of this AVP can determine which of the
transition methods is applicable from the presence or absence of
LW4o6-specific or MAP-E-specific additional attributes. Since the
content is an IPv4 address, the AVP Length MUST be set to 14 and the
first two octets MUST contain 0x0001 (IPv4).
3.3. Light-Weight 4over6 Attributes
The Light-Weight-4over6-Attributes AVP (AVP Code TBD06) is of type
Grouped. It contains the IPv6 address of the Border Router,
optionally the IPv6 prefix assigned to the customer edge device, and
optionally the port set identifier assigned to the customer edge
device.
Light-Weight-4over6-Attributes ::= < AVP Header: TBD06 >
{ Border-Router-IPv6-Address }
0*1[ IPv6-Prefix-Or-Addr ]
0*1[ Port-Set-Identifier ]
*[ AVP ]
Figure 2
Zhou, et al. Expires April 21, 2014 [Page 8]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
The Border-Router-IPv6-Address AVP is defined in Section 3.6 and
provides the IPv6 address of the Border Router. This AVP MUST be
present.
The IPv6-Prefix-Or-Addr AVP is defined in Section 3.8. Within the
Light-Weight-4over6-Attributes AVP, it provides the IPv6 prefix
assigned to the customer edge device. If this AVP is absent, it is
assumed that the same information is conveyed to the recipient of the
Light-Weight-4over6-Attributes AVP by another AVP in the subscriber
profile.
The Port-Set-Identifier AVP is defined in Section 3.9. It identifies
the specific set of ports assigned to the customer edge device. This
AVP MUST be present except when 1-1 mapping mode is being
provisioned, when it MUST NOT be present. In this version of this
document it is assumed that the algorithm and parameters used to
derive individual port values from the port set identifier are
already known to the recipient.
3.4. MAP-E Attributes
The MAP-E-Attributes AVP (AVP Code TBD07) is of type Grouped. It
contains the addresses of one or more Border Routers in the same
MAP-E domain as the customer edge device, an indicator of whether
mesh mode or hub-and-spoke mode is used in the domain, optionally the
end-user IPv6 prefix assigned to the customer edge device, and one or
more mapping rules.
MAP-E-Attributes ::= < AVP Header: TBD07 >
1*{ Border-Router-IPv6-Address }
{ Mesh-Or-Hub-And-Spoke }
0*1[ IPv6-Prefix-Or-Addr ]
1*{ Mapping-Rule }
*[ AVP ]
Figure 3
The Border-Router-IPv6-Address AVP is defined in Section 3.6 and
provides the IPv6 address of the Border Router. At least one
instance of this AVP MUST be present.
The Mesh-Or-Hub-And-Spoke AVP is defined in Section 3.10. It
indicates whether the the MAP-E domain supports mesh mode or hub-and-
spoke mode. This AVP MUST be present.
The IPv6-Prefix-Or-Addr AVP is defined in Section 3.8. Within the
MAP-E-Attributes AVP, it provides the IPv6 prefix assigned to the
customer edge device. If this AVP is absent, it is assumed that the
Zhou, et al. Expires April 21, 2014 [Page 9]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
same information is conveyed to the recipient of the MAP-E-Attributes
AVP by another AVP in the subscriber profile.
The Mapping-Rule AVP is defined in Section 3.5. At least one
instance of this AVP MUST be present. If the MAP-E domain supports
mesh mode, additional Mapping-Rule instances MAY be present. If the
MAP-E domain is operating in hub-and-spoke mode, additional Mapping-
Rule instances MUST NOT be present.
3.5. Mapping Rule
The Mapping-Rule AVP (AVP Code TBD08) is of type Grouped, and is used
only in conjunction with MAP-based transition methods (MAP-E and
potentially 4rd and MAP-T). Mapping rules are required both by the
Border Router and by the customer edge device. The components of the
Mapping-Rule AVP are the rule IPv4 prefix or address, the rule IPv6
prefix, the length in bits of the Extended Address field in the End-
User IPv6 Prefix assigned to the customer edge device, and optionally
the offset in a port number beyond which the port set identifier
begins.
The syntax of the Mapping-Rule AVP is as follows:
Mapping-Rule ::= < AVP Header: TBD08 >
{ IPv4-Prefix-Or-Addr }
{ IPv6-Prefix-Or-Addr }
{ EA-Field-Length }
[ PSID-Offset ]
*[ AVP ]
Figure 4
The IPv4-Prefix-Or-Addr AVP and IPv6-Prefix-Or-Addr AVPs are defined
in sections Section 3.7 and Section 3.8 respectively. They MUST be
present within the Mapping-Rule AVP. The EA-Field-Length AVP and
PSID-Offset AVP are defined in this section.
3.5.1. EA Field Length
The EA-Field-Length AVP (AVP Code TBD09) is of type Unsigned32. The
valid range for EA-Field-Length extends from 0 to a maximum value
defined by [I-D.ietf-softwire-map]. If EA-Field-Length is 0, the
subscriber profile MUST also provide an instance of the Public-
Unshared-IPv4-Address AVP (AVP Code TBD05). The EA-Field-Length AVP
MUST be present within the Mapping-Rule AVP. AVP Length for the EA-
Field-Length AVP MUST be set to 12.
Zhou, et al. Expires April 21, 2014 [Page 10]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
3.5.2. PSID Offset
The PSID-Offset AVP (AVP Code TBD10) is of type Unsigned32. The
valid range for PSID-Offset extends from 0 to 15, with a default
value given by [I-D.ietf-softwire-map] if the parameter is absent.
AVP Length for the PSID-Offset AVP MUST be set to 12.
3.6. Border Router IPv6 Address
The Border-Router-IPv6-Address (AVP Code TBD11) is of type Address as
defined in Section 4.3 of [RFC6733] and contains the IPv6 address of
a border router supporting an IPv6 transition method which will be
used by the customer edge device on which this address is
provisioned. The address MAY be an anycast address. Since the
content is an IPv6 address, the AVP Length MUST be set to 26 and the
first two octets MUST contain 0x0002 (IPv6).
3.7. IPv4 Prefix or Address
The IPv4-Prefix-Or-Addr (AVP Code TBD12) is derived from base type
OctetString. It is a discriminated union representing the
combination of the prefix length (number of bits) in the first octet,
followed by the prefix itself, most significant octet first, padded
with zeroes at the low-order end to an octet boundary. Valid values
of the prefix length are from 0 to 32, where 0 indicates that the
prefix is absent and 32 indicates a complete address.
Correspondingly, the AVP Length can range from 9 to 14.
3.8. IPv6 Prefix or Address
The IPv6-Prefix-Or-Addr (AVP Code TBD13) is derived from base type
OctetString. It is a discriminated union representing the
combination of the prefix length (number of bits) in the first two
octets, followed by the prefix itself, most significant octet first,
padded with zeroes at the low-order end to an octet boundary. Valid
values of the prefix length are from 0 to 128, where 0 indicates that
the prefix is absent and 128 indicates a complete address.
Correspondingly, the AVP Length can range from 10 to 26.
3.9. Port Set Identifier
The Port-Set-Identifier AVP (AVP Code TBD14) is of type Unsigned32
and indicates a set of ports defined by an otherwise-specified
algorithm. For a given shared address, each Port-Set-Identifier
value MUST identify a separate set of ports. AVP Length for the
Port-Set-Identifier AVP MUST be set to 12.
Zhou, et al. Expires April 21, 2014 [Page 11]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
3.10. Mesh Or Hub And Spoke
The Mesh-Or-Hub-And-Spoke AVP (AVP Code TBD15) is of type Enumerated.
It indicates whether the MAP-E domain operates in mesh or hub-and-
spoke mode. The possible values are:
(1) mesh mode;
(2) hub-and-spoke mode.
4. Acknowledgements
TBD
5. IANA Considerations
This memo requests to IANA to register the following Diameter AVP
codes:
+-------+--------------------------------+---------------+
| Code | Attribute Name | Reference |
+-------+--------------------------------+---------------+
| TBD01 | DS-Lite-Attributes | This document |
| TBD02 | ASM-Prefix64 | This document |
| TBD03 | SSM-Prefix64 | This document |
| TBD04 | Unicast-Prefix64 | This document |
| TBD05 | Public-Unshared-IPv4-Address | This document |
| TBD06 | Light-Weight-4over6-Attributes | This document |
| TBD07 | MAP-E-Attributes | This document |
| TBD08 | Mapping-Rule | This document |
| TBD09 | EA-Field-Length | This document |
| TBD10 | PSID-Offset | This document |
| TBD11 | Border-Router-IPv6-Address | This document |
| TBD12 | IPv4-Prefix-Or-Addr | This document |
| TBD13 | IPv6-Prefix-Or-Addr | This document |
| TBD14 | Port-Set-Identifier | This document |
+-------+--------------------------------+---------------+
Table 1
6. Security Considerations
To come.
7. References
7.1. Normative References
Zhou, et al. Expires April 21, 2014 [Page 12]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
[I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture (work in progress)", July 2013.
[I-D.ietf-softwire-map-radius]
Jiang, Sheng., Fu, Yu., Liu, Bing., and Peter. Deacon,
"RADIUS Attribute for MAP (work in progress)", June 2013.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP) (work in progress)", August 2013.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4 over IPv6 Access Network (work in progress)", July
2013.
[I-D.ietf-softwire-unified-cpe]
Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6
Softwire CPE (work in progress)", May 2013.
[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)",
October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
Zhou, et al. Expires April 21, 2014 [Page 13]
Internet-Draft AVPs For 4over6 CPE Provisioning October 2013
[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.
Authors' Addresses
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: cathy.zhou@huawei.com
T. Taylor
Huawei Technologies
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Qiong Sun
China Telecom
P.R.China
Phone: 86 10 58552936
Email: sunqiong@ctbri.com.cn
M. Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Zhou, et al. Expires April 21, 2014 [Page 14]