One document matched: draft-zhou-dime-4over6-provisioning-03.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 RFC6334 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6334.xml">
<!ENTITY RFC6519 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6519.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-03"
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 CE 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>PT Taylor Consulting</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="2014" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>DS-Lite</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 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 <xref target="RFC6733"/>.</t>
<t>As described below, in the particular case where the Light Weight IPv4
Over IPv6 (LW4o6) <xref target="I-D.ietf-softwire-lw4over6"/> transition
method has been deployed, per-subscriber-site information almost identical
to that passed to the subscriber site
<xref target="I-D.ietf-softwire-map-dhcp"/> or
collected from it <xref target="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. </t>
<t>This document analyzes the information required to configure the
customer edge equipment for the following set of transition methods:
<list style="symbols">
<t>Dual-Stack Lite <xref target="RFC6333"/>,</t>
<t>Light Weight IPv4 Over IPv6 (LW4over6)
<xref target="I-D.ietf-softwire-lw4over6"/>, and</t>
<t>Mapping of Address and Port with Encapsulation (MAP-E)
<xref target="I-D.ietf-softwire-map"/>.</t>
</list>
On the basis of that analysis it specifies a number of attribute-value
pairs (AVPs) to allow the necessary subscriber-site-specific configuration
information to be carried in Diameter.
</t>
<t>This document is intended to be complementary to documents such as
<xref target="RFC6519"/>,
<xref target="I-D.sun-softwire-lw4over6-radext"/>, and
<xref target="I-D.ietf-softwire-map-radius"/> which provide
RADIUS attributes to carry similar configuration information for the
respective transition methods. Reconciliation of the present document
with these other documents is a work in progress.</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"/>.</t>
<t>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.</t>
<t>The term "tunnel source address" is used to denote the IPv6 source
address used in the outer header of packets sent from the CE through an
LW4over6 transitional tunnel to the border router.</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 two of
the three 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. The approach taken in this document is to
specify grouped AVPs specific to LW4over6 and MAP-E. The operator can
control which of these two transition methods a given subscriber uses by
ensuring that AAA passes only the grouped AVP relevant to that method. A
grouped AVP is unnecessary for Dual-Stack Lite, since (as the next section
indicates) AAA has to provide only one parameter. Hence the absence of
either of the grouped AVPs indicates that the subscriber equipment will
use Dual-Stack Lite.</t>
<section anchor="dslite" title="Parameters For Dual-Stack Lite">
<t>Dual-Stack Lite is documented in <xref target="RFC6333"/>. The Basic
Bridging BroadBand (B4) element at the customer premises needs to be
provisioned with 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). </t>
</section> <!-- dslite -->
<section anchor="lw4o6" title="Light Weight IPv4 Over IPv6 (LW4over6)">
<t>Light Weight IPv4 Over IPv6 (LW4over6) is documented in
<xref target="I-D.ietf-softwire-lw4over6"/>. LW4over6 requires four
parameters to be provisioned to the customer equipment:
<list style="symbols">
<t>IPv6 address of the border router.</t>
<t>IPv6 prefix used by the CE to construct the tunnel source address.
In the terminology of <xref target="I-D.ietf-softwire-lw4over6"/>,
this is the IPv6 Binding Prefix.</t>
<t>an IPv4 address to be used on the external side of the CE; and</t>
<t>if the IPv4 address is shared, a specification of the port set
the subscriber site is allowed to use.</t>
</list>
</t>
<t>
As discussed in Section 4 of
<xref target="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. </t>
<t><xref target="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. </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>the IPv6 address of one or more border routers;</t>
<t>the unique End-user IPv6 prefix for the customer
edge device; </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>
<t>optionally, a specification of the port set the subscriber site
is allowed to use if the EA bits do not convey it (final case of
Section 5.2 of the MAP-E document).</t>
</list>
</t>
<t>whether the device is to operate in mesh or hub-and-spoke mode;</t>
<t>in mesh mode only, zero or more Forwarding Mapping Rules, described
by the same set of parameters as the Basic Mapping Rule;</t>
</list>
</t>
<t>As indicated in Section 5, bullet 1 of the MAP-E document, a MAP CE
can be provisioned with multiple End-user IPv6 prefixes, each associated
with its own Basic Mapping Rule. This does not change the basic
requirement for representation of the corresponding information in the
form of Diameter AVPs, but adds a potential requirement for multiple
instances of both types of AVP to be present. </t>
<t>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.</t>
</section> <!-- map-e -->
<section anchor="sumreq" title="Summary and Discussion">
<t>It appears that one item is common to the different
transition methods and the corresponding AVP to carry it can be
reused:
<list style="symbols">
<t>a representation of the IPv6 address of a border router;</t>
</list>
</t>
<t><xref target="RFC6519"/> sets a precedent for representation of the
IPv6 address of a border router as an FQDN. This can be dereferenced
to one or more IP addresses by the provisioning system before being
passed to the customer equipment, or left as an FQDN as it is in
<xref target="RFC6334"/>.</t>
<t>The remaining requirements are transition-method-specific:
<list style="symbols">
<t>for LW4over6, a representation of a binding between either the IPv6
Binding Prefix or a full /128 IPv6 address, a public IPv4 address, and
a port set identifier;</t>
<t>for MAP-E, a representation of a Mapping Rule;</t>
<t>for MAP-E, an indication of whether mesh mode or hub-and-spoke
mode is to be used.</t>
</list>
</t>
</section> <!-- sumreq -->
</section> <!-- reqts -->
<section anchor="deriv" title="Derived AVP Data Formats: AddressOrPrefix">
<t>The above requirements involve IP addresses and prefixes in a number of
contexts. To simplify specification of these attributes, this section
defines a new derived AVP data format, AddressOrPrefix, according to the
rules given in Section 4.3 of <xref target="RFC6733"/>.</t>
<t>AddressOrPrefix
<list style="empty">
<t>The AddressOrPrefix data format is an extension of the Address
data format defined in Section 4.3.1 of <xref target="RFC6733"/>.
Like the Address data format, it is derived from the OctetString basic
AVP format. As well as an AddressType, it contains a PrefixLength field.
The detailed specification is as follows:
<list style="symbols">
<t>As with the Address AVP, the first two octets represent the
AddressType, which contains an Address Family, defined in
<xref target="IANAADFAM"/>.</t>
<t>The next two octets are interpreted as a 16-bit unsigned integer
representing the PrefixLength. Valid values of PrefixLength are
from 0 to 32 for IPv4 and from 0 to 128 for IPv6. The value 0 is
included in each range to allow for presentation of a "null prefix",
the meaning of which must be defined by applications that use AVPs
based on the AddressOrPrefix data format.
</t>
<t>The remaining octets present the prefix or address, most
significant octet first. If the prefix does not extend to an
octet boundary, the low-order bits of the final octet are padded with
zeroes.</t>
</list>
</t>
</list></t>
</section> <!-- deriv -->
<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="BRaddr" title="Border-Router-Name AVP">
<t>Following on the precedent set by <xref target="RFC6334"/> and <xref
target="RFC6519"/>, this 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 <xref target="RFC6733"/>).</t>
</section> <!-- BRaddr -->
<section anchor="teppfx"
title="Tunnel-Source-Pref-Or-Addr AVP">
<t>The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) is of type
AddressOrPrefix. It conveys either a prefix or a full address that is
configured as the tunnel source address on the CE. Within the scope of
application of this document it is intended for use to convey the
LW4over6 Binding Prefix from AAA to the provisioning system or to carry
a full IPv6 tunnel source address that has been collected from the CE,
either from the provisioning system to AAA or from AAA to the border
router. This AVP is defined separately from the LW4over6-Binding AVP
(which includes it) to provide flexibility in the transport of the
tunnel source address from the provisioning system to AAA.</t>
<t>The Tunnel-Endpoint-Pref-Or-Addr AVP
</t>
</section> <!-- teppfx -->
<section anchor="psid" title="Port-Set-Identifier">
<t>The Port-Set-Identifier AVP (AVP Code TBD03) 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 quantities
illustrated in Figure 9, Appendix B of
<xref target="I-D.ietf-softwire-map"/>. The derivation of port
numbers from these parameters is described in that appendix.
<list style="symbols">
<t>The first (high-order) octet is the Offset field. It is interpreted
as an 8-bit unsigned integer giving the offset 'a' from the beginning
of a port number to the beginning of the port set identifier (PSID) to
which that port belongs. Valid values are from 0 to 15.</t>
<t>The next octet, the PSIDLength, is also interpreted as an 8-bit
unsigned integer and gives the length in bits of the port set
identifier (PSID). This corresponds to the value 'k' in the figure
referred to above. Valid values are from 1 to (16 - a).</t>
<t>The final two octets constitute the PSIDValue field and are
interpreted as a 16-bit unsigned integer. They give the value of the
PSID itself, right-justified within the field. That is, the value of
the PSID occupies the 'k' lowest-order bits of the PSIDValue
field.</t>
</list>
</t>
</section> <!-- psid -->
<section anchor="lw4o6-binding" title="LW4over6-Binding">
<t>The LW4over6-Binding AVP (AVP Code TBD04) is of type Grouped. It
contains the elements of configuration that constitute the binding
between an LW4over6 tunnel and IPv4 packets sent through that tunnel.
</t>
<figure anchor="fig_lw4o6_AVP" title="">
<artwork>
LW4over6-Binding ::= < AVP Header: TBD04 >
{ Tunnel-Source-Pref-Or-Addr }
{ LW4over6-External-IPv4-Addr }
[ Port-Set-Identifier ]
*[ AVP ]
</artwork>
</figure>
<t>The Tunnel-Source-Pref-Or-Addr AVP is defined in <xref
target="teppfx"/> and provides either the Binding Prefix or the full
IPv6 tunnel source address. This AVP MUST be present.</t>
<t>The LW4over6-External-IPv4-Addr AVP (AVP Code TBD05) is of type
AddressOrPrefix. Within the LW4over6-Binding AVP, it provides the
external IPv4 address used as the source address for packets outgoing
from the CE through the LW4over6 tunnel associated with the given
binding, or destination address for incoming packets. This AVP MUST be
present.</t>
<t>The Port-Set-Identifier AVP is defined in <xref target="psid"/>. It
identifies the specific set of ports assigned to the LW4over6 tunnel.
This AVP MUST be present except when 1-1 mapping mode is being
provisioned, when it MUST NOT be present. </t>
</section> <!-- lw4o6-attrib -->
<section anchor="map-e-attrib" title="MAP-E-Attributes">
<t>The MAP-E-Attributes AVP (AVP Code TBD06) is of type Grouped. It
contains the configuration data identified in <xref target="map-e"/>,
for a single MAP domain. If a CE belongs to more than one MAP domain,
AAA will have to provide an instance of the MAP-E-Attributes AVP for
each domain.
</t>
<figure anchor="fig_map_e_AVP" title="">
<artwork>
MAP-E-Attributes ::= < AVP Header: TBD06 >
1*{ Border-Router-Name }
1*{ MAP-Mapping-Rule }
[ MAP-Mesh-Mode ]
[ MAP-End-User-IPv6-Prefix ]
*[ AVP ]
</artwork>
</figure>
<t>The Border-Router-Name AVP is defined in <xref target="BRaddr"/>.
It provides the FQDN of a MAP border relay at the edge of the
MAP domain to which the containing MAP-E-Attributes AVP relates.
The provisioning system will typically resolve this FQDN into
one or more IPv6 addresses before passing it to the CE. At least one
instance of this AVP MUST be present.</t>
<t>The MAP-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 MAP-Mapping-Rule instances MAY be
present. If the MAP-E domain is operating in hub-and-spoke mode,
additional MAP-Mapping-Rule instances MUST NOT be present.</t>
<t>The MAP-Mesh-Mode AVP (AVP Code TBD07) is of type OctetString but has
no data. Hence the AVP length is always 8. The absence of the mesh mode
indicator attribute indicates that the CE is required to operate in hub-
and-spoke mode.</t>
<t>The MAP-End-User-IPv6-Prefix AVP (AVP Code TBD08) is of type
AddressOrPrefix. Within the MAP-E-Attributes AVP, it provides the end-
user IPv6 prefix assigned to the CE for the MAP domain to which the
containing MAP-E-Attributes AVP relates. This attribute is optional
because, depending on deployment, the end-user IPv6 prefix may be
provided by AAA or by another support system. </t>
</section> <!-- map-e-attrib -->
<section anchor="mapRule" title="MAP-Mapping-Rule">
<t>The MAP-Mapping-Rule AVP (AVP Code TBD09) 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 MAP
border relay and by the CE. The components of the MAP-Mapping-Rule AVP
provide the contents of a mapping rule as described in <xref
target="map-e"/>.</t>
<t>The syntax of the MAP-Mapping-Rule AVP is as follows:</t>
<figure anchor="fig_map" title="">
<artwork>
MAP-Mapping-Rule ::= < AVP Header: TBD09 >
{ Rule-IPv4-Addr-Or-Prefix }
{ Rule-IPv6-Prefix }
{ EA-Field-Length }
[ Port-Set-Identifier ]
*[ AVP ]
</artwork>
</figure>
<t>The Rule-IPv4-Addr-Or-Prefix AVP (AVP Code TBD10) is of type
AddressOrPrefix. The prefix length can range from 0 to 32,
based on the different cases identified in Section 5.2 of
<xref target="I-D.ietf-softwire-map"/>. A prefix length of 0
indicates that the entire IPv4 address or prefix is coded in the
Extended Address (EA) bits of the end-user IPv6 prefix rather
than in the mapping rule. This AVP MUST be present.</t>
<t>The Rule-IPv6-Prefix AVP (AVP Code TBD11) is also of type
AddressOrPrefix. The prefix length MUST be less than or equal
to the length of the prefix in the MAP-End-User-IPv6-Prefix AVP
contained in the same instance of the MAP-E-Attributes AVP as
the MAP-Mapping-Rule AVP instance to which the Rule-IPv6-Prefix
AVP belongs. The Rule-IPv6-Prefix AVP MUST be present.</t>
<t>The EA-Field-Length AVP (AVP Code TBD12) is of type
Unsigned32. Valid values range from 0 to 48. See Section 5.2 of
<xref target="I-D.ietf-softwire-map"/> for a description of the use
of this parameter in deriving IPv4 address and port number
configuration. This AVP MUST be present.</t>
<t>The Port-Set-Identifier AVP is defined in <xref target="psid"/>.
It MUST be present if the value of EA-Field-Length AVP is 0,
and is redundant (SHOULD NOT be present) otherwise.</t>
</section> <!-- maprule -->
</section> <!-- AVPdefs -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Tom Taylor performed work on earlier versions of this document with
funding from Huawei Technologies.</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>Border-Router-Name</c>
<c>This document</c>
<c>TBD02</c>
<c>Tunnel-Source-Pref-Or-Addr</c>
<c>This document</c>
<c>TBD03</c>
<c>Port-Set-Identifier</c>
<c>This document</c>
<c>TBD04</c>
<c>LW4over6-Binding</c>
<c>This document</c>
<c>TBD05</c>
<c>LW4over6-External-IPv4-Addr</c>
<c>This document</c>
<c>TBD06</c>
<c>MAP-E-Attributes</c>
<c>This document</c>
<c>TBD07</c>
<c>MAP-Mesh-Mode</c>
<c>This document</c>
<c>TBD08</c>
<c>MAP-End-User-IPv6-Prefix</c>
<c>This document</c>
<c>TBD09</c>
<c>MAP-Mapping-Rule</c>
<c>This document</c>
<c>TBD10</c>
<c>Rule-IPv4-Addr-Or-Prefix</c>
<c>This document</c>
<c>TBD11</c>
<c>Rule-IPv6-Prefix</c>
<c>This document</c>
<c>TBD12</c>
<c>EA-Field-Length</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-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="March" year="2014"/>
</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="January" year="2014"/>
</front>
</reference>
<reference anchor="IANAADFAM"
target="http://www.iana.org/assignments/address-family-numbers">
<front>
<title>Address Family Numbers</title>
<author initials="" surname="">
<organization>IANA</organization>
</author>
<date month="" year=""/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC2131;
&RFC3315;
&RFC2865;
&RFC4607;
&RFC6052;
&RFC6334;
&RFC6519;
<reference anchor="I-D.ietf-softwire-map-dhcp">
<front>
<title>DHCPv6 Options for configuration of Softwire Address and
Port Mapped Clients (Work in progress)</title>
<author initials="T." surname="Mrugalski">
<organization>ISC</organization>
</author>
<author initials="O." surname="Troan">
<organization>Cisco</organization>
</author>
<author initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<author initials="S." surname="Perrault">
<organization>Viagenie</organization>
</author>
<author initials="W." surname="Dec">
<organization>Cisco</organization>
</author>
<author initials="C." surname="Bao">
<organization>Tsinghua University</organization>
</author>
<author initials="L." surname="Yeh">
<organization>CNNIC</organization>
</author>
<author initials="X." surname="Deng">
<organization>Yingke Law Firm</organization>
</author>
<date month="March" year="2014"/>
</front>
</reference>
<reference anchor="I-D.sun-softwire-lw4over6-radext">
<front>
<title>Radius Extension for Lightweight 4over6 (Work in progress)</title>
<author initials="C." surname="Xie">
<organization>China Telecom</organization>
</author>
<author initials="Q." surname="Sun">
<organization>China Telecom</organization>
</author>
<author initials="Q." surname="Sun">
<organization>Tsinghua University</organization>
</author>
<author initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
</author>
<author initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
</author>
<author initials="Z." surname="Liu">
<organization>Tsinghua University</organization>
</author>
<date month="March" year="2014"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map-radius">
<front>
<title>RADIUS Attribute for MAP (Work in progress)</title>
<author initials="S." surname="Jiang">
<organization>Huawei Technologies Co., Ltd.</organization>
</author>
<author initials="Y." surname="Fu">
<organization>Huawei Technologies Co., Ltd.</organization>
</author>
<author initials="B." surname="Liu">
<organization>Huawei Technologies Co., Ltd.</organization>
</author>
<author initials="P." surname="Deacon">
<organization>IEA Software, Inc.</organization>
</author>
<date month="June" year="2014"/>
</front>
</reference>
<reference anchor="I-D.fsc-softwire-dhcp4o6-saddr-opt">
<front>
<title>DHCPv4 over DHCPv6 Source Address Option (Work in progress)</title>
<author initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<author initials="Q." surname="Sun">
<organization>Tsinghua University</organization>
</author>
<author initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
</author>
<date month="June" year="2014"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:19 |