Network Working Group F. Templin
Internet-Draft Nokia
Expires: February 15, 2005 August 15, 2004
IPv6 Addressing in the IPv4 Internet
draft-templin-v6v4inet-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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
RFC 3668.
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 February 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The IPv6 128-bit address space was designed as a solution for the
32-bit limitation of IPv4, but the proliferation of IPv4 in the
global Internet continues via private addressing domains behind
Network Address Translators (NATs). For these reasons, deployment of
IPv6 at the end nodes with minimal perturbation of IPv4 networks
presents a natural long-term transition and coexistence alternative.
This document proposes a coexistence scenario with IPv6 for end to
end addressing and IPv4 for network traversal.
Templin, et al. Expires February 15, 2005 [Page 1]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
1. Introduction
The IPv6 128-bit address space was designed as a 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]. For these reasons, deployment
of IPv6 at the end nodes with minimal perturbation of IPv4 networks
presents a natural long-term transition and coexistence alternative.
The Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] connects
IPv6 nodes separated by IPv4 networks using basic IPv6-in-IPv4
encapsulation (i.e., "ISATAP encapsulation") and an intra-site
virtual link abstraction similar to the Non-Broadcast, Multiple
Access (NBMA) model [RFC2491][RFC2492]. ISATAP nodes that also
implement the relay/proxy/bridge/server (RPBS), IPv4 Network Address
Translation (NAT), and advanced packet encapsulation functions
described in this document can extend this virtual link to reach
nodes in other enterprises/sites and located many IPv4 hops away.
2. Terminology
The terminology of [ISATAP][RFC2460][RFC2461] applies to this
document. The following additional terms are defined:
logical interface:
the same as defined in ([STD3], section 3.3.4.1).
virtual link:
the IPv4 network span over which packets can be forwarded from an
IPv6 sender toward a particular target endpoint (e.g., a peer
application) without the Hop Limit field in the IPv6 header being
decremented.
enterprise:
the same as defined in ([RFC1918], section 1); for the purpose of
this document, enterprise network entities have direct connection
to the global IPv4 Internet and comprise one or more sites.
site:
a network entity that is a proper subset of an enterprise (or
parent site) and determines its own addressing plan and address
assignments; a site comprises a relay/proxy/bridge/server (RPBS)
and its associated hosts.
Templin, et al. Expires February 15, 2005 [Page 2]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
relay/proxy/bridge/server (RPBS):
an IPv4 NAT that provides relaying, proxying, bridging, and/or
service provisioning capabilities to form the logical nucleus for
a site. RPBSs also serve as routers for their co-located IPv6
endpoints and endpoints on IPv6-only hosts; enterprise border
RPBSs are 6to4 routers [RFC3056].
associated host:
an RPBS or IPv6-only node that associates with a parent RPBS. An
RPBS that is an associated host within a parent site can also
serve as a parent RPBS for associated hosts in child sites.
IP Virtual Link eXtension (IPVLX) packet:
an IPv4 packet created via IPVLX encapsulation.
IPVLX encapsulation:
a method of encapsulating a segment of an IPv6 packet/fragment in
an outer IPv4 header (described in section 4).
IPVLX link adaptation:
a method for segmenting an IPv6 packet/fragment into a chain of
IPVLX packets (described in section 5) during encapsulation for
later reassembly during decapsulation, e.g., to satisfy path MTU
restrictions, etc.
IPVLX interface:
an interface that performs IPVLX encapsulation and link
adaptation, but otherwise behaves the same as an ISATAP interface.
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 [BCP14].
3. Autoconfiguration
RPBSs should automatically discover the addresses of parent RPBSs,
enterprise border RPBSs, DNS recursive name servers, etc. at startup
time or when moving to a new link. They should also configure
supporting services (e.g., DHCPv4 [RFC2131], DHCPv6
[RFC3315][RFC3633][RFC3736], Mobile IPv6 Home Agent [RFC3775], etc.)
and advertise the 6to4 Relay anycast prefix ([RFC3068], section 2.3)
for their associated hosts.
Associated hosts can act as site border RPBSs for their own
associated hosts to enable recursively-nested "sites within sites",
with scaling properties limited only by enterprise/site addressing
plans.
Templin, et al. Expires February 15, 2005 [Page 3]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
RPBSs should register their name-to-address mappings via secure,
dynamic updates to the DNS [RFC2136][DNSSEC]. (RPBSs that do not
receive IPv6 address assignments and/or prefix delegations via
autoconfiguration mechanisms should configure unique local addresses
[UNIQ1][UNIQ2].)
RPBSs should provide basic packet forwarding services if possible
within constraints such as memory, battery power, RF link quality,
etc. They should also use dynamic route discovery protocols such as
those from the IETF MANET working group
[RFC3561][RFC3626][RFC3684][DSR]. Unification of the MANET protocols
with existing routing/bridging protocols (e.g., OSPF [RFC2740], IEEE
802.1D spanning tree [STP], etc.) and an efficient flooding mechanism
is currently under investigation.
4. IPVLX Encapsulation
RPBSs determine the IPv4 addressing plans for their associated hosts,
which can in turn serve as RPBSs 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, RPBSs must act as IPv4 NATs for the packets they forward
between sites. A new form of IPv6-in-IPv4 packet encapsulation (i.e.,
"IPVLX encapsulation") is therefore required to provide mutable bits
in the IPv4 header that an RPBS can rewrite at the same time it
rewrites the IPv4 source and/or destination address.
Referring to ([RFC0791], Section 3.1), when an RPBS encapsulates an
IPVLX packet it sets the IPv4 header "Protocol" field to '41' and
also sets bits 0 and 1 in the "Flags" field (i.e., the "Reserved
Fragmentation (RF)" and "Don't Fragment (DF)" bits) to 1. Setting the
DF bit frees the 13 "Fragment Offset" and 16 "Identification" bits
for use as mutable bits, since setting the DF bit disables IPv4
fragmentation and since the encapsulating IPv4 header is not included
in the pseudo-header checksum calculations of upper layer protocols.
Setting the RF bit allows RPBSs to distinguish IPVLX packets from
ordinary ip-protocol-41 packets.
When an RPBS sends/forwards/receives an IPVLX packet, it treats the
16-bit "Identification" field as a 16-bit virtual circuit identifier
(VCI) and the high-order 8-bits of the "Fragment Offset" field as an
8-bit virtual path identifier (VPI). The VCI/VPI values in each IPVLX
packet are initialized by the first hop RPBS and (possibly) modified
by intermediate RPBSs on the path. The VCI/VPI values along with the
packet's IPv4 source and destination addresses (which provide logical
input/output interfaces) identify a virtual circuit (VC) that
represents the (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple for the
encapsulated IPv6 flow.
Templin, et al. Expires February 15, 2005 [Page 4]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
5. MTU and Link Adaptation
All IPv6 interfaces must support the IPv6 minimum MTU of 1280 bytes,
i.e., they must be able to send IPv6 packets/fragments of 1280 bytes
or smaller to any neighbor on the link without returning an ICMPv6
"Packet too Big" error [RFC1981] to the source. (IPVLX interfaces
must also avoid unnecessary fragmentation in the IPv4 Internet
[FRAG]). IPVLX interfaces must therefore implement a link adaptation
layer similar to ATM Adaptation Layer 5 (AAL5) [RFC2684] to segment
each IPv6 packet/fragment into a chain of IPVLX packets no larger
than the MTU of the outgoing IPv4 interface.
IPVLX link adaptation uses the AAL5 PDU format ([RFC2684], section 4)
except that the PAD field and all fields of the CPCS-PDU Trailer
other than the 4-octet CRC are omitted. IPVLX link adaptation uses
the CPCS-PDU Payload format for VC multiplexing of routed protocols
([RFC2684], section 6.1); the CRC is calculated across all payload
bytes exactly as for AAL5.
IPVLX interfaces use a default segment size (i.e., "SEGSIZE") of 48
bytes for IPVLX link adaptation to segment IPv6 packets/fragments
into chains of IPVLX packets that comprise a 20 byte IPv4 header
followed by a segment of the original packet no larger than 48 bytes.
IPVLX interfaces can use a larger SEGSIZE, but in that case must use
reliable mechanisms (e.g., out-of-band probing, etc.) to avoid ICMPv4
"fragmentation needed" messages [RFC1191] and/or path MTU-related
black holes [RFC2923]. IPVLX interfaces can use a smaller SEGSIZE,
but the size must be large enough to both satisfy the 1280 byte IPv6
minimum MTU and avoid poor performance.
IPVLX link adaptation uses the five low order bits from the 13-bit
IPv4 "Fragmentation Offset" field (see: section 4) to encode a
monotonically increasing segment ID (i.e., "SEGID") between 0 - 31 in
consecutive IPVLX packets of a chain. The "More Fragments" (MF) bit
is set as for ordinary IPv4 fragmentation, i.e., the MF bit is set in
all IPVLX packets in the chain except the final one.
IPVLX link adaptation splits an IPv6 packet/fragment (including the
IPv6 header and all data bytes) into blocks of SEGSIZE bytes and
encapsulates them in sequential order in a chain of no more than 32
IPVLX packets; all packets in the chain except the final one must be
of equal length. (The final packet may be smaller than the other
packets in the chain, but it must not be larger.) The trailing CRC is
encoded as the final 4 data bytes in the chain in network byte order
with no natural boundary alignment restrictions. The IPVLX packets in
a chain are sent over the wire in sequential SEGID order, i.e.,
segment 0 first, followed by segment 1, etc.
Templin, et al. Expires February 15, 2005 [Page 5]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
The Length, SEGID, MF and VC-related fields in the IPv4 headers of a
chain of IPVLX packets provide sufficient information for reassembly
with protection for minor packet reordering in the IPv4 network. The
equal length restriction for non-final IPVLX packets provides a fixed
hole size for reassembly algorithms [RFC0815]. The last hop RPBS
performs CRC verification as the final step in reassembly to identify
and discard IPVLX packet chains with data corruption. (Other
reassembly algorithm details are FFS).
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 packet chain reassembly
provides a 4 byte CRC, 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.
The use of IPVLX link adaptation may lead to an overall increase in
short chains of small packets in the Internet. Network administrators
are advised to follow the recommendations in [BCP48] to minimize
packet loss and packet reordering.
Network middleboxes that forward IPVLX packet chains can reassemble
and re-segment chains into different-sized IPVLX packets if they have
sufficient storage/processing resources to avoid packet loss and can
avoid path MTU black holes (see: section 7).
6. Virtual Link Extension
When a local IPv6 endpoint sends IPv6 packets toward a target
endpoint, the virtual link from the sender's first hop RPBS can be
extended to the last hop RPBS before the target via IPv4 NAT
traversal as follows:
Templin, et al. Expires February 15, 2005 [Page 6]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
6.1 From the First Hop RPBS to the Target's Enterprise/Site Border
When an intermediate RPBS along the path from the first hop to the
target's enterprise/site border receives an IPVLX packet for an
unknown VC, it creates a new VC cache entry (managed as for IPv6 flow
state [RFC3697]). When it forwards the packet into a topologically
disjoint IPv4 addressing region, the RPBS also rewrites the IPv4
source address to the address of the IPv4 interface that will forward
the packet and rewrites VCI/VPI to a unique value for the new IPv4
source and original IPv4 destination addresses. (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 RPBS VC cache entries store mappings from: (VCI(in),
VPI(in), IPv4_src(in), IPv4_dst(in)) to: (VCI(out), VPI(out),
IPv4_src(out), IPv4_dst(out)) to support NAT traversal during a
flow's lifetime. The first hop RPBS also caches a (IPv6 src, IPv6
dst, IPv6 flow_label)-tuple to identify a flow's endpoints.
6.2. From the Target's Enterprise/Site Border to the Last-Hop RPBS
For IPVLX packets entering an enterprise/site (and, for authentic
ICMPv4 messages reporting errors for IPVLX packets that previously
exited the enterprise/site) each intermediate RPBS along the path
toward the target should use some form of static/dynamic IPv6 route
discovery to determine the next hop RPBS among their associated
hosts. (Possible route discovery mechanisms include static prefix
delegations, routes learned via dynamic routing protocols, etc.)
Intermediate RPBSs should not decapsulate the packet as an IPv6
router would do, but instead relay the packet to the next hop RPBS
via IPv4, leaving the "Hop Limit" field in the IPv6 header unchanged.
The last hop RPBS in the path will be an IPv6 router for the target
that decapsulates the packet.
To support this relaying, when an intermediate RPBS along the path
from the enterprise/site border to the last hop RPBS before the
target receives an IPVLX packet for an unknown VC, it creates a new
VC cache entry (managed as for IPv6 flow state [RFC3697]). When it
forwards the packet into a topologically disjoint IPv4 addressing
region, the RPBS also rewrites the IPv4 destination address to the
IPv4 address of the next hop RPBS, rewrites the IPv4 source address
to the address of the IPv4 interface that will forward the packet,
and rewrites VCI/VPI to a unique value for the new IPv4 source and
destination addresses.
Intermediate RPBS VC cache entries store mappings from: (VCI(in),
VPI(in), IPv4_src(in), IPv4_dst(in)) to: (VCI(out), VPI(out),
Templin, et al. Expires February 15, 2005 [Page 7]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
IPv4_src(out), IPv4_dst(out)) to support NAT traversal during a
flow's lifetime. The last hop RPBS also caches a (IPv6 src, IPv6 dst,
IPv6 flow_label)-tuple to identify a flow's endpoints.
7. Error Handling
RPBSs may receive authentic ICMPv4 messages that comprise an outer
IPv4 header with the IPv4 source address of the 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.
When a first hop RPBS receives an authentic ICMPv4 message, it can
use the VC information encoded in the IPv4 header from the packet-in-
error to locate an (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple in its
VC cache for ICMPv6 error message translation [RFC2765]. When an
intermediate RPBS receives an authentic ICMPv4 message, it can
forward the message to the previous hop RPBS based on its VC cache.
RPBSs can keep per-VC queues of recently-sent IPVLX packet chains
with packets larger than 68 bytes for re-segmentation and
retransmission when an authentic ICMPv4 "fragmentation needed"
message is received, but this may not be possible for some
intermediate RPBSs due to storage and/or processing limitations.
RPBSs should discard (and may process as soft errors) any ICMPv4
messages that cannot be authenticated. In particular, RPBSs should
not implement the per-VC queuing method described above for any VC
for which ICMPv4 "fragmentation needed" messages that cannot be
authenticated may occur.
8. Header Compression
After the first hop RPBS selects the IPv6 source and destination
addresses for communication with the target and sends the initial
IPVLX packets of the flow, any intermediate RPBSs in the path should
have VC cache state established. The first hop RPBS can then use
IPv6 header compression for subsequent packets sent over the same VC
[RFC2507][RFC3095].
Templin, et al. Expires February 15, 2005 [Page 8]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
9. Discovering a Parent RPBS for the Site
During IPv4 address autoconfiguration, RPBSs that do not connect
directly to the global IPv4 Internet should discover an IPv4 address
for a parent RPBS via, e.g., resolving a Fully-Qualified Domain Name
(FQDN) in the site's name service (e.g., [LLMNR]), receiving a DHCPv4
option, etc. RPBSs may instead use the 6to4 Relay anycast address
([RFC3068], section 2.4) when no other mechanisms are available or
when the overhead for using other mechanisms is unacceptable.
Following IPv4 address discovery, RPBSs should next send IPVLX
encapsulated (*) Router Solicitation messages to verify that the
parent RPBS is up and to receive IPv6 autoconfiguration parameters.
The Router Solicitation messages should use the following addresses:
- in the IPv6 source address, a link-local address (preferably a
link-local [CGA] address)
- in the IPv6 destination address, a link-local ISATAP address
([ISATAP], section 6.2]) that embeds an IPv4 address for a
parent RPBS
- in the IPv4 source address, the IPv4 address from the
underlying IPv4 interface that will send the encapsulated
Router Solicitations
- in the IPv4 destination address, the IPv4 address embedded in
the IPv6 destination address
When a [CGA] source address is used, the Router Solicitation should
include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof-
of-ownership verification.
When the parent RPBS receives the Router Solicitation, it can send
back an IPVLX encapsulated (*) Router Advertisement with the
following addresses:
- in the IPv6 source address, a link-local address (preferably a
link-local [CGA] address)
- in the IPv6 destination address, the IPv6 source address
received in the Router Solicitation
- in the IPv4 source address, an equivalent IPv4 unicast address
([RFC3068], section 2.6)
- in the IPv4 destination address, the IPv4 source address
received in the Router Solicitation
Templin, et al. Expires February 15, 2005 [Page 9]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
When a [CGA] source address is used, the Router Advertisement should
include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof-
of-ownership verification. The Router Advertisement should also
include a SLLAO with an embedded global IPv4 unicast address
([RFC2529], section 5) associated with an enterprise border RPBS for
the site, i.e., a 6to4 router [RFC3056] for the enterprise.
(*) If the RPBS does not receive a Router Advertisement in
response to IPVLX encapsulated Router Solicitations, it should
instead send ISATAP encapsulated Router Solicitations [ISATAP]. In
that case, link-local ISATAP addresses that embed the
corresponding IPv4 addresses should be used in Router
Solicitation/Advertisement messages instead of [CGA] addresses.
10. Discovering More-Specific Routes
When an IPv6 endpoint initiates communications with a target
endpoint, its first hop RPBS resolves the target's Fully-Qualified
Domain Name (FQDN) using the DNS [RFC1035] or a name service for the
site (e.g., [LLMNR]). If the name service returns a set of AAAA
records including one with a 6to4 [RFC3056] address, the first hop
RPBS can consider the IPv4 address embedded in the 6to4 prefix as the
IPv4 destination address for the target node's enterprise border
RPBS.
For target nodes located in other sites/enterprises, the first hop
RPBS can then send IPVLX encapsulated IPv6 Router Solicitation
messages to discover a more-specific route for the target [DEFLT]
with the following addresses:
- in the IPv6 source address, a global (or unique local) [CGA]
unicast address for the initiating IPv6 endpoint
- in the IPv6 destination address, a global (or unique local)
IPv6 unicast address for the target returned by the name
service
- in the IPv4 source address, an address from the underlying
IPv4 interface that sends the IPVLX encapsulated Router
Solicitation
- in the IPv4 destination address, the 6to4-embedded IPv4
address
The IPVLX encapsulated IPv6 Router Solicitation should include [SEND]
parameters for [CGA] proof-of-ownership verification.
Templin, et al. Expires February 15, 2005 [Page 10]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
When the last hop RPBS before the target receives a Router
Solicitation, it can perform a reverse name service lookup on the
IPv6 source address as a means of authenticating the initiator. It
can then send an IPVLX encapsulated Router Advertisement back toward
the soliciting RPBS with the following addresses:
- in the IPv6 source address, a [CGA] link-local address
- in the IPv6 destination address, the IPv6 source address from
the Router Solicitation
- in the IPv4 source address, an address from the underlying
IPv4 interface that sends the IPVLX encapsulated Router
Advertisement
- in the IPv4 destination address, the IPv4 source address
received in the Router Solicitation
The IPVLX encapsulated IPv6 Router Advertisement should include a
SLLAO with an embedded global IPv4 unicast address ([RFC2529],
section 5) associated with an enterprise border RPBS for the target
and [SEND] parameters for [CGA] proof-of-ownership verification. It
should also include as many of the target's IPv6 addresses as
possible in Route Information Options [DEFLT].
When the soliciting RPBS receives a Router Advertisement, it can
verify that the IPv6 addresses in Route Information Options match the
IPv6 addresses received in AAAA records returned by the name service
as a means of authorizing the target. This assumes the name service
can be used as a suitable trust anchor for router authorization
without the need for ([SEND], section 6) authorization delegation
discovery.
Following authorization, the soliciting RPBS can create IPv6 route
cache entries with the link-local ISATAP address constructed from the
IPv4 address in the Router Advertisement's SLLAO as the next hop
toward the target's IPv6 addresses, and use IPv6 address selection
rules to determine the best IPv6 source and destination addresses to
choose for communications with the target [RFC3484]. The route cache
entries should be managed in conjunction with name service cache
entries, i.e., they should be deleted when the lifetime for the
corresponding name service cache entry expires.
Templin, et al. Expires February 15, 2005 [Page 11]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
11. Mobility
When an RPBS moves to a different network point of attachment, it
will receive new IPv4 autoconfiguration information and discover a
new parent RPBS that potentially resides in a different enterprise.
Upon reattachment, the mobile RPBS should send IPv6 Router
Solicitation messages using secure neighbor discovery mechanisms
[SEND][CGA] to its home enterprise border RPBS (i.e., its home 6to4
router) to update the router's neighbor cache and dynamic routing
information in any intermediate RPBSs.
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 RPBSs 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 [SEND][CGA] should be used to provide
mobile node location updates to correspondent nodes is FFS.
12. Analysis of Encapsulation Alternatives
IPv6 peers that connect to the same physical L2 media segment can use
native IPv6 directly over the L2 media. Attachment to the same
physical L2 media segment can be detected based on, e.g., passive
message snooping, whether/not a neighbor responds to native IPv6
neighbor discovery messages sent over the L2 media, etc.
In many cases, IPv6 neighbors will be attached to different physical
L2 media segments. To avoid issues associated with bridging
dissimilar media (e.g., path MTU black holes) and to support IPv6
neighbor discovery security mechanisms, RPBSs should use either
ISATAP encapsulation or IPVLX encapsulation for sending IPv6 packets
to neighbors within the same site and use IPVLX encapsulation for
sending IPv6 packets to neighbors in different sites.
When legacy NAT boxes that do not support the mechanisms described in
this document are in the path, RPBSs should use explicit NAT
traversal mechanisms (e.g., [TEREDO]) since they provide a lowest-
common denominator approach supported by most legacy NATs. However,
the IPv6/UDP/IPv4 encapsulation used by explicit NAT traversal
mechanisms requires an extra 8 bytes of overhead for each
encapsulated packet; effectively reducing the segment payload for a
68 byte encapsulated packet to only 40 bytes.
Templin, et al. Expires February 15, 2005 [Page 12]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
13. Security considerations
RPBSs and associated hosts use the securing mechanisms for IPv6
neighbor discovery found in [CGA][SEND] according to the trust model
appropriate for the given deployment scenario [RFC3756].
RPBSs and associated hosts use the securing mechanisms for IPv6 nodes
found in ([NODEREQ], section 8).
14. Acknowledgments
This document represents the author's best effort to anticipate,
interpret and describe emerging trends rooted in firm scientific
principles. The author acknowledges the many individuals whose many
years of effort have helped shape them.
The following are acknowledged for their helpful insights on path MTU
discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, Brian
Carpenter, Ralph Droms, Alain Durand, Jim Fleming, Tim Gleeson, Jun-
ichiro itojun Hagino, Brian Haberman, Bob Hinden, Christian Huitema,
Eddie Kohler, Kevin Lahey, Masataka Ohta, Matt Mathis, Jeff Mogul,
Erik Nordmark, Soohong Daniel Park, Chirayu Patel, Charles Perkins,
Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave
Thaler, Margaret Wasserman, Michael Welzl, Lixia Zhang, and the
members of the Nokia NRC/COM Mountain View team.
"...and I'm one step ahead of the shoe shine,
Two steps away from the county line,
Just trying to keep my customers satisfied,
Satisfi-i-ied!" - Paul Simon, 1969
Appendix A. The IPv6 minimum MTU
The 1280 byte IPv6 minimum MTU was agreed through working group
consensus in November 1997 discussions on the IPv6 mailing list.
Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Templin, et al. Expires February 15, 2005 [Page 13]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
[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.
Informative References
[BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
"End-to-end Performance Implications of Slow Links", BCP 48,
RFC 3150, July 2001.
[STD3] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[RFC0815] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, July
1982.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 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.
[RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491,
January 1999.
[RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
Templin, et al. Expires February 15, 2005 [Page 14]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
[RFC2507] Degermark, M., Nordgren, B. and S. Pin, "IP Header
Compression", RFC 2507, February 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.
[RFC2740] Colton, 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.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[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.
[RFC3095] Bormann, C. (Ed.), "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC
3095, July 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.
Templin, et al. Expires February 15, 2005 [Page 15]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Option 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.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery Trust Models and Threats", RFC 3756, May 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., editor
and G. Fairhurst, editor, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga, Work in Progress, April 2004.
[DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", draft-ietf-ipv6-router-selection, Work in
Progress, August 2004.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro, Work in Progress, July 2004.
[DSR] Johnson, D., Malz, D. and Hu, Y., "The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr,
Work in Progress, April 2003.
[FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In
Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications
Technology. August 1987.
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)",
draft-ietf-ngtrans-isatap, Work in Progress, May 2004.
[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
Name Resolution (LLMNR)", draft-ietf-dnsext-mdns, Work in Progress,
July 2004.
Templin, et al. Expires February 15, 2005 [Page 16]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
[NDPROXY] Thaler, D., Talwar, M. and C. Patel, "Bridge-Like Neighbor
Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy, Work in
Progress, February 2004.
[NODEREQ] J. Loughney, editor, "IPv6 Node Requirements", draft-ietf-
ipv6-node-requirements, Work in Progress, August 2004.
[RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent
Routing", draft-perlman-rbridge-00, Work in Progress, April 2004.
[SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P.
Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt,
Work in Progress, July 2004.
[STP] T. Jeffree, editor, "Media Access Control (MAC) Bridges",
ANSI/IEEE Std 802.1D, 1998,
http://standards.ieee.org/getieee802/download/802.1D-1998.pdf.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-huitema-v6ops-teredo, Work in Progress, February 2004.
[UNIQ1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, June
2004.
[UNIQ2] Hinden, R., and B. Haberman, "Centrally Assigned Unique Local
IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central, Work in
Progress, June 2004.
Authors' Addresses
Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94110
US
Phone: +1 650 625 2331
EMail: ftemplin@iprg.nokia.com
Templin, et al. Expires February 15, 2005 [Page 17]
Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Templin, et al. Expires February 15, 2005 [Page 18]