Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Intended status: Standards Track October 23, 2006
Expires: April 26, 2007
IPvLX - IP with virtual Link eXtension
draft-templin-ipvlx-06.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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The IPv6 128-bit addressing architecture was designed as a successor
for IPv4. But, IPv4 deployment in the global Internet continues via
private addressing domains behind Network Address Translators (NATs)
such that long-term coexistence with IPv6 addressing and minimal
perturbation of IPv4 networks is emerging as the dominant strategy.
This document proposes a long-term IPv6/IPv4 coexistence scheme
called: IPvLX - IP with virtual Link Extension.
Templin Expires April 26, 2007 [Page 1]
Internet-Draft IPvLX October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Addressing and Routing Assumptions . . . . . . . . . . . . . . 5
4. DNS Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 6
6. Encapsulation and Link Adaptation . . . . . . . . . . . . . . 7
6.1. IPvLX Encapsulation . . . . . . . . . . . . . . . . . . . 7
6.2. IPvLX Interface MTU and IPvLX Link Adaptation . . . . . . 9
6.3. IPv6 Fragmentation and Reassembly . . . . . . . . . . . . 9
6.4. Header Compression . . . . . . . . . . . . . . . . . . . . 9
7. Virtual Link Extension . . . . . . . . . . . . . . . . . . . . 9
7.1. Virtual Link Establishment . . . . . . . . . . . . . . . . 10
7.2. Virtual Link Confidentiality . . . . . . . . . . . . . . . 11
7.3. Virtual Link Traversal . . . . . . . . . . . . . . . . . . 12
7.3.1. From the Encapsulator to the Target
Enterprise/Site Border . . . . . . . . . . . . . . . . 12
7.3.2. From the Target Enterprise/Site Border to the
Decapsulator . . . . . . . . . . . . . . . . . . . . . 12
7.4. MPLS Label Switching . . . . . . . . . . . . . . . . . . . 13
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. IPv4 Backward Compatibility . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. Appendix A: Other Encapsulation Alternatives . . . . . . . . . 15
15. Appendix B: Comparison with Teredo . . . . . . . . . . . . . . 15
16. Appendix C: Changes . . . . . . . . . . . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
17.1. Normative References . . . . . . . . . . . . . . . . . . . 17
17.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Templin Expires April 26, 2007 [Page 2]
Internet-Draft IPvLX October 2006
1. Introduction
The IPv6 128-bit addressing architecture was designed as a
replacement solution for the 32-bit limitation of IPv4 and offers the
promise of scalable end to end addressing. But the proliferation of
IPv4 in the global Internet continues via private addressing domains
behind Network Address Translators (NATs) [RFC1918][RFC2993].
Therefore, use of IPv6 for addressing with minimal perturbation of
IPv4 networks is emerging as the dominant long-term transition and
coexistence strategy.
This document proposes IPvLX (IP with virtual Link eXtension) with
goals of fostering growth and restoring global transparency for peer-
to-peer communications. The scheme uses IPv6 for addressing and
simple network middleboxes (which are really just IPv4 NATs with
minor enhancements) to extend secure IP virtual links (VLs) across
one or more IPv4 networks. In this way, IPv6 is seen as an
addressing protocol used to establish and control virtual links while
IPv4 is seen as a link layer (L2) protocol for carrying L3 data
packets.
2. Terminology
The terminology of [RFC4214][RFC2460][RFC2461] applies to this
document. The following additional terms are defined:
logical interface:
the same as defined in ([RFC1122], section 3.3.4.1).
site:
the same as defined in ([RFC4214], section 3).
enterprise:
a network entity that contains one or more sites and has zero or
more border gateways connected to the global IPv4 Internet.
virtual link (VL):
a path over which IPv4-encapsulated L3 packets can be forwarded
between an encapsulating and decapsulating node separated by
potentially many IPv4 networks without the Hop Limit field in the
L3 header being decremented.
Templin Expires April 26, 2007 [Page 3]
Internet-Draft IPvLX October 2006
IP with virtual Link eXtension (IPvLX):
mechanisms and operational practices (described in this document)
used by IPvLX nodes to extend VLs across enterprise/site
boundaries. IPvLX virtual links are edge-to-edge between two
routers, as for VPNs.
IPvLX node:
an ISATAP node ([RFC4214], section 3) that supports IPvLX. IPvLX
nodes also serve as IPv6 routers for co-located IPv6 endpoints and
endpoints on attached IPv6-only links. IPvLX nodes that support
IPv6 endpoints are IPvLX gateways.
IPvLX gateway:
an IPvLX node that provides hybrid routing/bridging/firewalling
capabilities and determines the addressing plans for its
associated hosts. IPvLX gateways occur in exactly the same
topological locations as would an IPv4 NAT, and are really nothing
more than IPv4 NATs with minor enhancements. Enterprise border
IPvLX gateways occur in exactly the same topological locations as
6to4 routers [RFC3056].
associated host:
an IPvLX node or IPv6-only node that associates with a parent
IPvLX gateway. IPvLX nodes that are associated hosts within
parent sites can also serve as IPvLX gateways for their own
associated hosts in child sites.
IPvLX interface:
an IPvLX node's IPv6 interface that transmits Upper Layer Payloads
(ULPs) as chains of IPv4 packets using IPvLX encapsulation and
link adaptation.
IPvLX encapsulation:
a method for encapsulating segments of ULPs over IPv4 as the Layer
2 (L2) protocol.
IPvLX packet:
an IPv4 packet created using IPvLX encapsulation and link
adaptation.
Templin Expires April 26, 2007 [Page 4]
Internet-Draft IPvLX October 2006
(IPvLX) link adaptation:
a link layer mechanism specified in [ADAPT] that segments ULPs
into chains of IPv4 packets for later reassembly during
decapsulation, e.g., to satisfy path MTU restrictions, etc.
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 in each IPvLX packet header.
Each flow provides a logical interface for IPvLX.
IPvLX Flow Identifier:
a value encoded in the IPvLX Flow Header that identifies a flow
and may be modified by IPvLX gateways on the path.
IPvLX Flow Header:
a "Layer 2.5 shim" header immediately following the 20-byte IPv4
header in IPvLX packets.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. Addressing and Routing Assumptions
While IPv4 addresses in the current Internet are typically assigned
to devices, IPvLX assumes that IPv6 addresses will also be assigned
to application endpoints and data objects [NAME]. This new model
would provide greater flexibility such that each end-node might host
many different IPv6 application endpoints and data objects, and that
those entities could migrate to other end-nodes. In this model, each
IPv6 addressable entity would access other endpoints via an IPv6
router.
IPvLX sees IPv6 routers as logical forwarding engines that can reside
within both network middleboxes and end computing devices. They
provide a nexus for forwarding packets on behalf of their own IPv6
addresses as well as for IPv6 addresses that reside within sites for
which they serve as gateways. Even if forwarding occurs between IPv6
addresses within the same physical box, the net effect is still that
of IPv6 routing. IPv6 routers terminate links instead of providing
transit for the link as a bridge would do, therefore IPv6 routers
occur at the near and far end IPvLX gateways of all VLs as the
Templin Expires April 26, 2007 [Page 5]
Internet-Draft IPvLX October 2006
logical points of termination.
4. 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
IPvLX gateways to provide tunnel endpoint addresses - 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]) 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 assumes 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.
Given these assumptions, the global DNS provides IPvLX gateways with
a means for determining the next IPv6 hop toward the final
destination. In particular, for a destination FQDN:
"peer.example.com", IPvLX assumes that the name of the next-hop
toward the destination will be formed by concatenating a well-known
prefix 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.
5. Autoconfiguration
IPvLX gateways provide the border points of reference for forming
enterprise/site networks; they also serve as the border gateways
through which all packets entering or leaving the enterprise/site
must pass. Therefore, at startup time (or when moving to a new link)
interior IPvLX gateways should automatically associate with a parent
IPvLX gateway and automatically discover DNS recursive name servers
on at least one outward-facing interface. They should also configure
supporting services (e.g., DHCPv4 [RFC2131], DHCPv6
[RFC3315][RFC3633][RFC3736], Mobile IPv6 Home Agent [RFC3775], DSTM
border router and server [DSTM], etc.) and advertise themselves for
discovery by associated hosts on inward-facing interfaces, e.g., by
advertising the 6to4 Relay anycast prefix ([RFC3068], section 2.3).
Templin Expires April 26, 2007 [Page 6]
Internet-Draft IPvLX October 2006
IPvLX nodes within an enterprise/site also provide site border
gateways for their own associated hosts on inward-facing interfaces
to enable recursively-nested "sites within sites". IPvLX nodes that
do not receive IPv6 address assignments and/or prefix delegations
through an autoconfiguration mechanism should configure unique local
address prefixes [RFC4193]. They can then (optionally) downstream-
delegate portions of those prefixes to associated IPvLX gateways
and/or advertise them for address autoconfiguration on associated
hosts.
IPvLX gateways that do not move and/or change their addresses
frequently should register name-to-address mappings for themselves
via secure, dynamic updates to the global DNS [RFC2136][RFC4033].
The names should be formed from a well-known prefix and a FQDN suffix
for one of the IPvLX gateway's outward facing interfaces, e.g.,
"isatap.example.com" [RFC4214]. The addresses should include A
records with global IPv4 address(es) of border gateways for the IPvLX
gateway's enterprise, and AAAA records with global IPv6 address(es)
for the IPvLX gateway itself. All IPvLX nodes within an enterprise/
site should respond to local-scope name-to-IPv6 address resolution
requests for the application endpoints they support, e.g., via a
mechanism such as [LLMNR].
IPvLX nodes should provide basic packet forwarding services if
possible within constraints such as memory, battery power, RF link
quality, etc. They should also use efficient dynamic route discovery
protocols, e.g., a hybrid combination of IETF MANET protocols
[RFC3561][RFC3626][RFC3684][DSR][DYMO]. Unification of a hybrid
MANET protocol and efficient flooding mechanism with existing
routing/bridging protocols (e.g., OSPF [RFC2740], IS-IS [RFC1142],
IEEE 802.1D spanning tree [STP], etc.) is currently under
investigation within the IETF community.
6. Encapsulation and Link Adaptation
6.1. IPvLX Encapsulation
As for ordinary IPv4 NATs, IPvLX gateways determine the IPv4
addressing plans for their associated hosts, which can in turn serve
as IPvLX gateways that determine the IPv4 addressing plans for their
own associated hosts in child sites. Since these recursively-nested
IPv4 addressing plans may be topologically disjoint, IPvLX gateways
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 upper layer
Templin Expires April 26, 2007 [Page 7]
Internet-Draft IPvLX October 2006
payloads (ULPs) in IPv4 datagrams as for standard IPv6-in-IPv4
encapsulation [RFC4213] except that an IPvLX flow header (i.e., a
"layer 2.5 shim" header) is inserted between the IPv4 header and the
ULP. 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:
+-------------------------------+ -
| | \
~ ULP Payload (variable length) ~ } Layer 3
| | /
+-------------------------------+ -
| | \
~ MPLS Label Stack (variable ~ |
| length; multiples of 4 bytes) | } Layer 2.5
+-------------------------------+ |
| IPvLX Flow Header (4/8 bytes) | /
+-------------------------------+ -
| | \
| IPv4 Header (20 bytes) | } Layer 2
| | /
+-------------------------------+ -
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 first IPvLX gateway on the
path, and may be modified by intermediate IPvLX gateways on the path.
Additionally, an MPLS label stack may be inserted by the
encapsulating IPvLX node and may be modified by intermediate IPvLX
gateways 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
be desireable 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 layer 2.5 encapsulation alternatives are discussed in Appendix
A and a comparison of IPvLX with TEREDO [RFC4380] is given in
Appendix B.
Templin Expires April 26, 2007 [Page 8]
Internet-Draft IPvLX October 2006
6.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 [ADAPT] (which is similar to both ATM Adaptation
Layer 5 [RFC2684] and IEEE 802.11 MAC Sublayer Fragmentation [WLAN])
to segment ULP payloads into chains of IPvLX packets no larger than
the IPv4 path MTU.
6.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 [ADAPT], 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.
6.4. Header Compression
The initial packet for a flow MUST include a full IPv6 header
([RFC2460], section 3) to allow IPvLX gateways 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 ULP headers and/or IPv6 options
beyond the IPv6 header are out of scope, but MAY be specified in
other documents.
7. Virtual Link Extension
When an IPv6 endpoint initiates a connection with a target peer in a
remote site, a virtual link (VL) must be established between local
and remote IPvLX gateways before packets can flow. The packets can
then be forwarded toward the target peer across a VL extended across
many IPv4 networks as long as IPvLX gateways in the path behave as
follows:
Templin Expires April 26, 2007 [Page 9]
Internet-Draft IPvLX October 2006
7.1. Virtual Link Establishment
IPv6 application endpoints resolve FQDNs such as "peer.example.com"
to obtain one or more IPv6 addresses via a first-hop IPvLX gateway
acting as a recursive resolver. When the first hop IPvLX gateway
resolves the FQDN, it first discovers an IPv6 router for the target
by resolving a tunnel endpoint FQDN, e.g., "isatap.example.com". If
the name service returns a set of AAAA records, the first hop IPvLX
gateway can consider them as ISATAP addresses with an IPv6 prefix
corresponding to the IPv6 router and an IPv4 address corresponding to
the target's enterprise border embedded in the interface identifier.
The first hop IPvLX gateway can then send IPvLX encapsulated IPv6
Router Solicitation messages to contact the IPv6 router with the
following addresses:
o in the IPv6 source address, a Cryptographically Generated Address
(CGA) [RFC3972] with an IPv6 prefix for the initiating IPvLX
gateway
o in the IPv6 destination address, the ISATAP address for the
target's IPv6 router 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 IPvLX encapsulated IPv6 Router Solicitation should include a
Source Link Layer Address Option (SLLAO) ([RFC2461], section 4.6.1)
with an embedded IPv4 unicast address ([RFC2529], section 5)
associated with the solicitor, a Target Link Layer Address Option
(TLLAO) (([RFC2461], section 4.6.1) with an embedded IPv4 unicast
address that matches the IPv4 destination address, and SEND [RFC3971]
parameters for CGA [RFC3972] proof-of-ownership verification.
When the last hop IPvLX gateway before the target that terminates the
VL receives the Router Solicitation, it should first rewrite the IPv4
unicast address embedded in the SLLAO with the IPv4 source address of
the IPvLX encapsulated packet. It can then use SEND mechanisms to
verify address ownership for the initiator. Next, it can send an
IPvLX encapsulated Router Advertisement back toward the solicitor
with the following addresses:
Templin Expires April 26, 2007 [Page 10]
Internet-Draft IPvLX October 2006
o in the IPv6 source address, a CGA [RFC3972] link-local address
o in the IPv6 destination address, the IPv6 source address from the
Router Solicitation
o in the IPv4 source address, the same as for ([RFC4213], section
3.5)
o in the IPv4 destination address, the (rewritten) IPv4 address
embedded in the Router Solicitation's SLLAO, i.e., the link layer
address in the Neighbor Cache
The IPvLX encapsulated IPv6 Router Advertisement should include a
SLLAO with an embedded IPv4 unicast address associated with the
advertiser, a TLLAO with an embedded IPv4 unicast address that
matches the IPv4 destination address, an MTU option ([RFC2461],
section 4.6.4) that encodes the size of the IPvLX gateway's
reassembly buffer, and SEND [RFC3971] parameters for CGA [RFC3972]
proof-of-ownership verification and router certification. It should
also include as many of the target's IPv6 addresses as possible in
Route Information Options [RFC4191].
When the solicitor receives a Router Advertisement, it should first
rewrite the IPv4 unicast address embedded in the SLLAO with the IPv4
source address of the IPvLX encapsulated packet. It can then
discover the address of its own enterprise border by examining the
embedded IPv4 address in the TLLAO and use SEND mechanisms to verify
address ownership and router certificate chains.
Following authorization, the soliciting IPvLX gateway can create IPv6
route cache entries with the link-local ISATAP address constructed
from the IPv4 address in the Router Advertisement's (rewritten) SLLAO
as the next hop toward the target's IPv6 addresses, and return the
addresses to the initiating application endpoint. The application
endpoint can then use IPv6 address selection rules to determine the
best IPv6 source and destination addresses to choose for
communications with the target [RFC3484].
7.2. Virtual Link Confidentiality
During VL establishment, the local and remote IPvLX gateways also
arrange for the confidential exchange of packets across the link.
This requires a key exchange protocol for establishing IPSec security
associations allowing the local IPvLX gateway to encrypt packets sent
Templin Expires April 26, 2007 [Page 11]
Internet-Draft IPvLX October 2006
over the VL and for the remote IPvLX gateway to decrypt them. The
Internet Key Exchange Protocol [RFC4306] is used for this purpose.
7.3. Virtual Link Traversal
7.3.1. From the Encapsulator to the Target Enterprise/Site Border
When an intermediate IPvLX gateway along the path from the
encapsulator to the target's enterprise/site border 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 into a topologically disjoint IPv4 addressing region, the
IPvLX gateway 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 enterprise.)
Intermediate IPvLX gateway 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 6) for the flow. (Note that this flow state is analogous to
the session state maintained by IPv4 NATs.)
The encapsulator 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 Enterprise/Site Border to the Decapsulator
For the initial IPvLX packets for an IPvLX Flow that enter an
enterprise/site, each intermediate IPvLX gateway along the path
toward the decapsulator should examine the encapsulated IPv6 packet
headers and use some form of static/dynamic IPv6 route discovery to
determine the next hop IPvLX gateway among their associated hosts.
(Possible route discovery mechanisms include static prefix
delegations, routes learned via dynamic routing protocols, etc.)
Intermediate IPvLX gateways 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
gateway via IPv4, leaving the "Hop Limit" field in the IPv6 header
unchanged. The last hop IPvLX gateway in the path will be an IPv6
router before the target that decapsulates the packet. Note that the
decapsulating gateway may perform firewall/filtering functions.
Templin Expires April 26, 2007 [Page 12]
Internet-Draft IPvLX October 2006
To support this relaying, when an intermediate IPvLX gateway along
the path from the enterprise/site border to the decapsulator 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 into a topologically disjoint IPv4 addressing region, the
IPvLX gateway also rewrites the IPv4 destination address to the IPv4
address of the next hop IPvLX gateway, 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 gateway 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 6) for the flow. (Note that this flow state is analogous to
the session state maintained by IPv4 NATs.)
The decapsulator 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
For IPvLX packets that include an MPLS label stack, enterprise/site
border gateways make provisions to forward the packet to the Label
Switching Router (LSR) [RFC3031] named at the top of the stack within
the MPLS Domain. 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
Intermediate IPvLX gateways 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
gateway must arrange for the error message to be directed toward the
IPvLX gateway at the head of the VL that originated the packet-in-
error. However, it may not always be possible to walk the chain of
previous-hop IPvLX gateways 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.
Templin Expires April 26, 2007 [Page 13]
Internet-Draft IPvLX October 2006
Since reverse path forwarding from within the VL is not always
possible, the intermediate IPvLX gateway must encapsulate the ICMPv4
message within IPvLX and send it forward toward the IPvLX gateway
that would have decapsulated the packet at the far end of the VL.
The IPvLX gateway at the far end must then recognize the ICMPv4
message as an error that occurred within the virtual link, and return
a suitable error message back to the gateway that originated the
packet-in-error (see also: [ADAPT]).
9. Mobility
When an IPvLX node moves to a different network point of attachment,
it will receive new IPv4 autoconfiguration information and discover a
new parent IPvLX gateway that potentially resides in a different
enterprise. Upon reattachment, the mobile IPvLX node should send
IPv6 Router Solicitation messages using secure neighbor discovery
mechanisms [RFC3971][RFC3972] to its home enterprise border IPvLX
gateway (i.e., its home 6to4 router) to update the router's neighbor
cache and dynamic routing information in any intermediate IPvLX
gateways.
IPv6 nodes can use the features of Mobile IPv6 [RFC3775] to support
movement to foreign enterprises or to different IPv6 prefix regions
within the home enterprise. The Mobile IPv6 home agent function can
be deployed on IPvLX gateways to support associated hosts that have
moved to a different network point of attachment. Whether the
binding update mechanisms of Mobile IPv6, or [ICMPv6] Redirect
messages using secure neighbor discovery mechanisms
[RFC3971][RFC3972] should be used to provide mobile node location
updates to correspondent nodes is FFS.
10. IPv4 Backward Compatibility
For the near term, there will be many instances in which DNS
resolution for FQDNs such as "peer.example.com" will still return
global IPv4 addresses, meaning that the peer can be reached directly
via the global Internet. In such instances, IPv6 endpoints may
require backward-compatibility services in upstream IPvLX gateways
such as [DSTM] and NATPT [RFC2766].
11. IANA Considerations
This document introduces no IANA Considerations.
Templin Expires April 26, 2007 [Page 14]
Internet-Draft IPvLX October 2006
12. Security Considerations
IPvLX gateways and associated hosts use the securing mechanisms for
IPv6 neighbor discovery found in [RFC3971][RFC3972] and the securing
mechanisms for IPv6 nodes found in ([NODEREQ], section 8).
IPvLX sites need Network Architecture Protection [NAP] to protect
people and assets from harmful communications. Firewalls on all
IPvLX gateways are therefore needed. These firewalls may be host-
specific (such as when the IPvLX gateway resides on an end host), but
host-specific firewalls may not be feasible on small devices. In any
case, hosts which are not know to configure host-specific firewalls
MUST be deployed behind IPvLX gateways that do.
13. Acknowledgments
This work documents the mindshare of many contributers. Similar
proposals appear in [NDPROXY][PMTUD][RBRIDGE][VIRTUAL].
14. Appendix A: Other Encapsulation Alternatives
Another possibility for a layer 2.5 "shim" to encapsulate labels
similar to MPLS 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, all considerations discussed in this
document would apply in an identical fashion except that the 16-bit
Templin Expires April 26, 2007 [Page 15]
Internet-Draft IPvLX October 2006
UDP source port would be used as a per-hop flow designator instead of
the IPvLX flow identifier and legacy IPv4 NATs would be used instead
of IPvLX gateways. As such, this document can 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 hosts located
behind legacy NATs in the current IPv4 Internet infrastructure before
true IPvLX gateways become widely deployed.
From an idealistic standpoint, Teredo would seem to offer an
opportunity for immediate IPv6 flag-day rollout. For example, if a
large end-host software vendor distributed a new major release (or a
patch release for its already-deployed products) that enabled Teredo,
peer-to-peer operations could commence immediately with no changes to
the network. From a practical standpoint, however, this would place
all of the security burden on the end-hosts with little/no protection
from firewalls in the network. The security would then be limited to
the quality of any host-specific firewalls on the end-nodes, 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 in a routine patch distribution with an
ulterior motive of exposing end-user devices that were previously
hidden behind the opaque (yet brittle) protection afforded as an
unwarranted side-effect of IPv4 NATs. 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.
Such "vendors" would essentially be using "TereDo" to "Do Terror",
yet even without a published interoperability specification such as
Teredo unscrupulous "vendors" could still roll out their own
proprietary "terrorist tools" to exploit IPv4 NAT weaknesses.
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 underscoring the need for
Network Architecture Protection [NAP] in IPv6. Whether it also
provides a flag day deployment mechanism for IPv6 is beyond the scope
of this document.
16. Appendix C: Changes
Changes since -04, -05:
Templin Expires April 26, 2007 [Page 16]
Internet-Draft IPvLX October 2006
o updated references
Changes since -03:
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
[ADAPT] Templin, F., "Link Adaptation for IPv6-in-IPv4 Tunnels",
draft-templin-linkadapt (work in progress),
September 2005.
[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
[DSR] Johnson, D., Maltz, D., and Y. Hu, "The Dynamic Source
Routing Protocol for Mobile Ad Hoc Networks (DSR)",
draft-ietf-manet-dsr (work in progress), July 2004.
[DSTM] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
(DSTM)", draft-bound-dstm-exp (work in progress),
Templin Expires April 26, 2007 [Page 17]
Internet-Draft IPvLX October 2006
October 2005.
[DYMO] Chakeres, I., Belding-Royer, E., and C. Perkins, "Dynamic
MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo
(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.
[ICMPV6] Conta, A., Deering, S., and M. Gupta, ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3 (work in progress), July 2005.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal Multicast
Name Resolution (LLMNR)", draft-ietf-dnsext-mdns (work in
progress), October 2005.
[NAME] Balakrishnan, H. and et. al., "A Layered Naming
Architecture for the Internet, SIGCOMM 2004, Aug. 30 -
Sep. 2, 2004.".
[NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Network Architecture Protection",
draft-vandevelde-v6ops-nap (work in progress),
October 2005.
[NDPROXY] Thaler, D., Talwar, M., and C. Patel, "Bridge-like
Neighbor Discovery Proxies (ND Proxy)",
draft-thaler-ipv6-ndproxy (work in progress),
October 2005.
[NODEREQ] Loughney, ed., J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements (work in progress),
August 2004.
[PMTUD] Mathis, M., Heffner, J., and K. Lahey, "Path MTU
Discovery", draft-ietf-pmtud-method (work in progress),
February 2005.
[RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges:
Transparent Routing", draft-perlman-rbridge (work in
progress), May 2005.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Templin Expires April 26, 2007 [Page 18]
Internet-Draft IPvLX October 2006
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[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.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[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.
Templin Expires April 26, 2007 [Page 19]
Internet-Draft IPvLX October 2006
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
"End-to-end Performance Implications of Slow Links",
BCP 48, RFC 3150, July 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology
Dissemination Based on Reverse-Path Forwarding (TBRPF)",
RFC 3684, February 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[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
Templin Expires April 26, 2007 [Page 20]
Internet-Draft IPvLX October 2006
(UDP-Lite)", RFC 3828, July 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[VIRTUAL] Touch, J., Wang, Y., Eggert, L., and G. Finn, "Virtual
Internet Architecture, Future Developments of Network
Architectures (FDNA) at Sigcomm", August 2003.
[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.".
Templin Expires April 26, 2007 [Page 21]
Internet-Draft IPvLX October 2006
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 April 26, 2007 [Page 22]
Internet-Draft IPvLX October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 April 26, 2007 [Page 23]