One document matched: draft-ietf-softwire-map-radius-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. -->
<?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. -->
<?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="3"?>
<!-- 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-ietf-softwire-map-radius-02"
ipr="pre5378Trust200902">
<front>
<title abbrev="MAP RADIUS ">RADIUS Attribute for MAP</title>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<author fullname="Yu Fu" initials="Y." surname="Fu">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>eleven.fuyu@huawei.com</email>
</address>
</author>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Peter Deacon" initials="P." surname="Deacon">
<organization>IEA Software, Inc.</organization>
<address>
<postal>
<street>P.O. Box 1170</street>
<city>Veradale</city>
<region>WA</region>
<code>99037</code>
<country>USA</country>
</postal>
<email>peterd@iea-software.com</email>
</address>
</author>
<date month="" year="2014"/>
<area>Internet Area</area>
<workgroup>Softwire</workgroup>
<keyword>IPv6 Transition, MAP, RADIUS</keyword>
<abstract>
<t>Mapping of Address and Port (MAP) is a stateless mechanism for
running IPv4 over IPv6-only infrastructure. It provides both IPv4 and
IPv6 connectivity services simultaneously during the IPv4/IPv6
co-existing period. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) MAP options has been defined to configure MAP Customer Edge
(CE). However, in many networks, the configuration information may be
stored in Authentication Authorization and Accounting (AAA) servers
while user configuration is mainly from Broadband Network Gateway (BNG)
through DHCPv6 protocol. This document defines a Remote Authentication
Dial In User Service (RADIUS) attribute that carries MAP configuration
information from AAA server to BNG. The MAP RADIUS attribute are
designed following the simplify principle. It provides just enough
information to form the correspondent DHCPv6 MAP option.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Recently providers start to deploy IPv6 and consider how to transit
to IPv6. Mapping of Address and Port (MAP)<xref
target="I-D.ietf-softwire-map"/> is a stateless mechanism for running
IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6
connectivity services simultaneously during the IPv4/IPv6 co-existing
period. MAP has adopted Dynamic Host Configuration Protocol for IPv6
(DHCPv6) <xref target="RFC3315"/> as auto-configuring protocol. The MAP
Customer Edge (CE) uses the DHCPv6 extension options <xref
target="I-D.ietf-softwire-map-dhcp"/> to discover MAP Border Relay (in
tunnel model only) and to configure relevant MAP rules.</t>
<t>In many networks, user configuration information may be managed by
AAA (Authentication, Authorization, and Accounting) servers. Current AAA
servers communicate using the Remote Authentication Dial In User Service
(RADIUS) <xref target="RFC2865"/> protocol. In a fixed line broadband
network, the Broadband Network Gateways (BNGs) act as the access gateway
of users. The BNGs are assumed to embed a DHCPv6 server function that
allows them to locally handle any DHCPv6 requests initiated by
hosts.</t>
<t>Since the MAP configuration information is stored in AAA servers and
user configuration is mainly through DHCPv6 protocol between BNGs and
hosts/CEs, new RADIUS attributes are needed to propagate the information
from AAA servers to BNGs. The MAP RADIUS attributes designed in this
document are especially for the MAP encapsulation mode, while providing
enough information to form the correspondent DHCPv6 MAP option <xref
target="I-D.ietf-softwire-map-dhcp"/>.</t>
</section>
<section title="Terminology">
<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 terms MAP CE and MAP Border Relay are defined in <xref
target="I-D.ietf-softwire-map"/>.</t>
</section>
<section title="MAP Configuration process with RADIUS">
<t>The below Figure 1 illustrates how the RADIUS protocol and DHCPv6
cooperate to provide MAP CE with MAP configuration information.</t>
<figure title="Figure 1: the cooperation between DHCPv6 and RADIUS combining with RADIUS authentication">
<artwork><![CDATA[ MAP CE BNG AAA Server
| | |
|------DHCPv6 Solicit----->| |
|(Option Request w/ MAP option) |
| |--Access-Request(MAP Attr)-->|
| | |
| |<--Access-Accept(MAP Attr)---|
|<---DHCPv6 Advertisement--| |
| | |
|------DHCPv6 Request---->| |
| (MAP Option) | |
|<---- -DHCPv6 Reply-------| |
| (MAP option) | |
| | |
DHCPv6 RADIUS
]]></artwork>
</figure>
<t>BNGs act as a RADIUS client and as a DHCPv6 server. First, the MAP CE
MAY initiate a DHCPv6 Solicit message that includes an Option Request
option (6) <xref target="RFC3315"/> with the MAP option <xref
target="I-D.ietf-softwire-map-dhcp"/> from the MAP CE. But note that the
ORO (Option Request option) with the MAP option could be optional if the
network was planned as MAP-enabled as default. When BNG receives the
SOLICIT, it SHOULD initiates radius Access-Request message, in which the
User-Name attribute (1) SHOULD be filled by the MAP CE MAC address, to
the RADIUS server and the User-password attribute (2) SHOULD be filled
by the shared MAP password that has been preconfigured on the DHCPv6
server, requesting authentication as defined in <xref target="RFC2865"/>
with MAP-Configuration attribute, defined in the next Section. If the
authentication request is approved by the AAA server, an Access-Accept
message MUST be acknowledged with the IPv6-MAP-Configuration Attribute.
After receiving the Access-Accept message with MAP-Configuration
Attribute, the BNG SHOULD respond the user an Advertisement message.
Then the user can requests for a MAP Option, the BNG SHOULD reply the
user with the message containing the MAP option. The recommended format
of the MAC address is as defined in Calling-Station-Id (Section 3.20 in
<xref target="RFC3580"/> without the SSID (Service Set Identifier)
portion.</t>
<t>Figure 2 describes another scenario, in which the authorization
operation is not coupled with authentication. Authorization relevant to
MAP is done independently after the authentication process. As similar
to above scenario, the ORO with the MAP option in the initial DHCPv6
request could be optional if the network was planned as MAP-enabled as
default.</t>
<t><figure
title="Figure 2: the cooperation between DHCPv6 and RADIUS decoupled with RADIUS authentication ">
<artwork><![CDATA[ MAP CE BNG AAA Server
| | |
|------DHCPv6 Request---->| |
|(Option Request w/ MAP option) |
| |--Access-Request(MAP Attr)-->|
| | |
| |<--Access-Accept(MAP Attr)---|
| | |
|<-----DHCPv6 Reply--------| |
| (MAP option) | |
| | |
DHCPv6 RADIUS
]]></artwork>
</figure></t>
<t>In the abovementioned scenario, the Access-Request packet SHOULD
contain a Service-Type attribute (6) with the value Authorize Only (17);
thus, according to <xref target="RFC5080"/>, the Access-Request packet
MUST contain a State attribute that obtained from the previous
authentication process.</t>
<t>In both above-mentioned scenarios, Message-authenticator (type 80)
<xref target="RFC2869"/> SHOULD be used to protect both Access-Request
and Access-Accept messages.</t>
<t>After receiving the MAP-Configuration Attribute in the initial
Access-Accept, the BNG SHOULD store the received MAP configuration
parameters locally. When the MAP CE sends a DHCPv6 Request message to
request an extension of the lifetimes for the assigned address, the BNG
does not have to initiate a new Access-Request towards the AAA server to
request the MAP configuration parameters. The BNG could retrieve the
previously stored MAP configuration parameters and use them in its
reply.</t>
<t>If the BNG does not receive the MAP-Configuration Attribute in the
Access-Accept it MAY fallback to a pre-configured default MAP
configuration, if any. If the BNG does not have any pre-configured
default MAP configuration or if the BNG receives an Access-Reject, the
tunnel cannot be established.</t>
<t>As specified in <xref target="RFC3315"/>, section 18.1.4, "Creation
and Transmission of Rebind Messages ", if the DHCPv6 server to which the
DHCPv6 Renew message was sent at time T1 has not responded by time T2,
the MAP CE (DHCPv6 client) SHOULD enters the Rebind state and attempt to
contact any available server. In this situation, the secondary BNG
receiving the DHCPv6 message MUST initiate a new Access-Request towards
the AAA server. The secondary BNG MAY include the MAP-Configuration
Attribute in its Access-Request.</t>
</section>
<section title="Attributes">
<t>This section defines MAP-Rule Attribute which is used in the MAP
scenario. The attribute design follows <xref target="RFC6158"/> and
referring to<xref target="RFC6929"/>.</t>
<t>The MAP RADIUS attribute are designed following the simplify
principle. The sub options are organized into two categories: the
necessary and the optional.</t>
<section title="MAP-Configuration Attribute">
<t>The MAP-Configuration Attribute is structured as follows:<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ MAP Rule Option(s) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
2 + the length of the Rule option(s)
MAP Rule Option (s)
A variable field that may contains one or more Rule option(s),
defined in Section 4.2.
]]></artwork>
</figure></t>
</section>
<section title="MAP Rule Options">
<t>Depending on deployment scenario, one Default Mapping rule and zero
or more other type Mapping Rules MUST be included in one
MAP-Configuration Attribute.</t>
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Sub Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1 Basic Mapping Rule (Not Forwarding Mapping Rule)
2 Forwarding Mapping Rule (Not Basic Mapping Rule)
3 Default Mapping Rule
4 Basic & Forwarding Mapping Rule
Length
2 + the length of the sub options
Sub Option
A variable field that contains necessary sub options defined in
Section 4.3 and zero or several optional sub options, defined
in Section 4.4.
]]></artwork>
</figure>
</section>
<section title="Sub Options for MAP Rule Option">
<t/>
<section title="Rule-IPv6-Prefix Sub Option">
<t>The Rule-IPv6-Prefix Sub Option is necessary for every MAP Rule
option. It should appear for once and only once.</t>
<t>The IPv6 Prefix sub option is followed the framed IPv6 prefix
designed in <xref target="RFC3162"/>. <figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | Reserved | prefix6-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| rule-ipv6-prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
1 (SubType number, for the Rule-IPv6-Prefix6 sub option)
SubLen
20 (the length of the Rule-IPv6-Prefix6 sub option)
Reserved
Reserved for future usage. It should be set to all zero.
prefix6-len
length of the IPv6 prefix, specified in the rule-ipv6-prefix
field, expressed in bits
rule-ipv6-prefix
a 128-bits field that specifies an IPv6 prefix that appears in
a MAP rule
]]></artwork>
</figure></t>
</section>
<section title="Rule-IPv4-Prefix Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | Reserved | prefix4-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
2 (SubType number, for the Rule-IPv4-Prefix6 sub option)
SubLen
8 (the length of the Rule-IPv4-Prefix6 sub option)
Reserved
Reserved for future usage. It should be set to all zero.
Prefix4-len
length of the IPv6 prefix, specified in the rule-ipv6-prefix
field, expressed in bits
rule-ipv4-prefix
a 32-bits field that specifies an IPv4 prefix that appears in
a MAP rule
]]></artwork>
</figure>
</section>
<section title="EA Length Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | EA-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
3 (SubType number, for the EA Length sub option)
SubLen
4 (the length of the EA Length sub option)
EA-len
16 bits long field that specifies the Embedded-Address (EA)
bit length. Allowed values range from 0 to 48.]]></artwork>
</figure>
</section>
<section title="BR-IPv6-Address Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| BR-ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
4 (SubType number, for the BR-ipv6-address sub option)
SubLen
20 (the length of the BR-ipv6-address sub option)
Reserved
Reserved for future usage. It should be set to all zero.
BR-ipv6-address
a 128-bits field that specifies the IPv6 address for the BR. ]]></artwork>
</figure>
</section>
<section title="PSID Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | PSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
5 (SubType number, for the PSID Sub Option sub option)
SubLen
4 (the length of the PSID Sub Option sub option)
PSID (Port-set ID)
Explicit 16-bit (unsigned word) PSID value. The PSID value
algorithmically identifies a set of ports assigned to a CE. The
first k-bits on the left of this 2-octets field is the PSID
value. The remaining (16-k) bits on the right are padding zeros.
]]></artwork>
</figure>
</section>
<section title="PSID Length Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | PSID-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
6 (SubType number, for the PSID Length sub option)
SubLen
4 (the length of the PSID Length sub option)
PSID-len
Bit length value of the number of significant bits in the PSID
field. (also known as 'k'). When set to 0, the PSID field is to
be ignored. After the first 'a' bits, there are k bits in the
port number representing valid of PSID. Subsequently, the
address sharing ratio would be 2 ^k.
]]></artwork>
</figure>
</section>
<section title="PSID Offset Sub Option">
<figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | SubLen | PSID Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubType
7 (SubType number, for the PSID Offset sub option)
SubLen
4 (the length of the PSID Offset sub option)
PSID Offset
4 bits long field that specifies the numeric value for the MAP
algorithm's excluded port range/offset bits (A-bits), as per
section 5.1.1 in [I-D.ietf-softwire-map]. Default must be set
to 4.
]]></artwork>
</figure>
</section>
</section>
<section title="Table of attributes">
<t>The following table provides a guide to which attributes may be
found in which kinds of packets, and in what quantity.<figure>
<artwork><![CDATA[Request Accept Reject Challenge Accounting # Attribute
Request
0-1 0-1 0 0 0-1 TBD1 MAP-
Configuration
0-1 0-1 0 0 0-1 1 User-Name
0-1 0 0 0 0 2 User-Password
0-1 0-1 0 0 0-1 6 Service-Type
0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator
]]></artwork>
</figure></t>
<t>The following table defines the meaning of the above table
entries.</t>
<figure>
<artwork><![CDATA[0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in
packet.
1 Exactly one instance of this attribute MUST be present in
packet.
]]></artwork>
</figure>
</section>
</section>
<section title="Diameter Considerations">
<t>This attribute is usable within either RADIUS or Diameter <xref
target="RFC6733"/>. Since the Attributes defined in this document will
be allocated from the standard RADIUS type space, no special handling is
required by Diameter entities.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requires the assignment of two new RADIUS Attributes
Types in the "Radius Types" registry (currently located at
http://www.iana.org/assignments/radius-types for the following
attributes:<list style="symbols">
<t>MAP-Configuration TBD1</t>
</list></t>
<t>IANA should allocate the numbers from the standard RADIUS Attributes
space using the "IETF Review" policy <xref target="RFC5226"/>.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>In MAP scenarios, both CE and BNG are within a provider network,
which can be considered as a closed network and a lower security threat
environment. A similar consideration can be applied to the RADIUS
message exchange between BNG and the AAA server.</t>
<t>Known security vulnerabilities of the RADIUS protocol are discussed
in <xref target="RFC2607"/>, <xref target="RFC2865"/>, and<xref
target="RFC2869"/>. Use of IPsec <xref target="RFC4301"/> for providing
security when RADIUS is carried in IPv6 is discussed in <xref
target="RFC3162"/>.</t>
<t>A malicious user may use MAC address proofing and/or dictionary
attack on the shared MAP password that has been preconfigured on the
DHCPv6 server to get unauthorized MAP configuration information.</t>
<t>Security considerations for MAP specific between MAP CE and BNG are
discussed in <xref target="I-D.ietf-softwire-map"/>. Furthermore,
generic DHCPv6 security mechanisms can be applied DHCPv6
intercommunication between MAP CE and BNG.</t>
<t>Security considerations for the Diameter protocol are discussed in
<xref target="RFC6733"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the valuable comments made by Peter
Lothberg, Wojciech Dec, and Suresh Krishnan for this document.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2865'?>
<?rfc include='reference.RFC.3162'?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.3580'?>
<?rfc include='reference.RFC.5080'?>
<?rfc include='reference.RFC.6158'?>
<?rfc include='reference.RFC.6929'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-map-dhcp'?>
<?rfc include='reference.RFC.2607'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.2869'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.6733'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:32 |