One document matched: draft-zhou-dime-4over6-provisioning-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC4607 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-dime-4over6-provisioning-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="AVPs For 4over6 CPE Provisioning">Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions</title>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<phone>86 10 58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<phone></phone>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date year="2013" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>DS-Lite</keyword>
<keyword>Public IPv4 Over IPv6</keyword>
<keyword>Light-Weight 4over6</keyword>
<keyword>MAP-E</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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. </t>
<t>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 <xref
target="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 <xref
target="RFC6733"/>. To allow the information to be carried in Diameter ,
this document specifies a number of attribute-value pairs (AVPs) for the
purpose. </t>
<t>This document takes as its scope the set of transition methods
provided for by <xref target="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 <xref target="RFC6333"/>,
Public IPv4 Over IPv6
<xref target="I-D.ietf-softwire-public-4over6"/>,
Light Weight IPv4 Over IPv6 (LW4o6)
<xref target="I-D.ietf-softwire-lw4over6"/>,
and Mapping of Address and Port with Encapsulation (MAP-E)
<xref target="I-D.ietf-softwire-map"/>.</t>
<t>Several documents provide related specifications for RADIUS <xref
target="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.</t>
<section title="Requirements Language">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="reqts" title="Description of the Parameters Required By Each Transition Method">
<t>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.</t>
<t>A means is required to indicate which transition method(s) a given
subscriber is allowed to use.
<xref target="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.</t>
<section anchor="dslite" title="Parameters For Dual-Stack Lite">
<t>Dual-Stack Lite is documented in <xref target="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
<xref target="RFC6333"/>.
<list style="symbols">
<t>IPv6 address of the border router (AFTR) (sec. 5.4);</t>
<t>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.</t>
<t>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). </t>
</list>
</t>
</section> <!-- dslite -->
<section anchor="pub4o6" title="Public IPv4 Over IPv6">
<t>Public IPv4 Over IPv6 is described in
<xref target="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:
<list style="symbols">
<t>a public IPv4 address;</t>
<t>IPv6 address of the border router</t>
</list>
It also requires per-subscriber provisioning on the border router:
<list style="symbols">
<t>binding between the customer IPv4 address and the customer
IPv6 prefix, for routing of incoming packets to the correct tunnel.</t>
</list>
</t>
</section> <!-- pub4o6 -->
<section anchor="lw4o6" title="Light Weight IPv4 Over IPv6 (LW4o6)">
<t>Light Weight IPv4 Over IPv6 (LW4o6) is documented in
<xref target="I-D.ietf-softwire-lw4over6"/>. Its
provisioning requirements are exactly the same as those for Public
4over6 with one addition:
<list style="symbols">
<t>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.</t>
</list>
</t>
</section> <!-- lw4o6 -->
<section anchor="map-e" title="Mapping of Address and Port with Encapsulation (MAP-E)">
<t>Mapping of Address and Port with Encapsulation (MAP-E) is described
in <xref target="I-D.ietf-softwire-map"/>. MAP-E requires the
provisioning of the following per-subscriber information at the
customer edge device:
<list style="symbols">
<t>whether the device is to operate in mesh or hub-and-spoke mode;</t>
<t>the IPv6 address of one or more border routers;</t>
<t>the specially constructed End-user IPv6 prefix for the customer
edge device. <xref target="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. </t>
<t>the Basic Mapping Rule for the customer edge device. This
includes the following parameters:
<list style="symbols">
<t>the rule IPv6 prefix and length;</t>
<t>the rule IPv4 prefix and length;</t>
<t>the number of "Extended Address" (EA) bits included in the
End-user IPv6 prefix;</t>
<t>of those Extended Address bits, the number that precede the port
set identifier. The default value is 6.</t>
</list>
</t>
<t>in mesh mode only, zero or more Forwarding Mapping Rules,
containing the same parameters as the Basic Mapping rule.</t>
<t>optionally, the port set identifier if the EA bits do not carry it.</t>
</list>
</t>
<t>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.</t>
</section> <!-- map-e -->
<section anchor="sumreq" title="Summing Up">
<t>It appears that the following items are common to two or more
methods and the corresponding AVPs to carry them can be reused:
<list style="symbols">
<t>the IPv6 address of the border router;</t>
<t>an IPv4 prefix and length (could be a /32);</t>
<t>a port set identifier.</t>
</list>
</t>
<t>The remaining requirements are method-specific:
<list style="symbols">
<t>for Public 4over6 and LW4o6, a binding between a customer IPv6
prefix or address and an IPv4 address;</t>
<t>for MAP-E, the indication of whether mesh mode or hub-and-spoke
mode is to be used;</t>
<t>for MAP-E, a Grouped AVP expressing a MAP Rule.</t>
</list></t>
</section> <!-- sumreq -->
</section> <!-- reqts -->
<section anchor="AVPdefs" title="Attribute-Value Pair Definitions">
<t>This section provides the specifications for the AVPs needed to
meet the requirements summarized in <xref target="sumreq"/>. Within
the context of their usage, all of these AVPs MUST have the M bit set
and the V bit cleared.</t>
<section anchor="dslite_AVP" title="DS-Lite Attributes">
<t>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 <xref target="I-D.softwire-dslite-multicast"/>.</t>
<figure anchor="fig_dslite_AVP" title="">
<artwork>
DS-Lite-Attributes ::= < AVP Header: TBD01 >
{ Border-Router-IPv6-Address }
0*1[ ASM-Prefix64 ]
0*1[ SSM-Prefix64 ]
0*1[ Unicast-Prefix64 ]
*[ AVP ]
</artwork>
</figure>
<t>The Border-Router-IPv6-Address AVP is defined in <xref
target="braddr"/>. Within the DS-Lite-Attributes AVP, it provides the
IPv6 address of the AFTR. This AVP MUST be present.</t>
<t>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.</t>
<section anchor="ASM-pref" title="ASM-Prefix64">
<t>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.</t>
<t>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.</t>
</section> <!-- ASM-pref -->
<section anchor="SSM-Pref" title="SSM-Prefix64">
<t>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.</t>
<t>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 <xref target="RFC4607"/> mode. The conveyed
multicast IPv6 prefix MUST belong to the SSM range. This prefix is
likely to be a /96.</t>
</section> <!-- SSM-Pref -->
<section anchor="Uni-Pref" title="Unicast-Prefix64">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC6052"/>.</t>
</section> <!-- Uni-Pref -->
</section> <!-- dslite -->
<section anchor="publicV4" title="Public Unshared IPv4 Address">
<t>The Public-Unshared-IPv4-Address AVP (AVP Code TBD05) is of type Address
as defined in Section 4.3 of <xref target="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).</t>
</section> <!-- publicV4 -->
<section anchor="lw4o6-attrib" title="Light-Weight 4over6 Attributes">
<t>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.</t>
<figure anchor="fig_lw4o6_AVP" title="">
<artwork>
Light-Weight-4over6-Attributes ::= < AVP Header: TBD06 >
{ Border-Router-IPv6-Address }
0*1[ IPv6-Prefix-Or-Addr ]
0*1[ Port-Set-Identifier ]
*[ AVP ]
</artwork>
</figure>
<t>The Border-Router-IPv6-Address AVP is defined in <xref
target="braddr"/> and provides the IPv6 address of the Border Router.
This AVP MUST be present.</t>
<t>The IPv6-Prefix-Or-Addr AVP is defined in <xref
target="v6pref"/>. 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.</t>
<t>The Port-Set-Identifier AVP is defined in <xref target="psid"/>. 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.</t>
</section> <!-- lw4o6-attrib -->
<section anchor="map-e-attrib" title="MAP-E Attributes">
<t>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. </t>
<figure anchor="fig_map_e_AVP" title="">
<artwork>
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 ]
</artwork>
</figure>
<t>The Border-Router-IPv6-Address AVP is defined in <xref
target="braddr"/> and provides the IPv6 address of the Border Router.
At least one instance of this AVP MUST be present.</t>
<t>The Mesh-Or-Hub-And-Spoke AVP is defined in <xref target="meshhs"/>.
It indicates whether the the MAP-E domain supports mesh mode or
hub-and-spoke mode. This AVP MUST be present.</t>
<t>The IPv6-Prefix-Or-Addr AVP is defined in <xref
target="v6pref"/>. 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 same information is conveyed to
the recipient of the MAP-E-Attributes AVP by another
AVP in the subscriber profile.</t>
<t>The Mapping-Rule AVP is defined in <xref target="mapRule"/>. 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.</t>
</section> <!-- map-e-attrib -->
<section anchor="mapRule" title="Mapping Rule">
<t>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.</t>
<t>The syntax of the Mapping-Rule AVP is as follows:</t>
<figure anchor="fig_map" title="">
<artwork>
Mapping-Rule ::= < AVP Header: TBD08 >
{ IPv4-Prefix-Or-Addr }
{ IPv6-Prefix-Or-Addr }
{ EA-Field-Length }
[ PSID-Offset ]
*[ AVP ]
</artwork>
</figure>
<t>The IPv4-Prefix-Or-Addr AVP and IPv6-Prefix-Or-Addr AVPs are defined
in sections <xref target="v4pref"/> and <xref target="v6pref"/>
respectively. They MUST be present within the Mapping-Rule AVP. The
EA-Field-Length AVP and PSID-Offset AVP are defined in this section.</t>
<section anchor="EAlen" title="EA Field Length">
<t>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 <xref target="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.</t>
</section> <!-- EAlen -->
<section anchor="PSIDoffset" title="PSID Offset">
<t>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 <xref target="I-D.ietf-softwire-map"/> if the parameter is
absent. AVP Length for the PSID-Offset AVP MUST be set to 12.</t>
</section> <!-- PSIDoffset -->
</section> <!-- maprule -->
<section anchor="braddr" title="Border Router IPv6 Address">
<t>The Border-Router-IPv6-Address (AVP Code TBD11) is of type Address
as defined in Section 4.3 of <xref target="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). </t>
</section> <!-- braddr -->
<section anchor="v4pref" title="IPv4 Prefix or Address">
<t>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.</t>
</section> <!-- v4pref -->
<section anchor="v6pref" title="IPv6 Prefix or Address">
<t>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.</t>
</section> <!-- v6pref -->
<section anchor="psid" title="Port Set Identifier">
<t>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.</t>
</section> <!-- psid -->
<section anchor="meshhs" title="Mesh Or Hub And Spoke">
<t>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:
<list style="empty">
<t>(1) mesh mode;</t>
<t>(2) hub-and-spoke mode.</t>
</list>
</t>
</section> <!-- meshhs -->
</section> <!-- AVPdefs -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo requests to IANA to register the following Diameter AVP
codes: </t>
<texttable anchor="tt_codes" title="">
<ttcol align="center">Code</ttcol>
<ttcol align="left">Attribute Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c>TBD01</c>
<c>DS-Lite-Attributes</c>
<c>This document</c>
<c>TBD02</c>
<c>ASM-Prefix64</c>
<c>This document</c>
<c>TBD03</c>
<c>SSM-Prefix64</c>
<c>This document</c>
<c>TBD04</c>
<c>Unicast-Prefix64</c>
<c>This document</c>
<c>TBD05</c>
<c>Public-Unshared-IPv4-Address</c>
<c>This document</c>
<c>TBD06</c>
<c>Light-Weight-4over6-Attributes</c>
<c>This document</c>
<c>TBD07</c>
<c>MAP-E-Attributes</c>
<c>This document</c>
<c>TBD08</c>
<c>Mapping-Rule</c>
<c>This document</c>
<c>TBD09</c>
<c>EA-Field-Length</c>
<c>This document</c>
<c>TBD10</c>
<c>PSID-Offset</c>
<c>This document</c>
<c>TBD11</c>
<c>Border-Router-IPv6-Address</c>
<c>This document</c>
<c>TBD12</c>
<c>IPv4-Prefix-Or-Addr</c>
<c>This document</c>
<c>TBD13</c>
<c>IPv6-Prefix-Or-Addr</c>
<c>This document</c>
<c>TBD14</c>
<c>Port-Set-Identifier</c>
<c>This document</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>To come.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC2119;
&RFC6333;
&RFC6733;
<reference anchor="I-D.ietf-softwire-unified-cpe">
<front>
<title>Unified IPv4-in-IPv6 Softwire CPE (work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom</organization>
</author>
<date month="May" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-lw4over6">
<front>
<title>Lightweight 4over6: An Extension to the DS-Lite Architecture (work in progress)</title>
<author initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="Q." surname="Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
</author>
<author initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<author initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<date month="July" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map-radius">
<front>
<title>RADIUS Attribute for MAP (work in progress)</title>
<author initials="Sheng" surname="Jiang" fullname="Sheng Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Yu" surname="Fu" fullname="Yu Fu">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Bing" surname="Liu" fullname="Bing Liu">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Peter" surname="Deacon" fullname="Peter Deacon">
<organization>IEA Software, Inc.</organization>
</author>
<date month="June" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map">
<front>
<title>Mapping of Address and Port with Encapsulation (MAP) (work in progress)</title>
<author initials="O." surname="Troan">
<organization>Cisco Systems</organization>
</author>
<author initials="W." surname="Dec">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="C." surname="Bao">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="S." surname="Matsushima">
<organization>SoftBank Telecom</organization>
</author>
<author initials="T." surname="Murakami">
<organization>IP Infusion</organization>
</author>
<author initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
</author>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-public-4over6">
<front>
<title>Public IPv4 over IPv6 Access Network (work in progress)</title>
<author initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="J." surname="Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="P." surname="Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="O." surname="Vautrin">
<organization>Juniper Networks</organization>
</author>
<author initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<date month="July" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-dslite-multicast">
<front>
<title>Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network (work in progress)</title>
<author initials="J." surname="Qin">
<organization>Cisco</organization>
</author>
<author initials="M." surname="Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
</author>
<author initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<author initials="Q." surname="Wang">
<organization>China Telecom</organization>
</author>
<date month="October" year="2013"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC2131;
&RFC3315;
&RFC2865;
&RFC4607;
&RFC6052;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:28 |