Network Working Group F. Templin Internet-Draft Nokia Expires: October 16, 2004 April 16, 2004 ISATAP Extensions for Mobility, Multihoming and Efficiency Improvement (IEMMEI) draft-templin-v6ops-iemmei-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 October 16, 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 interface management abstraction similar to the ATM Permanent/Switched Virtual Circuit model. Nodes can use these extensions to realize mobility, multihoming and efficiency improvements not available via the ISATAP base specification alone. Templin, et al. Expires October 16, 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 interface management abstraction similar to the ATM Permanent/Switched Virtual Circuit model [RFC2492]. Nodes that use these extensions can realize mobility, multihoming and efficiency improvements not available via the ISATAP base specification alone. 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 router/servers and their associated hosts. 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 IPv6 Tunnel Broker abstraction [RFC3053] for configuring/managing tunnels. IEMMEI driver: an IEMMEI node's network module that provides an API for control plane signaling and tunnel configuration/management. Also provides a packet encapsulation/decapsulation engine, and an embedded gateway function. Templin, et al. Expires October 16, 2004 [Page 2] Internet-Draft IEMMEI April 2004 3. IEMMEI Conceptual Model ISATAP interfaces are IPv6 interfaces that provide a point-to- multipoint 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 provides an IPv6 Tunnel Broker abstraction [RFC3053] and configures/manages tunnel endpoints using IPv6 neighbor discovery messages for control plane signaling. Each such configured 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 configured tunnel provides a point-to-point connection between peers that can support multiple applications and multiple instances of each application. Templin, et al. Expires October 16, 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 October 16, 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 create configured tunnels dynamically during runtime as an ISATAP interface's associated logical interface, e.g., via the IEMMEI daemon acting as an IPv6 Tunnel Broker. Each configured tunnel interface 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 mapping for neighbors on ISATAP interfaces. 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 the neighbor cache. Using these extensions, the IPv6 neighbor cache(s) 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. 4.3 Flow Labels in IPv6 Neighbor Discovery Messages 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 Templin, et al. Expires October 16, 2004 [Page 5] Internet-Draft IEMMEI April 2004 messages to the same value that appears in the Flow Label field of messages that triggered the advertisement. 4.4 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.5 NAT Traversal Simple IPv6-in-IPv4 encapsulation provides sufficient functionality to support communications between nodes with global IPv4 addresses, between nodes that reside within the same site (e.g., the same enterprise network), or when the encapsulating node's site is extended via bridge-like proxies [NDPROXY] over the path to the decapsulator. When legacy NAT boxes are in the path, encapsulations that provide explicit NAT traversal mechanisms (e.g., [TEREDO]) may be needed. 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 Templin, et al. Expires October 16, 2004 [Page 6] Internet-Draft IEMMEI April 2004 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 is the apparent tunnel endpoint. The IEMMEI driver uses the decapsulation specification in ([ISATAP], section 7.2) and processes each packet according to the following steps: 1. Locate the correct tunnel interface to receive the packet. If not found, silently discard the packet and return from processing. 2. If the tunnel uses header compression, reconstitute headers. If header reconstitution fails, silently discard the packet and return from processing. 3. Verify that the packet's IPv4 source address is correct for the encapsulated IPv6 source address. If the IPv4 source address is incorrect, silently discard the packet and return from processing. 4. Decapsulate the packet and perform IPv6 source address validation and ingress filtering. If the packet was not discarded due to source address validation/filtering, and the packet has traversed a NAT, rewrite the IPv6 source address according to the specification for the appropriate encapsulation extension (e.g., [TEREDO], etc.). 5. If the packet is destined to the localhost, determine the correct transport protocol listener. Otherwise, perform an IPv6 forwarding table lookup and site border/firewall filtering (see: [UNIQUE], section 6). (If the packet cannot be delivered, send an appropriate ICMPv6 Destination Unreachable message ([ICMPV6], section 3.2) to the packet's source, then discard the packet and return from processing.) Templin, et al. Expires October 16, 2004 [Page 7] Internet-Draft IEMMEI April 2004 6. If the packet was destined to a remote host, attempt to forward the packet. (If the packet is larger than LinkMTU for the outgoing IPv6 interface, drop the packet and send an ICMPv6 "packet too big" message [RFC1981].) Return from processing. If the packet was destined for the localhost, apply security processing and place the packet in a buffer for upper layers. The buffer can be, e.g., the IPv6 reassembly cache, an application's mapped data buffer, etc. If there is clear evidence that upper layer reassembly has stalled, send an ICMPv6 Packet Too Big message [RFC1981] to the packet's source address with an MTU value likely to incur successful reassembly. 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 router/servers, 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 a DHCPv6 [RFC3315] server to provide prefix delegation services [RFC3633], stateless autoconfiguration services [RFC3736], etc. for 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 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 a DHCPv6 relay/server to provide service for 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, Templin, et al. Expires October 16, 2004 [Page 8] Internet-Draft IEMMEI April 2004 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. 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]. Templin, et al. Expires October 16, 2004 [Page 9] Internet-Draft IEMMEI April 2004 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 Appendix A. Major Changes Initial draft version (-00); derived from 'draft-ietf-ngtrans- isatap-20'. 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 October 16, 2004 [Page 10] 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 October 16, 2004 [Page 11] 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 October 16, 2004 [Page 12] 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., and A. Williams, "Design for a Routing Bridge", Templin, et al. Expires October 16, 2004 [Page 13] Internet-Draft IEMMEI April 2004 draft-perlman-zerouter-rbridge-00.txt (Expired), June 2003. [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 October 16, 2004 [Page 14] 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 October 16, 2004 [Page 15]