One document matched: draft-templin-isupdate-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<rfc category="std" docName="draft-templin-isupdate-01.txt" ipr="trust200902">
<front>
<title abbrev="Routing Loop Attack">ISATAP Updates</title>
<author fullname="Fred L. Templin" initials="F." surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="5" month="July" year="2011" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Many end user sites in the Internet today still have predominantly
IPv4 internal infrastructures. These sites range in size from small
home/office networks to large corporate enterprise networks, but share
the commonality that IPv4 continues to provide satisfactory internal
routing and addressing services for most applications. As more and more
IPv6-only services are deployed in the Internet, however, end user
devices within such sites will increasingly require at least basic IPv6
functionality for external access. It is also expected that more and
more IPv6-only devices will be deployed within the site over time. This
document therefore discusses updates to the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) to better accommodate these needs.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>End user sites in the Internet today currently use IPv4 routing and
addressing internally for core operating functions such as web browsing,
filesharing, network printing, e-mail, teleconferencing and numerous
other site-internal networking services. Such sites typically have an
abundance of public or private IPv4 addresses for internal networking,
and are separated from the public Internet by firewalls, packet
filtering gateways, proxies, address translators and other site border
demarcation devices. To date, such sites have had little incentive to
enable IPv6 services internally <xref target="RFC1687"></xref>.</t>
<t>End-user sites that currently use IPv4 services internally come in
endless sizes and varieties. For example, a home network behind a
Network Address Translator (NAT) may consist of a single link supporting
a few laptops, printers etc. As a larger example, a small business may
consist of one or a few offices with several networks connecting
considerably larger numbers of computers, routers, handheld devices,
printers, faxes, etc. Moving further up the scale, large banks,
restaurants, major retailers, large corporations, etc. may consist of
hundreds or thousands of branches worldwide that are tied together in a
complex global enterprise network. Additional examples include
personal-area networks, mobile vehicular networks, disaster relief
networks, tactical military networks, and various forms of Mobile Ad-hoc
Networks (MANETs). These cases and more are discussed in RANGERS<xref
target="RFC6139"> </xref>.</t>
<t>With the proliferation of IPv6 devices in the public Internet,
however, existing IPv4 sites will increasingly require a means for
enabling IPv6 services so that hosts within the site can communicate
with IPv6-only correspondents. Such services must be deployable with
minimal configuration, and in a fashion that will not cause disruptions
to existing IPv4 services. The Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP) <xref target="RFC5214"></xref> provides a
simple-to-use service that sites can deploy in the near term to meet
these requirements, as discussed in <xref
target="I-D.templin-v6ops-isops"></xref>. However, the ISATAP base
specification has several fundamental limitations that restrict its
applicability.</t>
<t>For example, the base specification does not allow for
router-to-router tunneling and also does not support DHCPv6-based
address and/or prefix delegation services <xref
target="RFC3315"></xref><xref target="RFC3633"></xref>. The base
specification furthermore does not permit the assignment of non
ISATAP-format addresses of any kind to the ISATAP interface. Finally,
the base specification provides no means for address selection
preference of IPv4 over ISATAP for communications within the same site.
This document therefore specifies updates to the base specification to
address these deficiencies.</t>
</section>
<section title="ISATAP Updates">
<t>The base ISATAP model supports two basic node types - namely,
advertising ISATAP routers and ISATAP hosts. Advertising ISATAP routers
configure their site-facing ISATAP interfaces as advertising router
interfaces (see: <xref target="RFC4861"></xref>, Section 6.2.2). ISATAP
hosts configure their site-facing ISATAP interfaces as simple host
interfaces and also coordinate their autoconfiguration operations with
advertising ISATAP routers.</t>
<t>This document introduces a third node type known as "non-advertising
ISATAP routers". Non-advertising ISATAP routers configure their
site-facing ISATAP interfaces as non-advertising router interfaces and
obtain IPv6 addresses/prefixes via manual or automatic configuration
arrangements with advertising ISATAP routers. Non-advertising ISATAP
routers connect IPv6 networks to the ISATAP link, and can therefore
support a router-to-router tunneling mode not supported under the base
specification.</t>
<t>To support this router-to-router tunneling (and also to support the
assignment of non ISATAP-format addresses on ISATAP interfaces) ISATAP
nodes add an update to the source address verification checks specified
in Section 7.3 of <xref target="RFC5214"></xref>. Namely, the node also
considers the outer IPv4 source address correct for the inner IPv6
source address if:</t>
<t><list style="symbols">
<t>a forwarding table entry exists that lists the packet's IPv4
source address as the link-layer address corresponding to the inner
IPv6 source address via the ISATAP interface.</t>
</list></t>
<t>The base ISATAP model further does not specify any IPv6 multicast
mappings. This precludes the use of services such as DHCPv6 which
require a link-scoped IPv6 multicasting service. To support DHCPv6
services, ISATAP hosts and non-advertising ISATAP routers that observe
this specification map the IPv6 "All_DHCP_Relay_Agents_and_Servers"
link-scoped multicast address to the IPv4 address of an advertising
ISATAP router. Advertising ISATAP routers in turn configure a DHCPv6
server or relay function, and accept DHCPv6 messages sent by clients
using this mapping. The advertising router also maintains IPv6
forwarding table entries that list the IPv4 address of the client as the
link-layer address of any delegated IPv6 addresses or prefixes.</t>
<t>Finally, this document updates the address selection policies of the
base specification as follows. For communications between two nodes
whose IPv6 addresses are covered by the same IPv6 prefix advertised in
Router Advertisements (RAs) on an ISATAP interface, prefer IPv4 over
IPv6 if the L bit in the Prefix Information Option (PIO) is set to
0.</t>
<t>Using these updates, a much richer ISATAP service model is made
possible. The following two sections describe the new modes of operation
that are enabled by the updates.</t>
</section>
<section title="DHCPv6 Services">
<t>Whether or not advertising ISATAP routers make stateless IPv6
services available using StateLess Address AutoConfiguration (SLAAC),
they can also provide managed IPv6 services to ISATAP clients (i.e.,
both hosts and non-advertising ISATAP routers) using DHCPv6. Any
addresses/prefixes obtained via DHCPv6 are distinct from any IPv6
prefixes advertised on the ISATAP interface for SLAAC purposes,
however.</t>
<t>The following sections discuss operational considerations for
enabling ISATAP DHCPv6 services within predominantly IPv4 sites.</t>
<section anchor="router-dhcpv6"
title="Advertising ISATAP Router Behavior">
<t>Advertising ISATAP routers that support DHCPv6 services send RA
messages in response to Router Solicitation (RS) messages received on
an advertising ISATAP interface. Advertising ISATAP routers also
configure either a DHCPv6 relay or server function to service DHCPv6
requests received from ISATAP clients.</t>
</section>
<section anchor="host-dhcpv6" title="ISATAP Host Behavior">
<t>ISATAP hosts send RS messages to obtain RA messages from an
advertising ISATAP router. When the DHCPv6 service is available, the
host can acquire IPv6 addresses through the use of DHCPv6 stateful
address autoconfiguration <xref target="RFC3315"></xref> whether or
not IPv6 prefixes for SLAAC are advertised. To acquire addresses, the
host performs standard DHCPv6 exchanges while mapping the IPv6
"All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to
the IPv4 address of an advertising ISATAP router.</t>
<t>After the host receives IPv6 addresses, it assigns them to its
ISATAP interface and forwards any of its outbound IPv6 packets via the
advertising router as a default router. The advertising router in turn
maintains IPv6 forwarding table entries that list the IPv4 address of
the host as the link-layer address of the delegated IPv6 addresses.
Note that IPv6 addresses acquired from DHCPv6 therefore need not be
ISATAP addresses, i.e., even though the addresses are assigned to the
ISATAP interface.</t>
</section>
<section anchor="non-router-dhcpv6"
title="Non-Advertising ISATAP Router Behavior">
<t>Non-advertising ISATAP routers can acquire IPv6 prefixes through
the use of DHCPv6 Prefix Delegation <xref target="RFC3633"></xref> via
an advertising router in the same fashion as described above for
host-based DHCPv6 stateful address autoconfiguration. The advertising
router in turn maintains IPv6 forwarding table entries that list the
IPv4 address of the non-advertising router as the link-layer address
of the next hop toward the delegated IPv6 prefixes.</t>
<t>In many use case scenarios (e.g., small enterprise networks,
MANETs, etc.), advertising and non-advertising ISATAP routers can
engage in a proactive dynamic IPv6 routing protocol (e.g., OSPFv3,
RIPng, etc.) over their ISATAP interfaces so that IPv6
routing/forwarding tables can be populated and standard IPv6
forwarding between ISATAP routers can be used. In other scenarios
(e.g., large enterprise networks, highly mobile MANETs, etc.), this
might be impractical dues to scaling issues. When a proactive dynamic
routing protocol cannot be used, non-advertising ISATAP routers send
RS messages to obtain RA messages from an advertising ISATAP router,
i.e., they act as "hosts" on their non-advertising ISATAP
interfaces.</t>
<t>After the non-advertising ISATAP router acquires IPv6 prefixes, it
can sub-delegate them to routers and links within its attached IPv6
edge networks, then can forward any outbound IPv6 packets coming from
its edge networks via other ISATAP nodes on the link.</t>
</section>
<section anchor="avoidance-fig"
title="Reference Operational Scenario - DHCPv6 Model">
<t><xref target="no-onlink-prefix-fig"></xref> depicts a reference
ISATAP network topology that uses DHCPv6. The scenario shows two
advertising ISATAP routers ('A', 'B'), two non-advertising ISATAP
routers ('C', 'E'), an ISATAP host ('G'), and three ordinary IPv6
hosts ('D', 'F', 'H') in a typical deployment configuration:</t>
<figure anchor="no-onlink-prefix-fig"
title="Reference ISATAP Network Topology using DHCPv6">
<artwork><![CDATA[ .-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host H |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | : fe80::*192.0.2.4
: | 192.0.2.1 | | 192.0.2.1 | ; 2001:db8:2::1
+ +------------+ +------------+ \ +--------------+
fe80::*:192.0.2.1 fe80::*:192.0.2.1 | (isatap) |
| ; | Host G |
: IPv4 Site -+-' +--------------+
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.2 fe80::*:192.0.2.3 .-.
+--------------+ +--------------+ ,-( _)-.
| (isatap) | | (isatap) | .-(_ IPv6 )-.
| Router C | | Router E |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | IPv6 Host F |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host D |
`-(______)-' +-------------+
(* == "5efe")
]]></artwork>
</figure>
<t>In <xref target="no-onlink-prefix-fig"></xref>, advertising ISATAP
routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet
via a companion gateway. (Note that the routers may instead connect to
the IPv6 Internet directly as shown in <xref
target="I-D.templin-v6ops-isops"></xref>.</t>
<t>Advertising ISATAP routers 'A' and 'B' both configure the IPv4
anycast address 192.0.2.1 on a site-interior IPv4 interface, and
configure an advertising ISATAP interface with link-local ISATAP
address fe80::5efe:192.0.2.1. The site administrator then places the
single IPv4 address 192.0.2.1 in the Potential Router List (PRL) for
the site. 'A' and 'B' then both advertise the anycast address/prefix
into the site's IPv4 routing system so that ISATAP clients can locate
the router that is topologically closest. (Note: advertising ISATAP
routers can instead use individual IPv4 unicast addresses instead of a
shared IPv4 anycast address. In that case, the PRL may contain
multiple IPv4 addresses of advertising routers.)</t>
<t>Non-advertising ISATAP router 'C' connects to one or more IPv6 edge
networks and also connects to the site via an IPv4 interface with
address 192.0.2.2, but it does not advertise the site's IPv4 anycast
address/prefix. 'C' next configures a non-advertising ISATAP router
interface with link-local ISATAP address fe80::5efe:192.0.2.2, then
discovers router 'A' via an IPv6-in-IPv4 encapsulated RS/RA exchange.
'C' next receives the IPv6 prefix 2001:db8:0::/48 through a DHCPv6
prefix delegation exchange via 'A', then engages in an IPv6 routing
protocol over its ISATAP interface and announces the delegated IPv6
prefix. 'C' finally sub-delegates the prefix to its attached edge
networks, where IPv6 host 'D' autoconfigures the address
2001:db8:0::1.</t>
<t>Non-advertising ISATAP router 'E' connects to the site, configures
its ISATAP interface, performs an RS/RA exchange, receives a DHCPv6
prefix delegation, and engages in the IPv6 routing protocol the same
as for 'C'. In particular, 'E' configures the IPv4 address 192.0.2.3
and the link-local ISATAP address fe80::5efe:192.0.2.3. 'E' then
receives the delegated IPv6 prefix 2001:db8:1::/48 and sub-delegates
the prefix to its attached edge networks, where IPv6 host 'F'
autoconfigures IPv6 address 2001:db8:1::1.</t>
<t>ISATAP host 'G' connects to the site via an IPv4 interface with
address 192.0.2.4, and also configures an ISATAP host interface with
link-local ISATAP address fe80::5efe:192.0.2.4 over the IPv4
interface. 'G' next performs an anycast RS/RA exchange to discover 'B"
and configure a default IPv6 route with next-hop address
fe80::5efe:192.0.2.1. 'G' then receives the IPv6 address 2001:db8:2::1
from a DHCPv6 address configuration exchange via 'B'; it then assigns
the address to the ISATAP interface but does not assign a
non-link-local IPv6 prefix to the interface.</t>
<t>Finally, IPv6 host 'H' connects to an IPv6 network outside of the
ISATAP domain. 'H' configures its IPv6 interface in a manner specific
to its attached IPv6 link, and autoconfigures the IPv6 address
2001:db8:3::1.</t>
<t>Following this autoconfiguration, when host 'D' has an IPv6 packet
to send to host 'F', it prepares the packet with source address
2001:db8:0::1 and destination address 2001:db8:1::1, then sends the
packet into the edge network where IPv6 forwarding will eventually
convey it to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to
forward the packet to router 'E', since it has discovered a route to
2001:db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP
interface. Router 'E' finally sends the packet into the edge network
where IPv6 forwarding will eventually convey it to host 'F'.</t>
<t>In a second scenario, when 'D' has a packet to send to ISATAP host
'G', it prepares the packet with source address 2001:db8:0::1 and
destination address 2001:db8:2::1, then sends the packet into the edge
network where it will eventually be forwarded to router 'C' the same
as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward the
packet to router 'A' (i.e., 'C's default router), which in turn
forwards the packet to 'G'. Note that this operation entails two hops
across the ISATAP link (i.e., one from 'C' to 'A', and a second from
'A' to 'G'). If 'G' also participates in the dynamic IPv6 routing
protocol, however, 'C' could instead forward the packet directly to
'G' without involving 'A'.</t>
<t>In a third scenario, when 'D' has a packet to send to host 'H' in
the IPv6 Internet, the packet is forwarded to 'C' the same as above.
'C' then forwards the packet to 'A', which forwards the packet into
the IPv6 Internet.</t>
<t>In a final scenario, when 'G' has a packet to send to host 'H' in
the IPv6 Internet, the packet is forwarded directly to 'B', which
forwards the packet into the IPv6 Internet.</t>
</section>
<section title="DHCPv6 Site Administration Guidance">
<t>Site administrators configure advertising ISATAP routers that also
support the DHCPv6 relay/server function to send RA messages with the
M flag set to 1 as an indication to clients that the stateful DHCPv6
address autoconfiguration services area available. If stateless DHCPv6
services are also available, the RA messages also set the O flag to
1.</t>
<t>Gateways and packet filtering devices of various forms are often
deployed in order to divide the site into separate partitions.
Although the purely DHCPv6 model does not involve the advertisement of
non-link-local IPv6 prefixes on ISATAP interfaces, alignment of IPv6
prefixes used for DHCPv6 address assignment with IPv4 site partitions
is still recommended so that ISATAP clients can prefer native IPv4
communications over ISATAP IPv6 services for correspondents within
their contiguous IPv4 partition.</t>
<t>For example, if the site is assigned the aggregate prefix
2001:db8:0::/48, then the site administrators can assign the
more-specific prefixes 2001:db8:0:0::/64, 2001:db8:0:1::/64,
2001:db8:0:2::/64, etc. to the different IPv4 partitions within the
site. The administrators can then institute a policy that prefers
native IPv4 addresses for communications between clients covered by
the same /64 prefix.</t>
<t>Site administrators can implement this policy implicitly by
configuring advertising ISATAP routers to advertise each /64 prefix
with both the A and L flags set to 0 as an indication that IPv4 should
be preferred over IPv6 destinations that configure addresses from the
same prefix. Site administrators can instead (or in addition)
implement address selection policy rules <xref
target="RFC3484"></xref> through explicit configurations in each
ISATAP client.</t>
<t>For example, each ISATAP client associated with the prefix
2001:db8:0:0::/64 can add the prefix to its address selection policy
table with a lower precedence than the prefix ::ffff:0:0/96. In this
way, IPv4 addresses are preferred over IPv6 addresses from within the
same /64 prefix. The prefix could be added to each ISATAP client
either manually, or through an automated service such as a DHCP option
<xref target="I-D.ietf-6man-addr-select-opt"></xref>. In this way,
clients will use IPv4 communications to reach correspondents within
the same IPv4 site partition, and will use IPv6 communications to
reach correspondents in other partitions and/or outside of the
site.</t>
<t>When the PRL includes an anycast address, the client may be
directed to a first DHCPv6 relay/server in initial message exchanges
and to a different relay/server in subsequent exchanges. In order to
address this uncertainty, site administrators should configure DHCPv6
servers to include a Server Unicast option so that clients can remain
associated with the same server that was reached during the initial
exchange. (Alternatively, the administrator could arrange for the
site's DHCPv6 servers to maintain a distributed database of client
bindings.)</t>
<t>Finally, site administrators should configure ISATAP routers to not
send ICMPv6 Redirect messages to inform a source client of a better
next hop toward the destination unless there is strong assurance that
the client and the next hop are within the same IPv4 site
partition.</t>
</section>
<section anchor="predirect" title="On-Demand Dynamic Routing for DHCP">
<t>With respect to the reference operational scenarios depicted in
<xref target="no-onlink-prefix-fig"></xref>, there may be use cases in
which a proactive dynamic IPv6 routing protocol cannot be used. For
example, in large enterprise network deployments it would be
impractical for all ISATAP routers to engage in a common routing
protocol instance due to scaling considerations.</t>
<t>In those cases, an on-demand routing capability can be enabled in
which ISATAP nodes send initial packets via an advertising ISATAP
router and receive redirection messages back. For example, when a
non-advertising ISATAP router 'C' has a packet to send to a host
located behind non-advertising ISATAP router 'E', it can send the
initial packets via advertising router 'A' which will return
redirection messages to inform 'C' that 'E' is a better first hop.
Protocol details for this redirection procedure (including a means for
detecting whether the direct path is usable) are specified in <xref
target="I-D.templin-aero"></xref>.</t>
</section>
<section anchor="loopavoid-dhcp" title="Loop Avoidance">
<t>In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6
prefixes are assigned to ISATAP router interfaces. Therefore, an
ISATAP router cannot mistake another router for an ISATAP host due to
an address that matches an on-link prefix. This corresponds to the
mitigation documented in Section 3.2.4 of <xref
target="I-D.ietf-v6ops-tunnel-loops"></xref>.</t>
<t>Any routing loops introduced in the DHCPv6 scenario would therefore
be due to a misconfiguration in IPv6 routing the same as for any IPv6
router, and hence are out of scope for this document.</t>
</section>
</section>
<section title="Manual Configuration">
<t>In addition to any SLAAC services and DHCPv6 services, when the
updates in this document are employed site administrators can use manual
configuration to assign non-ISATAP IPv6 addresses to the ISATAP
interfaces of client end systems. Site administrators can also use
manual configuration to assign IPv6 prefixes to non-advertising ISATAP
routers instead of (or in addition to) using DHCPv6 prefix
delegation.</t>
<t>The IPv6 prefixes used for manual configuration must be distinct from
any prefixes used for SLAAC, however they may overlap with the prefixes
used for DHCPv6 as long as there is administrative assurance that the
same IPv6 addresses/prefixes will not be delegated by both DHCPv6 and
manual configuration. The manual configuration scenarios and routing
considerations are otherwise the same as discussed for DHCPv6 in Section
4.</t>
<t>When manually configured IPv6 addresses/prefixes are used, the
prefixes must be covered by a shorter IPv6 prefix advertised into the
IPv6 routing system by one or more advertising ISATAP routers. The
advertising routers must further maintain forwarding table entries that
associate the addresses/prefixes with the ISATAP clients to which the
addresses/prefixes are delegated, i.e., the same as for DHCPv6.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>In addition to the security considerations documented in <xref
target="RFC5214"></xref>, sites that use ISATAP should take care to
ensure that no routing loops are enabled <xref
target="I-D.ietf-v6ops-tunnel-loops"></xref>. Additional security
concerns with IP tunneling are documented in <xref
target="RFC6169"></xref>.</t>
</section>
<section anchor="acknowledge" title="Acknowledgments">
<t>The following are acknowledged for their insights that helped shape
this work: Dmitry Anipko, Fred Baker, Brian Carpenter, Remi Despres,
Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel Jaeggli,
John Mann, Gabi Nakibly, Christoper Palmer, Hemant Singh, Mark Smith,
Dave Thaler, Ole Troan, Gunter Van de Velde, ...</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5214"?>
<?rfc ?>
<?rfc include="reference.RFC.4861"?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3633"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6139"?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.1687"?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.6169"?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.3484"?>
<?rfc include="reference.I-D.ietf-v6ops-tunnel-loops"?>
<?rfc include="reference.I-D.ietf-6man-addr-select-opt"?>
<?rfc include="reference.I-D.templin-aero"?>
<?rfc include="reference.I-D.templin-v6ops-isops"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:58:53 |