Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Intended status: Informational May 10, 2007
Expires: November 11, 2007
The IPvLX Architecture
draft-templin-ipvlx-08.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 11, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IETF has embraced IPv6 as the next-generation Internet protocol,
but global IPv4 deployment continues in private addressing domains
behind Network Address Translators (NATs). This document envisions a
long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as
identifiers (and sometimes also locators) and IPv4 addresses serving
as locators (and sometimes also identifiers). This document proposes
an architectural framework for IPv6/IPv4 coexistence called: "IPvLX
(IP with virtual Link Extension)".
Templin Expires November 11, 2007 [Page 1]
Internet-Draft IPvLX May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abbreviations and Conventions . . . . . . . . . . . . . . . . 5
4. Routing and Addressing Assumptions . . . . . . . . . . . . . . 6
5. DNS Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
6. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 7
7. Virtual Link Extension . . . . . . . . . . . . . . . . . . . . 8
7.1. Mapping and VL Establishment . . . . . . . . . . . . . . . 8
7.1.1. Forward Mapping . . . . . . . . . . . . . . . . . . . 8
7.1.2. Reverse Mapping . . . . . . . . . . . . . . . . . . . 9
7.1.3. VL Confidentiality using IKE and IPSec . . . . . . . . 10
7.1.4. Referrals . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Encapsulation and Link Adaptation . . . . . . . . . . . . 11
7.2.1. IPvLX Encapsulation . . . . . . . . . . . . . . . . . 11
7.2.2. IPvLX Interface MTU and IPvLX Link Adaptation . . . . 12
7.2.3. IPv6 Fragmentation and Reassembly . . . . . . . . . . 12
7.2.4. Header Compression . . . . . . . . . . . . . . . . . . 12
7.3. Virtual Link Traversal . . . . . . . . . . . . . . . . . . 13
7.3.1. From the ITR to the Target EBR . . . . . . . . . . . . 13
7.3.2. From the Target EBR to the ETR . . . . . . . . . . . . 13
7.4. MPLS Label Switching . . . . . . . . . . . . . . . . . . . 14
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. IPv4 Backward Compatibility . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. Appendix A: Other Encapsulation Alternatives . . . . . . . . . 16
15. Appendix B: Comparison with Teredo . . . . . . . . . . . . . . 16
16. Appendix C: Changes . . . . . . . . . . . . . . . . . . . . . 17
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Templin Expires November 11, 2007 [Page 2]
Internet-Draft IPvLX May 2007
1. Introduction
The IPv6 128-bit addressing architecture was designed as a solution
for the 32-bit limitation of IPv4 and offers the promise of scalable
addressing. But the proliferation of IPv4 in the global Internet
continues via private addressing domains behind Network Address
Translators (NATs) [RFC1918][RFC2993]. This document therefore
envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses
serving as identifiers (and sometimes also locators) and IPv4
addresses serving as locators (and sometimes also identifiers).
It is well known that IP addresses have heretofore embodied both the
identity and (topological) location of an end system (or, to be more
precise, an end system interface). But, a growing consensus in the
modern literature has postulated an "identity/locator split" in which
identity and location are maintained in separate addressing entities.
This document proposes a natural identity/locator split methodology
by treating IPv6 addresses as end system interface identifiers and
IPv4 addresses as routing locators in a manifestation of the "map-
and-encaps" architectural framework [RFC1955].
This document proposes an architectural framework for IPv6/IPv4
coexistence known as: "IPvLX (IP with virtual Link eXtension)" with
goals of limiting core routing table growth while supporting scaling
to arbitrarily large numbers of end systems and restoring global
Internet transparency. The scheme uses IPv6 for end system interface
identification and simple network middleboxes to extend virtual links
(VLs) across one or more IPv4 networks.
This document is being published to capture a stable snapshot of a
next-generation Internet architecture proposal, and to provide
operational insight into a widely-deployed IPv6 transition mechanism
known as "teredo" [RFC4380]. Similar proposals appear in
[RFC1955][RFC1992][RFC3056][I-D.wang-ietf-efit][I-D.farinacci-lisp].
2. Terminology
The terminology of [RFC2460][RFC2461][RFC4214][I-D.farinacci-lisp][I-
D.ietf-autoconf-manetarch] applies; the following terms are
(re)defined within the scope of this document:
site
the terms "site" and "MANET" are used synonymously throughout this
document. Traditional literature commonly uses the term "site" to
refer to relatively fixed networks (e.g., the wired links of a
campus LAN), but such "static" networks are really only a special
case of a MANET. Sites connect to other networks via IPvLX nodes
Templin Expires November 11, 2007 [Page 3]
Internet-Draft IPvLX May 2007
that act as site border routers (SBRs).
Mobile Ad-hoc Network (MANET)
a set of links that may have asymmetric reachability
characteristics (see: [RFC2461], Section 2.2) and are connected by
IPvLX nodes (acting as MANET routers) that maintain a routing
structure among themselves. A MANET may be as large as an
enterprise or as small as an individual site, and may also be a
subnetwork of a larger site. An IPvLX node and its downstream-
attached links is a "site" unto itself, and a MANET is therefore a
"site-of-sites".
enterprise
a connected set of MANETs/sites that connects to the global
Internet via IPvLX nodes configured as enterprise border routers
(EBRs). An enterprise is normally represented as a single
Autonomous System (AS).
virtual link (VL)
a path over which IPv6 packets are forwarded between IPvLX nodes
acting as an ingress tunnel router (ITR) and egress tunnel router
(ETR) across potentially many IPv4 networks without the Hop Limit
field in the IPv6 header being decremented.
IP with virtual Link eXtension (IPvLX)
an architectural framework of mechanisms and operational practices
used by IPvLX nodes to extend VLs between sites.
IPvLX node
an ISATAP node ([RFC4214], Section 3) that also acts as a MANET
router and supports IPvLX. IPvLX nodes serve as IPv6 routers for
their own internal virtual interfaces and physical or virtual
interfaces of devices on downstream-attached links.
IPvLX interface
an IPvLX node's virtual interface that sends and receives IPv6
packets using IPvLX link adaptation and encapsulation.
Templin Expires November 11, 2007 [Page 4]
Internet-Draft IPvLX May 2007
IPvLX link adaptation
a Sub-IP layer mechanism specified in [I-D.templin-linkadapt] that
splits IPv6 packets into chains of segments that are no larger
than the path MTU of the VL.
IPvLX encapsulation
a method used by an ITR to encapsulate the packet segments created
by link adaptation in an IPvLX Flow Header and IPv4 header for
transmission on an IPv4 interface and later reassembly during
decapsulation by an ETR.
IPvLX Flow Header
a header that is inserted between the IPv6 packet segment and the
20-byte IPv4 header in IPvLX packets.
IPvLX Flow Identifier
a value encoded in the IPvLX Flow Header that identifies a flow
and may be modified by IPvLX nodes on the path.
IPvLX Flow (or simply: "flow")
a unidirectional stream of IPvLX encapsulated packets identified
by a tuple consisting of an IPvLX Flow identifier, and IPv4
source/destination addresses encoded the header of each IPvLX
encapsulated packet.
3. Abbreviations and Conventions
With reference to Section 2, IPvLX nodes are referred to by one or
more of the following abbreviations (depending on their operational
orientation) throughout the document:
SBR (Site Border Router) - an IPvLX node that connects a site to
other networks
EBR (Enterprise Border Router) - an IPvLX node that connects an
enterprise to the global Internet
ITR (Ingress Tunnel Router) - an IPvLX node that encapsulates
packets for transmission over a VL
ETR (Egress Tunnel Router) - an IPvLX node that decapsulates
packets that arrive on a VL
Templin Expires November 11, 2007 [Page 5]
Internet-Draft IPvLX May 2007
Additionally, an IPvLX node has physical interfaces that attach to
networks that provide transit to the global Internet, and physical or
virtual interfaces that attach to stub networks for which they are
SBRs. The convention adopted by this document is to refer to the
former as "upstream" interfaces and the latter as "downstream"
interfaces.
4. Routing and Addressing Assumptions
IPv4 addresses in the current Internet combine both identifier and
locator attributes; they are typically assigned to interfaces and
provide both an identity for the end system and a routable entity
that routing can use for packet forwarding decisions. IPvLX assumes
that IPv6 addresses need only be treated as identifiers on a global
basis (not as locators), but that they may also be routable within a
limited topology such as an end site. As for IPv4 addresses, IPv6
addresses are assigned to physical or virtual interfaces.
Each IPvLX node includes an IPv6 router entity that provides a nexus
for forwarding packets on behalf of local IPv6 addresses as well as
for IPv6 addresses that reside within sites for which the IPvLX node
serves as a SBR. IPvLX nodes can therefore serve as both network
middleboxes and end systems. The IPv6 router entity of an IPvLX node
terminates VLs instead of providing transit for the link as a bridge
would do, therefore IPv6 routers occur at the near and far end IPvLX
nodes of all VLs as the logical points of termination. The near and
far end of a VL are known throughout this document as the Ingress
Tunnel Router (ITR) and Egress Tunnel Router (ETR), respectively.
5. DNS Assumptions
The global DNS [RFC1035] today maintains resource records for Fully
Qualified Domain Names (FQDNs) with global IPv4 addresses for
traditional Internet services, and by design anticipates that their
FQDN-to-address mappings will change relatively infrequently. IPvLX
asks only that the global DNS also maintain resource records for
addresses of ETRs - again, under the assumption that those FQDN-to-
address mappings will change infrequently.
IPvLX further assumes a DNS-like "site-local" name resolution service
(e.g., LLMNR [RFC4795]) that is separate from the global DNS and
records the FQDN-to-IPv6-address mappings for IPv6 application
endpoints within a site. Unlike the global DNS, IPvLX nodes assume
that the FQDN-to-IPv6-address mappings within the site local name
service may change dynamically as IPv6 application endpoints come
into existence, move to new locations and terminate.
Templin Expires November 11, 2007 [Page 6]
Internet-Draft IPvLX May 2007
Given these assumptions, the global DNS provides IPvLX nodes with a
means for determining the next IPv6 hop toward the final destination
(i.e., the ETR). In particular, for a destination FQDN:
"peer.example.com", IPvLX nodes assume that the name of the ETR is
formed by concatenating the well-known prefix "isatap" with the FQDN
suffix, e.g., "isatap.example.com" [RFC4214]. Following next-hop
resolution, the address of the final destination can be determined by
consulting the next-hop's site-specific local name resolution
service.
6. Autoconfiguration
IPvLX nodes serve as SBRs through which all packets entering or
leaving the site must pass. At startup time, or when moving to a new
link, IPvLX nodes should automatically discover (e.g., via DHCP) an
IPv4 address and domain name associated with at least one upstream
interface. They should then discover SBRs on upstream interfaces by
resolving the FQDN "isatap.example.com" within each upstream site's
name service and sending IPv6-in-IPv4 encapsulated Router
Solicitations (RSs) to elicit Router Advertisements (RAs) as
specified in [RFC4214]. They should also configure supporting
services (e.g., DHCP [RFC2131][RFC3315][RFC3633], DNS server, etc.)
and advertise themselves for discovery by nodes on downstream
interfaces by configuring an entry for themselves in the downstream
site's ISATAP Potential Router List (PRL).
IPvLX nodes also serve as SBRs for sites connected on their
downstream interfaces to enable recursively-nested sites-within-sites
("it's turtles all the way down" [RFC1992]). IPvLX nodes that do not
receive IPv6 address assignments and/or prefix delegations through an
autoconfiguration mechanism should configure unique local addresses
[RFC4193]. They can then (optionally) downstream-delegate portions
of those prefixes to other IPvLX nodes and/or advertise them for
stateless address autoconfiguration on attached IPv6 devices.
IPvLX nodes should register themselves as potential ETRs via secure,
dynamic updates to the global DNS [RFC2136][RFC4033]. The names
should be formed from concatenating the prefix "isatap" and a FQDN
suffix for one of the IPvLX node's upstream interfaces, e.g.,
"isatap.example.com". The addresses must be ISATAP addresses that
include an IPv6 prefix served by the IPvLX node with an embedded
global IPv4 address of an EBR, and are registered as AAAA records in
the DNS. All IPvLX nodes within a site should respond to local-scope
name-to-IPv6 address resolution requests for the downstream IPv6
endpoints they connect, e.g., via a mechanism such as LLMNR.
IPvLX nodes should provide basic packet forwarding services if
Templin Expires November 11, 2007 [Page 7]
Internet-Draft IPvLX May 2007
possible within constraints such as memory, battery power, RF link
quality, etc. IPvLX nodes that connect to links with asymmetric
reachability characteristics should also engage in a MANET routing
protocol (e.g., [I-D.ietf-manet-dymo][I-D.ietf-manet-olsrv2]) as well
as a distributed site-scoped multicast flooding service (e.g., SMF
[I-D.ietf-manet-smf]).
7. Virtual Link Extension
When an application initiates a connection with a target peer in a
remote site, it resolves a FQDN to get back a set of addresses.
Applications should prefer and use IPv4 addresses whenever they are
available, since packets can be sent directly without using the
virtual link extension mechanisms specified in this section.
When no IPv4 addresses are available, IPv6 addresses must be
discovered and a virtual link (VL) must be established between an ITR
and an ETR before packets can flow (note that an existing VL between
an ITR and ETR may be used if one is already available). Packets can
then be forwarded toward the target peer across the VL (which may
extend across many IPv4 networks) as long as IPvLX nodes in the path
behave as follows:
7.1. Mapping and VL Establishment
Applications resolve FQDNs (e.g., "peer.example.com") via an on-link
IPvLX node that acts as both a (default) router and a DNS server on
that link, but also acts as an ordinary DNS recursive resolver on an
upstream interface. The IPvLX node resolves the FQDN locally as a
server if possible; otherwise, it resolves the FQDN as a client of an
upstream DNS server. If the name resolution returns A records with
IPv4 addresses, the application can connect directly to the peer
using IPv4 instead of IPv6. Otherwise, the following mapping and VL
establishment operations are performed:
7.1.1. Forward Mapping
If no A records for the FQDN are returned when the IPvLX node
attempts to resolve the FQDN "peer.example.com", it next tries to
discover an ETR for the target by resolving the FQDN
"isatap.example.com". If the DNS returns a set of AAAA records, the
IPvLX node considers them as ISATAP addresses with an IPv6 prefix
corresponding to the ETR and an IPv4 address corresponding to an EBR
for the ETR's enterprise embedded in the interface identifier. It
then creates IPv6 routing table entries for the /64 prefixes carried
in the ISATAP addresses. Each routing table entry points to the VL
and has as its next hop a link-local ISATAP address that embeds an
Templin Expires November 11, 2007 [Page 8]
Internet-Draft IPvLX May 2007
IPv4 address of an EBR, i.e., so that the unidirectional forward VL
toward the ETR is established.
Next, the IPvLX node (acting as an ITR) prepares an IPvLX-
encapsulated (see: Section 7.2) IPv6 Node Information Query (NI
Query) [RFC4620] to be sent to the ETR. The body of the message
includes an ICMP Type 139 (NI Query), Code 1 (Data field contains
name), Qtype 3 (Node Addresses), Flags set to TBD to indicate Unique
Local Addresses, an appropriate Nonce value, and the FQDN
"peer.example.com" in the data field. The following addresses are
included in the IPv6 and IPv4 headers:
o in the IPv6 source address, an IPv6 address assigned to an
interface of the ITR that is connected to the same link as the
application
o in the IPv6 destination address, the ISATAP address for the ETR as
returned by the DNS
o in the IPv4 source address, the same as for ([RFC4213], Section
3.5)
o in the IPv4 destination address, the global IPv4 address embedded
in the ISATAP address
The ITR then sends the IPvLX-encapsulated NI Query using IPv4 routing
based on the IPv4 destination address, which will direct the query to
an EBR for the peer's enterprise.
7.1.2. Reverse Mapping
When an ITR's NI Query arrives at an EBR, IPvLX nodes on the path to
the ETR use IPv6 routing within the peer's site based on the
destination address in the encapsulated IPv6 header, which will
direct the query to the ETR. When the ETR receives the NI Query, it
resolves the FQDN "peer.example.com" in its site-local name
resolution service (e.g., LLMNR) to obtain a set of AAAA records. It
then creates an IPv6 routing table entry for the /64 prefix carried
in the NI Query IPv6 source address that points to the VL and has as
its next hop a link-local ISATAP address that embeds the NI Query's
IPv4 source address, i.e., so that the unidirectional reverse VL
toward the ITR is established without the need for an explicit
reverse mapping.
Templin Expires November 11, 2007 [Page 9]
Internet-Draft IPvLX May 2007
Next, the ETR returns an IPvLX encapsulated (see: Section 7.2) IPv6
Node Information Query reply (NI Reply) to the ITR. The message
should include an ICMP Type 140 (NI Reply), Code 0 (indicates
successful reply), Qtype 3 (Node Addresses), Flags set to TBD to
indicate Unique Local Addresses, the Nonce value that was supplied in
the NI Query, and a set of zero or more IPv6 addresses in the data
field that were returned in the AAAA records from the site-local name
resolution of "peer.example.com". The following addresses are
included in the IPv6 and IPv4 headers:
o in the IPv6 source address, the IPv6 destination address from the
NI Query
o in the IPv6 destination address, the IPv6 source address from the
NI Query
o in the IPv4 source address, the same as for ([RFC4213], Section
3.5)
o in the IPv4 destination address, the IPv4 source address from the
NI Query
When the ITR receives the NI Reply with IPv6 addresses, it wraps the
IPv6 addresses in DNS AAAA resource records and returns them to the
application as though it were responding as an ordinary DNS server.
7.1.3. VL Confidentiality using IKE and IPSec
Following the forward and reverse mapping and VL establishment phases
described above, the ITR and ETR can optionally perform an IKE
exchange to establish IPSec security associations as described in
"Using IPSec to Secure IPv6-in-IPv4 Tunnels"
[I-D.ietf-v6ops-ipsec-tunnels].
7.1.4. Referrals
Some applications rely on referrals in which a broker informs a
correspondent node of a third party to contact. When such referrals
include an FQDN for the third party, mapping and VL establishment are
performed exactly as in the above subsections.
It is FFS whether referrals that include an IP address for the third
party (instead of a FQDN) can be easily accommodated.
Templin Expires November 11, 2007 [Page 10]
Internet-Draft IPvLX May 2007
7.2. Encapsulation and Link Adaptation
7.2.1. IPvLX Encapsulation
As for ordinary IPv4 NATs, IPvLX nodes determine the IPv4 addressing
plans for their downstream-attached sites, which may include IPvLX
nodes that in turn determine the IPv4 addressing plans in child
sites. Since these recursively-nested IPv4 addressing plans may be
topologically disjoint, IPvLX nodes must rewrite certain packet
header fields to relay/proxy the packets they forward between sites.
To support this header rewriting, IPvLX nodes use a special form of
encapsulation ("IPvLX encapsulation") that encapsulates IPv6 packets
in IPv4 datagrams as for standard IPv6-in-IPv4 encapsulation
[RFC4213] except that an IPvLX flow header is inserted between the
IPv4 header and the IPv6 header. The IPvLX flow header provides a
virtual circuit identifier that labels the flow, and forwarding
capabilities between labeled waypoints via an optional MPLS Label
Stack [RFC3031][RFC3032] as shown below:
+-------------------------------+
| |
~ IPv6 Packet (variable length) ~
| |
+-------------------------------+
| |
~ MPLS Label Stack (variable ~
| length; multiples of 4 bytes) |
+-------------------------------+
| IPvLX Flow Header (4/8 bytes) |
+-------------------------------+
| |
| IPv4 Header (20 bytes) |
| |
+-------------------------------+
IPvLX Packet Format
When an IPvLX node sends/forwards/receives an IPvLX encapsulated
packet, it treats the IPvLX Flow Identifier in the flow header as a
Virtual Circuit (VC) number similar to that used for ATM [RFC2492].
The Flow Identifier is initialized by the ITR, and may be modified by
intermediate IPvLX nodes on the path. Additionally, an MPLS label
stack may be inserted by the ITR and may be modified by intermediate
IPvLX nodes on the path.
The IPvLX Flow Header is sufficiently similar to an MPLS label stack
entry [RFC3032] in terms of size and configuration such that it would
Templin Expires November 11, 2007 [Page 11]
Internet-Draft IPvLX May 2007
be desirable to engineer it as part of the MPLS label stack instead
of as a separately defined entity, e.g., by specifying a spare bit in
the MPLS label stack entry to indicate: "IPvLX Flow Header". In that
case, the Protocol field in the IPv4 header could be set to the IP
protocol number assigned for MPLS encapsulation in IP [RFC4023].
Other IPvLX Flow Header encapsulation alternatives are discussed in
Appendix A, and a comparison of IPvLX with Teredo [RFC4380] is given
in Appendix B.
7.2.2. IPvLX Interface MTU and IPvLX Link Adaptation
All IPv6 interfaces are required to support the IPv6 minimum MTU of
1280 bytes (and should support larger MTUs if possible) while all
IPv4 interfaces should avoid unnecessary fragmentation in the IPv4
Internet [FRAG]. IPvLX interfaces therefore use the link adaptation
scheme specified in [I-D.templin-linkadapt] (which is similar to both
ATM Adaptation Layer 5 [RFC2684] and IEEE 802.11 MAC Sublayer
Fragmentation [WLAN]) to segment IPvLX-encapsulated IPv6 packets into
chains of IPv4 packets no larger than the IPv4 path MTU.
7.2.3. IPv6 Fragmentation and Reassembly
IPv6 endpoints can use host-based IPv6 fragmentation (e.g., by
setting the "USE_MINIMUM_MTU" socket option [RFC3542]) to avoid
ICMPv6 "packet too big" messages. Since IPvLX link adaptation
provides an edge-to-edge checksum [I-D.templin-linkadapt], IPv6
reassembly implementations can provide improved robustness and
efficiency (e.g., for applications that use UDP-Lite [RFC3828]) by
replacing any missing IPv6 fragments with replicated data from IPv6
fragments received in valid IPvLX packet chains rather than
discarding the entire packet.
7.2.4. Header Compression
The initial packet for a flow must include a full IPv6 header
([RFC2460], Section 3) to allow IPvLX nodes along the path to the
destination to initialize flow state. Subsequent packets in the flow
may omit the IPv6 header and instead encode the same protocol value
that would have appeared in the IPv6 "Next Header" field in the IPvLX
Flow Header.
IPvLX encapsulated IPv6 neighbor discovery messages must not omit the
IPv6 header.
Compression methods for additional upper-layer protocol headers
and/or IPv6 options beyond the IPv6 header are out of scope, but may
be specified in other documents.
Templin Expires November 11, 2007 [Page 12]
Internet-Draft IPvLX May 2007
7.3. Virtual Link Traversal
7.3.1. From the ITR to the Target EBR
When an intermediate IPvLX node along the path from the ITR to the
target's EBR receives an IPvLX packet for a new IPvLX Flow, it
creates a flow state entry with a lifetime value as specified in
[RFC3697]. When it forwards the packet across site boundaries, the
IPvLX node also rewrites the IPvLX packet's IPv4 source address with
an address selected as for ([RFC4213], Section 3.5) and rewrites the
Flow Identifier (FI) to a unique value for the new IPv4 source and
original IPv4 destination addresses. (The IPv4 header checksum is
also recalculated and rewritten, but the IPv4 destination address is
not rewritten since it already provides the topologically-correct
address necessary to direct the packet toward the target EBR.)
Intermediate IPvLX node flow state entries store the mapping from:
(FI(in), IPv4_src(in), IPv4_dst(in)) to: (FI(out), IPv4_src(out),
IPv4_dst(out)) during a flow's lifetime. They use the mapping to
forward both non-initial packets and ICMPv4 error messages (see:
Section 8) for the flow. (Note that this flow state is analogous to
the session state maintained by IPv4 NATs.)
The ITR stores the flow identification information along with the
IPv6 source and destination addresses to identify the flow's
endpoints.
7.3.2. From the Target EBR to the ETR
For the initial IPvLX packets for an IPvLX Flow that arrive at an
EBR, each intermediate IPvLX node along the path toward the ETR
should examine the encapsulated IPv6 packet headers and use some form
of static/dynamic IPv6 route discovery to determine the next hop
IPvLX node among those connected on downstream links. (Possible
route discovery mechanisms include static prefix delegations, routes
learned via dynamic routing protocols, etc.) Intermediate IPvLX
nodes should not decapsulate the packet (unless they are configured
to act as an IPv6 router for this particular IPvLX Flow), but instead
relay the packet to the next hop IPvLX node via IPv4, leaving the
"Hop Limit" field in the IPv6 header unchanged. The ETR is the last
hop IPvLX node in the path, which decapsulates the packet and may
also perform firewall/filtering functions.
To support this relaying, when an intermediate IPvLX node along the
path from the EBR to the ETR receives an IPvLX packet for a new IPvLX
Flow, it creates a flow state entry with a lifetime value as
specified in [RFC3697]. When it forwards the packet across site
boundaries, the IPvLX node also rewrites the IPv4 destination address
Templin Expires November 11, 2007 [Page 13]
Internet-Draft IPvLX May 2007
to the IPv4 address of the next hop IPvLX node, rewrites the IPvLX
packet's IPv4 source address with an address selected as for
([RFC4213], Section 3.5), and rewrites the Flow Identifier (FI) to a
unique value for the new IPv4 source and destination addresses. (The
IPv4 header checksum is also recalculated and rewritten.)
Intermediate IPvLX node flow state entries store the mapping from:
(FI(in), IPv4_src(in), IPv4_dst(in)) to: (FI(out), IPv4_src(out),
IPv4_dst(out)) during a flow's lifetime. They use the mapping to
forward both non-initial packets and ICMPv4 error messages (see:
Section 8) for the flow. (Note that this flow state is analogous to
the session state maintained by IPv4 NATs.)
The ETR stores the IPvLX Flow identification information along with
the IPv6 source and destination addresses to identify the flow's
endpoints.
7.4. MPLS Label Switching
IPvLX nodes forward IPvLX packets to the next-hop Label Switching
Router (LSR) [RFC3031] within the MPLS Domain as told by the MPLS
label stack carried in each packet. In the case of IPvLX Flows that
span the global IPv4 Internet, the MPLS domain could include the
entire IPv4 Internet and the MPLS label stack could be used to direct
the order of autonomous systems the packet will traverse en-route to
the enterprise containing the final destination.
8. Error Handling
IPvLX nodes may receive valid ICMPv4 messages that include an outer
IPv4 header with the IPv4 source address of the IPv4 node reporting
the error, an inner IPv4 header from the IPvLX packet-in-error, and
at least the first 8 bytes of the encapsulated IPv6 packet segment
including the IPvLX flow header. The intermediate node must arrange
for the error message to be directed toward the ITR that originated
the packet-in-error. However, it may not always be possible to walk
the chain of previous-hop IPvLX nodes backward from a point in the
middle of a VL, e.g., when a stack of MPLS labels was used to steer
the packet through a number of intermediate waypoints.
Since reverse path forwarding from within the (unidirectional) VL is
not always possible, an intermediate IPvLX node must encapsulate the
ICMPv4 message within IPvLX and send it forward toward the ETR. The
ETR must then recognize the ICMPv4 message as an error that occurred
within the VL, and return a suitable error message back to the ITR
(see also: [I-D.templin-linkadapt]).
Templin Expires November 11, 2007 [Page 14]
Internet-Draft IPvLX May 2007
9. Mobility
When an IPvLX node moves to a new site within its home enterprise, it
will receive new IPv4 autoconfiguration information and discover new
upstream SBRs. But, it should be able to retain its IPv6 address/
prefix delegations such that localized mobility management is handled
seamlessly by network-based mechanisms (e.g., a routing protocol)
within the enterprise. When an IPvLX node moves to a different
enterprise, however, it must inform a rendezvous server in its home
enterprise of the move, since the DNS service cannot be updated on
the granularity of node mobility. For Mobile IPv6 [RFC3775], a
rendezvous server capability is manifested by the MIPv6 Home Agent,
while HIP [RFC4423] defines its own rendezvous server capability.
Rendezvous server capability for IPvLX are FFS.
10. IPv4 Backward Compatibility
In such instances, IPv6 only endpoints may require IPv4 backward-
compatibility services in upstream IPvLX nodes such as [DSTM].
11. IANA Considerations
This document introduces no IANA Considerations.
12. Security Considerations
IPvLX nodes use the securing mechanisms for IPv6 nodes found in
([RFC4294], Section 8).
IPvLX sites need Network Architecture Protection [I-D.ietf-v6ops-nap]
to protect people and assets from harmful communications. Firewalls
on all IPvLX nodes are therefore needed. These firewalls may be
host-specific (such as when the IPvLX node resides on an end host),
but host-specific firewalls may not be feasible on small devices. In
any case, hosts which are not able to configure host-specific
firewalls must be deployed behind IPvLX nodes that do.
13. Acknowledgments
This work has benefited from helpful discussions with many
colleagues, friends and family; recent discussions in the IETF RAM
and IRTF RRG groups have been particularly helpful.
Templin Expires November 11, 2007 [Page 15]
Internet-Draft IPvLX May 2007
14. Appendix A: Other Encapsulation Alternatives
Another possible construct for use as an IPvLX flow header is an IPv4
option. IPv4 options are variable length, and can accommodate more
than one waypoint (i.e., as for IPv4 strict/loose source and record
route). But, IPv4 options have the disadvantage that the first 16-
bits of the option are consumed by bookkeeping bits that are
essentially "bricks" in the packet's "knapsack" as it traverses the
VL. A more significant disadvantage is that IPv4 options need to be
examined by all IPv4 forwarding nodes in the path, including those in
legacy sections of the infrastructure, which can cause slow path
processing.
UDP/IPv4 encapsulation has the distinct advantage that it works over
unmodified IPv4 NAT boxes. In comparison with the other
alternatives, it has the disadvantage that 6 of the 8 bytes of the
UDP header are "bricks in the knapsack". Also, only 16-bits (the UDP
source port) are available for encoding a Flow Identifier, and
multiple nested UDP encapsulations would be necessary to simulate an
MPLS label stack.
15. Appendix B: Comparison with Teredo
If the UDP encapsulation specified for Teredo [RFC4380] were used
instead of IPvLX encapsulation, the considerations discussed in this
document would apply in a corresponding fashion except that the 16-
bit UDP source port would be used as a per-hop flow designator
instead of the IPvLX flow identifier, and classical IPv4 NATs would
be used instead of IPvLX nodes. As such, this document can in some
sense be viewed as an informational/applicability overview for
Teredo.
Using Teredo, the number of distinct flows that can be supported are
limited due to the 16-bit UDP source port, and recursively nested
sites-within-sites (i.e., recursively-nested NATs) may be somewhat
more difficult to achieve in practice. Still, Teredo provides the
option to support peer-to-peer operation between end systems located
behind legacy NATs in the current IPv4 Internet infrastructure before
true IPvLX nodes become widely deployed.
From an idealistic standpoint, Teredo would seem to offer an
opportunity for large scale incremental deployment. For example,
Microsoft Windows Vista ships with Teredo enabled by default such
that end-to-end operations between IPv6 peers can be supported with
no changes to the network. From a practical standpoint, however,
this places a new security burden on the end systems. The security
would then be limited to the quality of any host-specific firewalls
Templin Expires November 11, 2007 [Page 16]
Internet-Draft IPvLX May 2007
on the end systems, which end users might not know how to configure
or might not even be aware of.
A more pressing concern would be unscrupulous "vendors" concealing a
technology similar to Teredo (e.g., in a routine patch distribution)
which opens holes in NATs to expose end-user devices that were
previously hidden due to the opaque nature of the NAT's private IPv4
addressing domain. This could allow the unscrupulous vendors to do
harmful things such as locate end-users, take control of end-users
devices, turn off end-users devices, etc.
In light of the above, the Teredo specification provides the
necessary contribution of sensitizing the community to the false
sense of security afforded by IPv4 NATs and underscores the need for
Network Architecture Protection [I-D.ietf-v6ops-nap] in IPv6 end
systems and networks. This is particularly true now that Teredo is
shipping as on-by-default in widely-deployed implementations.
16. Appendix C: Changes
(Note to RFC Editor - please delete this section before publication
as an RFC.)
Changes since -07:
o Rephrased as an architecture document (as oposed to specification)
o Defined scope in Introduction
o Updated acknowledgements
Changes since -06:
o Simplified and clarified text by introducing ITR/ETR/EBR/SBR
terminology
o Replaced RS/RA mapping mechanism with NI Query/Reply
o introduced identifier/locator split terminology
o numerous other clarifications/updates
Changes since -04, -05:
o updated references
Changes since -03:
Templin Expires November 11, 2007 [Page 17]
Internet-Draft IPvLX May 2007
o minor wording changes in Addressing, DNS and Autoconfiguration
sections
o simplified sections on encapsulation and link adaptation
o minor wording changes in appendix B
17. References
17.1. Normative References
[I-D.templin-linkadapt]
Templin, F., "Link Adaptation for IPv6-in-(foo)-in-IPv4
Tunnels", draft-templin-linkadapt-05 (work in progress),
May 2007.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005.
17.2. Informative References
[DSTM] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
(DSTM)", draft-bound-dstm-exp (work in progress),
October 2005.
[FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful,
In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology.", August 1987.
[I-D.farinacci-lisp]
Templin Expires November 11, 2007 [Page 18]
Internet-Draft IPvLX May 2007
Farinacci, D., "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-00 (work in progress), January 2007.
[I-D.ietf-autoconf-manetarch]
Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-ietf-autoconf-manetarch-01 (work in progress),
March 2007.
[I-D.ietf-manet-dymo]
Perkins, C. and I. Chakeres, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-09 (work in
progress), May 2007.
[I-D.ietf-manet-olsrv2]
Clausen, T., "The Optimized Link State Routing Protocol
version 2", draft-ietf-manet-olsrv2-03 (work in progress),
March 2007.
[I-D.ietf-manet-smf]
Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-04 (work in progress), March 2007.
[I-D.ietf-v6ops-ipsec-tunnels]
Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
draft-ietf-v6ops-ipsec-tunnels-05 (work in progress),
January 2007.
[I-D.ietf-v6ops-nap]
Velde, G., "Local Network Protection for IPv6",
draft-ietf-v6ops-nap-06 (work in progress), January 2007.
[I-D.wang-ietf-efit]
Massey, D., "A Proposal for Scalable Internet Routing &
Addressing", draft-wang-ietf-efit-00 (work in progress),
February 2007.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The
Nimrod Routing Architecture", RFC 1992, August 1996.
Templin Expires November 11, 2007 [Page 19]
Internet-Draft IPvLX May 2007
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
Templin Expires November 11, 2007 [Page 20]
Internet-Draft IPvLX May 2007
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", RFC 4620, August 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007.
[WLAN] Society, I., "Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications, IEEE
Computer Society, ANSI/IEEE 802.11, 1999 Edition.".
Author's Address
Fred L. Templin (editor)
Boeing Phantom Works
P.O. Box 3707
Seattle, WA 98124
USA
Email: fred.l.templin@boeing.com
Templin Expires November 11, 2007 [Page 21]
Internet-Draft IPvLX May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Templin Expires November 11, 2007 [Page 22]