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 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 currently provided by the Internet Society. Templin, et al. Expires November 4, 2004 [Page 16]