Network Working Group F. Templin
Internet-Draft Nokia
Expires: November 4, 2004 May 4, 2004
ISATAP Extensions for Mobility, Multihoming
and Efficiency Improvement (IEMMEI)
draft-templin-v6ops-iemmei-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 4, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
IPv6 hosts/routers over IPv4 networks via automatic tunneling using a
link abstraction similar to the Non-Broadcast, Multiple Access (NBMA)
model. This document describes operational extensions for ISATAP that
enable a dynamic tunnel endpoint management abstraction similar to
the ATM Permanent/Switched Virtual Circuit model. Nodes can use these
extensions to realize mobility, multihoming and efficiency
improvements.
Templin, et al. Expires November 4, 2004 [Page 1]
Internet-Draft IEMMEI April 2004
1. Introduction
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
IPv6 hosts/routers over IPv4 networks via automatic tunneling using a
link abstraction similar to the Non-Broadcast, Multiple Access (NBMA)
model [RFC2491]. This document presents ISATAP Extensions for
Mobility, Multihoming, and Efficiency Improvement (IEMMEI -
pronounced: "i-am-i") that enable a dynamic tunnel endpoint
management abstraction similar to the ATM Permanent/Switched Virtual
Circuit model [RFC2492]. Nodes that use these extensions can realize
mobility, multihoming and efficiency improvements.
2. Terminology
The terminology of [ISATAP][RFC2460][RFC2461] applies to this
document. The following additional terms are defined:
site:
the same as defined in ([RFC3582], section 2). In practical terms,
a site consists of one or more routers and their associated hosts.
ISATAP link:
the extent of an ISATAP interface's attached site; neighbor-
dependent, and may be asymmetric based on egress and ingress
directions.
embedded gateway:
the same as defined in ([STD3], section 1.1.4).
logical interface:
the same as defined in ([STD3], section 3.3.4.1). Within the
context of this document, a logical interface is an IPv6 address
or a configured tunnel associated with an ISATAP interface.
IEMMEI node:
A node that observes the specifications in [ISATAP] and adds
operational extensions as described in this document.
IEMMEI daemon:
an IEMMEI node's server application that uses an API for control
plane signaling based on IPv6 Neighbor Discovery messages, and
provides an abstraction similar to IPv6 Tunnel Broker [RFC3053]
for configuring/managing tunnel endpoints.
Templin, et al. Expires November 4, 2004 [Page 2]
Internet-Draft IEMMEI April 2004
IEMMEI driver:
an IEMMEI node's network module that provides an API for control
plane signaling and tunnel endpoint configuration/management. Also
provides a packet encapsulation/decapsulation engine, and an
embedded gateway function.
3. IEMMEI Conceptual Model
ISATAP interfaces are IPv6 interfaces that provide a non-broadcast
multi-access abstraction for automatic tunneling of IPv6 packets over
IPv4 networks. They also provide a forwarding plane nexus (used by
the IEMMEI driver) for forwarding packets on behalf of their
associated logical interfaces, and a control plane nexus (used by the
IEMMEI daemon) for sending and receiving IPv6 neighbor discovery
messages.
The IEMMEI driver encapsulates packets for transmission according to
a logical interface's attributes. It also determines the correct
logical interface to receive each tunneled packet after
decapsulation, and provides an embedded gateway function.
The IEMMEI daemon configures/manages tunnel endpoints using IPv6
neighbor discovery messages for control plane signaling. Each such
tunnel endpoint is managed as an ISATAP interface's associated
logical interface and provides a nexus for multiple applications
using IPv6 addresses as application identifiers. Each such
application identifier provides a nexus for multiple sessions. In
summary, each tunnel endpoint can support multiple applications and
multiple instances of each application.
Templin, et al. Expires November 4, 2004 [Page 3]
Internet-Draft IEMMEI April 2004
The following example diagram depicts the IEMMEI conceptual model:
<-- IPv6-enabled applications -->
+----+ +---------------------------------------------+
|I D| | IPv6 Stack |
|E a| | |
|M e| | <-- IPv6 addresses --> |
|M m| | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |
|E o| | |v6| |v6| |v6| |v6| |v6| |v6| |v6| ... |v6| |
|I n| | +--+ +-++ ++-+ ++-+ ++++ ++-+ +-++ +-++ |
+-+--+ +---/---/----|----|---/-|--|-\----|--------|--+
| / / | | / | | \ | | <----+
x / / | | / | | \ | | I |
/ / +--++ +++-+ +--++ ++-++ +-+-+ E |
/ / |tun| |tun| |tun| |tun| ... |tun| M |
/ / +-+-+ +--++ +-+-+ ++--+ +-+-+ M |
/ / | \ | / | E |
x / / x | x \ | / x | I |
| / / | | | \ | / | | |
+--+---+---+ +------+---+ +-----+-+-++ +--------+-+ D |
|ISATAP I/F| |ISATAP I/F| |ISATAP I/F| .. |ISATAP I/F| r |
| (site 1) | | (site 1) | | (site 3) | | (site n) | i |
+---+----+++ +-++-----+-+ +-+-----+-++ +------+---+ v |
| | \ / | | | | \ | e |
| | \/ | | | | \ | r |
| | /\ | | | | \ | <----+
+---|----|-/--\-|-----|-----|-----|-----\ -------|---+
| +-+-+ +++-+ +++-+ +-+-+ +-+-+ +-+-+ +--++ +-+-+ |
| |loc| |loc| |loc| |loc| |loc| |loc| |loc| .. |loc| |
| +-+-+ +--++ +---+ +---+ +-+-+ +-+-+ +-+-+ +-+-+ |
| | / / / \ | / / |
| | / / +---+ \ | / / |
| | / / / \ | / / |
| | / / / IPv4 Stack \ | / / |
+-+-+-+--+-+--+--------+--+------+++------+-+------+-+
|IPv4 I/F| |IPv4 I/F| |IPv4 I/F| .... |IPv4 I/F|
|(site 1)| |(site 2)| |(site 3)| |(site n)|
+--------+ +--------+ +--------+ +--------+
4. IEMMEI Node Extensions
IEMMEI nodes observe the specifications in [ISATAP] and add
operational extensions as described in the following subsections of
this document. Proper application of these extensions can expand the
[ISATAP] domain of applicability to include all operational scenarios
covered under the IETF v6ops working group analysis.
Templin, et al. Expires November 4, 2004 [Page 4]
Internet-Draft IEMMEI April 2004
4.1 Interface Management
IEMMEI nodes typically create ISATAP interfaces statically during
system startup but can also create them dynamically during runtime,
e.g., when an IPv4 interface is enabled/disabled. Each ISATAP
interface configures a locator set that includes IPv4 address-to-
interface mappings from a single site.
IEMMEI nodes typically configure tunnel endpoints dynamically during
runtime as an ISATAP interface's associated logical interface, e.g.,
via IPv6 Neighbor Discovery messages processed by the IEMMEI daemon.
Each tunnel endpoint inherits the locator set of its associated
ISATAP interface.
4.2 Mobility Management
IEMMEI nodes use the IPv6 Neighbor Discovery mechanisms specified in
([ISATAP], section 8) to manage the IPv6 L3 address to IPv4 L2
addresses mappings for tunnel endpoints.
When an IEMMEI node changes its IPv4 network point of attachment, it
can send authenticated IPv6 neighbor discovery messages (e.g.,
unsolicited Neighbor Advertisement messages) that include Link Layer
Address Options (LLAOs) encoding the new IPv4 address ([RFC2529],
section 5).
When an IEMMEI node receives authentic IPv6 neighbor discovery
messages that include such LLAOs, it can update appropriate L3->L2
address mappings in tunnel endpoints.
Using these extensions, the set of tunnel endpoints associated with
an IEMMEI node's ISATAP interface(s) provides a binding cache for
mobility management, and IPv6 neighbor discovery messages that
include LLAOs provide a mechanism to dynamically manage L3->L2
address mappings.
Templin, et al. Expires November 4, 2004 [Page 5]
Internet-Draft IEMMEI April 2004
4.3 Encapsulation
The IEMMEI driver encapsulates IPv6 packets according to the
encapsulation attributes of an ISATAP interface's associated logical
interface (or, according to the encapsulation attributes of other
tunnel interfaces). Encapsulation methods can include ip-protocol-41
(e.g., 6over4 [RFC2529], 6to4 [RFC3056], configured tunnels [MECH],
isatap itself [ISATAP], etc.), UDP/IPv4 encapsulation (e.g., teredo
[TEREDO], etc.) and others (e.g., UDP-Lite [UDPLITE], minimal
encapsulation within IP [RFC2004], etc.).
Security processing, upper layer fragmentation and header compression
for the packet's inner headers are performed prior to encapsulation.
4.4 Flow Labels
IPv6 packets that comprise a flow can carry non-zero values in the
Flow Label field to aid Packet Classifiers [RFC3697], but the IPv6
Neighbor Discovery specification [RFC2461] makes no mention of the
use of the Flow Label field in IPv6 Neighbor Discovery messages.
To aid packet classifiers, IEMMEI nodes can set the Flow Label field
in Neighbor Solicitation, Router Solicitation and Redirect messages
to the same value that appears in the Flow Label field of messages
that triggered the solicitation/redirect event. They can also set the
Flow Label field in Neighbor Advertisement and Router Advertisement
messages to the same value that appears in the Flow Label field of
messages that triggered the advertisement.
4.5 ISATAP Link and NAT Interactions
IEMMEI nodes should use simple ip-protocol-41 encapsulation whenever
possible, since it provides sufficient functionality for tunneling
packets between IPv6 neighbors attached to the same ISATAP link. From
an IEMMEI node's perspective, the extent of an ISATAP link is
neighbor-dependent and may be asymmetric based on egress and ingress
directions.
Templin, et al. Expires November 4, 2004 [Page 6]
Internet-Draft IEMMEI April 2004
4.5.1 Egress Edge of the ISATAP Link
For an ip-protocol-41 packet sent on an ISATAP interface, the
theoretical egress edge of the ISATAP link occurs at the first
Network Address Translator (NAT) along the forward path that would
rewrite the packet's IPv4 destination address (or, at the IPv6
neighbor that would decapsulate the packet if there is no such NAT).
The ISATAP link cannot extend beyond this theoretical edge, since
this would entail crossing an administrative boundary into a
different addressing realm, i.e., into a different site. Therefore,
the NAT at the theoretical egress edge of the ISATAP link should be
configured as a site border ISATAP router.
In practice, any intermediate NATs along the forward path to the
decapsulator that rewrite the packet's IPv4 source address (but not
the destination address) would require a simple modification to
support extension of the ISATAP link to its theoretical egress edge.
In particular, each such intermediate NAT should also rewrite the
embedded IPv4 address (if any) in the packet's IPv6 source address.
When the source address is rewritten, the mapping should be cached
for future reference based on the packet's Flow Label field (see:
section 4.4).
4.5.2 Ingress Edge of the ISATAP Link
For an ip-protocol-41 packet received on an ISATAP interface, the
theoretical ingress edge of the ISATAP link occurs at the last NAT
along the reverse path that rewrote the packet's IPv4 destination
address (or, at the IPv6 neighbor that encapsulated the packet if
there is no such NAT). This point may be topologically "closer" to
the IEMMEI node than the theoretical egress edge.
In practice, any NATs along the reverse path to the encapsulator that
re-write the packet's IPv4 destination address would require a simple
modification to support extension of the ISATAP link to this
theoretical ingress edge. In particular, each such NAT should also
rewrite the embedded IPv4 address (if any) in the packet's IPv6
destination address. When the destination address is rewritten, the
mapping should be determined by consulting previously cached values
based on the packet's Flow Label field (see: sections 4.4 and 4.5.1).
4.5.3 Legacy NAT Traversal
When legacy NAT boxes that do not support these simple modifications
are in the forward or reverse paths, IEMMEI nodes should use
encapsulations that provide explicit NAT traversal (e.g., [TEREDO]).
Templin, et al. Expires November 4, 2004 [Page 7]
Internet-Draft IEMMEI April 2004
4.6 Tunnel MTU and Fragmentation
Due to well-known issues with path MTU discovery [RFC2923],
applications may see greater performance by either only sending
packets that are no larger than 1280bytes or by operationally
disabling path MTU discovery such that the IP layer will fragment
large packets to the minimum IPv6 MTU of 1280bytes ([RFC3542],
section 11). Even so, packets/fragments encapsulated by the IEMMEI
driver that are no larger than 1280 bytes may still require host-
based IPv4 fragmentation, e.g., when an underlying link has a small
IPv4 MTU [BCP48]. While this host-based fragmentation is not
considered harmful, unmitigated IPv4 fragmentation caused by the
network can cause poor performance [FRAG]. For example, since the
minimum IPv4 fragment size is only 8 bytes, network middleboxes could
shred a single 1280 byte encapsulated packet into as many as 160 IPv4
fragments with obvious negative performance implications.
When an IEMMEI node experiences poor performance related to excessive
network-based IPv4 fragmentation along a path, it can reduce the size
of the tunneled packets it sends until a size that yields improved
performance is found. A lower bound of 68 bytes is used in this
packet size determination, since every Internet module is expected to
forward 68 byte datagrams without further IPv4 fragmentation.
Appendix B provides informative text on the derivation of the 1280
byte IPv6 minimum MTU.
Appendix C provides informative text on an optional IPv4 reassembly
cache management procedure that decapsulators can use to improve
efficiency.
4.7 Decapsulation/Filtering
IEMMEI nodes typically arrange for the IEMMEI driver to receive all
encapsulated packets (see: section 4.1.2) for which the node
configures a matching tunnel endpoint. For each encapsulated packet
received, the IEMMEI driver uses the decapsulation and filtering
specifications associated with the given encapsulation type.
Templin, et al. Expires November 4, 2004 [Page 8]
Internet-Draft IEMMEI April 2004
5. IEMMEI Node Deployment Considerations
IEMMEI nodes should support "ad-hoc" deployment in arbitrary
networked environments. In other words, IEMMEI nodes should be able
to discover enough information about their environment at boot time
to automatically configure themselves for operation. Such information
includes the addresses of site border gateways, the addresses of DNS
recursive name servers, etc. An IEMMEI node should also be prepared
to act as a site border router/bridge (or, "RBridge"
[RBRIDGE][NDPROXY]), as a mobile RBridge, or as a simple host
depending on its situational orientation.
IEMMEI nodes that connect to the global Internet (e.g., via an ISP, a
3GPP network, etc.) should automatically configure themselves as site
border RBridge/servers, i.e., they should configure themselves as
IPv6 RBridges, and configure DHCPv6 services
[RFC3315][RFC3633][RFC3736] to support their associated hosts.
Similarly, IEMMEI nodes with associated hosts that do not connect
directly to the global Internet should obtain configuration
information from an upstream RBridge/server (including prefix
delegations) and configure themselves as edge RBridge/servers for
logical IP subnets (LISs) within the parent site, i.e., they should
configure themselves as an IPv6 RBridge and configure DHCPv6 services
to support nodes on their downstream links. In this way, IEMMEI nodes
can automatically configure themselves as site border RBridge/servers
for recursively-nested "sites within sites".
When an IEMMEI node configures itself as a site border
RBridge/server, but does not receive a prefix delegation from an
upstream provider, it should configure a unique local prefix space
[UNIQUE] for downstream delegation. Unique local prefixes should also
be used for intra-site and/or intra-organizational communications.
IEMMEI nodes that might encounter neighbors on a downstream link,
including those not configured as site RBridge/servers, should
provide a basic L2 packet forwarding service (i.e., an L2 bridging
service) if possible within constraints such as memory, battery
power, RF link quality, etc. In order to adapt to the dynamically-
changing network neighborhood and provide the appropriate L2 packet
forwarding service, capable IEMMEI nodes should enable packet
forwarding and use an efficient dynamic route discovery protocol such
as those developed in the IETF MANET working group
[RFC3561][RFC3626][RFC3684][DSR]. Unification of aspects of these new
protocols with an efficient flooding mechanism and existing
routing/bridging protocols (including OSPF [RFC2740] and IEEE 802.1D
spanning tree [STP]) is currently under investigation.
Templin, et al. Expires November 4, 2004 [Page 9]
Internet-Draft IEMMEI April 2004
6. Native IPv6 vs IPv6-in-IPv4 Encapsulation
IEMMEI nodes 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 is detected based on whether/not a neighbor
responds to native IPv6 neighbor discovery messages sent over the L2
media.
To normalize issues associated with bridging dissimilar media (e.g.,
path MTU black holes), and to support IPv6 neighbor discovery
security mechanisms, IEMMEI nodes should use IPv4 as the common
logical L2 encapsulation layer for sending IPv6 packets to neighbors
that do not attach to the same physical L2 media segment.
7. Security considerations
When the operational extensions described in this document are used,
the Security Considerations in their respective references apply.
Securing mechanisms for IPv6 neighbor discovery messages (e.g.,
[CGA], [SEND], etc.) are used according to the trust model
appropriate for the given deployment scenario [SENDPS].
8. Acknowledgments
The ideas in this document are not original; the author acknowledges
the original architects.
The following individuals are acknowledged for their helpful insights
on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound,
Ralph Droms, Alain Durand, Tim Gleeson, Jun-ichiro itojun Hagino,
Brian Haberman, Bob Hinden, Christian Huitema, Eddie Kohler, Kevin
Lahey, Hakgoo Lee, Matt Mathis, Jeff Mogul, Erik Nordmark, Soohong
Daniel Park, Chirayu Patel, Michael Richardson, Pekka Savola, Hesham
Soliman, Mark Smith, Dave Thaler, 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
Templin, et al. Expires November 4, 2004 [Page 10]
Internet-Draft IEMMEI April 2004
Appendix A. Major Changes Since -00
- added definition for "ISATAP link"
- replaced "configured tunnel interface" with "tunnel endpoint"
in several places
- revised "NAT Traversal" section into new section on
"ISATAP link and NAT Interactions"
- shortened "Decapsulation/Filtering" section
Appendix B. 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. The
size was chosen to allow extra room for link layer encapsulations
without exceeding the Ethernet MTU of 1500 bytes, i.e., the practical
physical cell size of the Internet. The 1280 byte MTU also provides a
fixed upper bound for the size of IPv6 packets/fragments with a
maximum store-and-forward delay budget of ~1 second assuming worst-
case link speeds of ~10Kbps [BCP48], thus providing a convenient
value for use in reassembly buffer timer settings. Finally, the 1280
byte MTU allows transport connections (e.g., TCP) to configure a
large-enough maximum segment size for improved performance even if
the IPv4 interface that will send the tunneled packets uses a smaller
MTU.
Templin, et al. Expires November 4, 2004 [Page 11]
Internet-Draft IEMMEI April 2004
Appendix C. Optional IPv4 Reassembly Cache Management Procedure
Decapsulating IEMMEI nodes can provide greater efficiency for tunnels
that incur excessive network-based IPv4 fragmentation by implementing
a simple IPv4 reassembly cache management procedure. When the initial
fragment of an encapsulated packet arrives, the packet's IPv4
reassembly timer is set to 1 second (i.e., the worst case store-and-
forward delay budget for a 1280 byte packet). If an encapsulated
packet's IPv4 reassembly timer expires:
- If enough contiguous leading bytes of the packet have arrived
(e.g., see: [UDPLITE]), reassemble the packet using zero-filled or
heuristically-chosen replacement data bytes in place of any
missing fragments. (Otherwise, garbage-collect the reassembly
buffer and return from processing.)
- Mark the packet as "INCOMPLETE", and also mark it with an
"ACTUAL_BYTES" length that encodes the actual number of data bytes
in fragments that arrived.
- Deliver the packet to the IEMMEI driver, and do not send an ICMPv4
"time exceeded" message.
When the IEMMEI driver processes this "INCOMPLETE" packet, it can
send a message (e.g., an IPv6 Router Advertisement with an MTU
option) to inform the far end of the tunnel that network-based
IPv4 fragmentation may be causing poor performance along the path.
The "INCOMPLETE" packet can also be forwarded to the final
destination since some applications might realize greater
efficiency by accepting partial information and requesting
selective retransmission of missing portions, e.g., when [UDPLITE]
is used.
Normative References
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-
ngtrans-isatap, Work in Progress, April 2004.
Templin, et al. Expires November 4, 2004 [Page 12]
Internet-Draft IEMMEI April 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.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[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.
[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.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2740] Colton, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
Tunnel Broker", RFC 3053, 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,
Templin, et al. Expires November 4, 2004 [Page 13]
Internet-Draft IEMMEI April 2004
"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.
[RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 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 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.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3736] R. Droms, "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga, Work in Progress, February, 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.
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3, Work in Progress, February, 2004.
[MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, Work in
Progress, February 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.
[RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent
Templin, et al. Expires November 4, 2004 [Page 14]
Internet-Draft IEMMEI April 2004
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, October 2003.
[SENDPS] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery Trust Models and Threats", draft-ietf-send-psreq, Work in
Progress, October 2003.
[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.
[UDPLITE] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The UDP-Lite Protocol", draft-ietf-tsvwg-udp-lite, Work
in Progress, August 2003.
[UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress,
January 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
Full 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.
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,
Templin, et al. Expires November 4, 2004 [Page 15]
Internet-Draft IEMMEI April 2004
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
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 currently provided by the
Internet Society.
Templin, et al. Expires November 4, 2004 [Page 16]