Mobile IP Working Group Alper E. Yegin Internet Draft Mohan Parthasarathy Category: Standards Track Carl Williams Expires: March, 2001 Sun Microsystems September, 2000 Mobile IPv6 Neighborhood Routing for Fast Handoff draft-yegin-mobileip-nrouting-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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. Abstract The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 1 Internet Draft Neighborhood Routing 25 September 2000 Contents Status of this Memo 1 Abstract 1 1. Introduction 3 2. Terminology 3 3. Protocol Operation 4 3.1. Access Router Sending Router Advertisements . . . 4 3.2. MN Processing . . . . . . . . . . . . . . . . . . 5 3.3. CN Processing . . . . . . . . . . . . . . . . . . 5 3.4. Access Router Processing Data Packets . . . . . . 6 3.5. Home Agent Processing . . . . . . . . . . . . . . 6 3.6. Other Details . . . . . . . . . . . . . . . . . . 6 4. New Requirements for IPv6 Nodes 7 4.1. Access Routers . . . . . . . . . . . . . . . . . . 7 4.2. Mobile Node . . . . . . . . . . . . . . . . . . . 7 4.3. Correspondent Nodes . . . . . . . . . . . . . . . 8 4.4. Home Agent . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Extensions 9 5.1. Router Advertisement . . . . . . . . . . . . . . . 9 5.2. Binding Update . . . . . . . . . . . . . . . . . . 10 5.3. New Routing Header . . . . . . . . . . . . . . . . 10 6. Security Considerations 14 7. Conclusion 14 References 15 Author's Addresses 15 Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 2 Internet Draft Neighborhood Routing 25 September 2000 1. Introduction MIPv6 draft [1] describes how a MN should send a BU after moving to a new link. When MN is attached to a new link, it configures a new CoA and sends BUs to CNs and HA. Although this would establish "connectivity" as soon as BUs are received by CNs and HA, this method doesn't produce acceptable results for communications that require certain characteristics, such as minimum latency and packet loss . During the time between when MN detaches from old link and the time when BUs are received, MN is "unreachable". All the packets in flight during this period end up at the old link and get dropped. The unreachability problem is due to the lack of knowledge at the CNs and HA about the possible movement of the MN. By the time binding update reaches the CNs and HA, all packets that were sent to the old location of the mobile node are lost. If the MN had provided the information about its neighborhood and if the packet can be routed in that neighborhood, then MN will always be reachable. The "neighborhood" is an area in which the MN may visit in the immediate future. It consists of the known current link and a number of possible other links that the MN might move to next. With this information the CNs and HA will send packets to the "neighborhood" for the MN. Since the MN will be in the "neighborhood" even after detaching from the old link, packets will be delivered successfully. Layer 2 (L2) of access router (AR) can figure out a list of possible next links that MN might visit in the immediate future, by using the layout of ARs in the domain and measurements (e.g. direction of MN), and applying some heuristics. When AR communicates this information to MN, MN can send an extended BU to CNs and HA, telling them about its neighborhood. So with this extended information CNs and HA can send packets to this neighborhood, which tries to reach the MN at the known current link first, and then at the other links in the neighborhood. Packets can be routed to multiple links using a new routing header described later in this document. In this manner, MN can notify CNs and HA where it is now and where else it might be in the immediate future. Instead of "reactively" updating the system to establish connectivity as soon as MN moves, this protocol "proactively" informs CNs and HA to cover MN's possible movements, and refine in time. And although no other entity keeps track of instant movements of MN, it stays reachable. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Basic Mobile IPv6 terminology is used as defined in [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 3 Internet Draft Neighborhood Routing 25 September 2000 Additionally, the following terminology is used in this draft: Access Router (AR) The closest router to the mobile node in the visited domain that the mobile node uses to access the network [3]. Neighborhood The ordered list of links which includes the link that MN is currently attached to and a number of other links that MN may visit in the immediate future. Since MN may visit links that are more than one hop away, other links in the neighborhood don't have to be adjacent to current link of attachment. Neighborhood is determined by the L2 of access router MN is currently attached to. Current Care-of-Address Care-of-Address configured using the prefix of the link that MN is currently attached to. Possible Next Link (pn-link) Any of the links in a neighborhood other than the one that MN is currently attached to. Possible Next Prefix (pn-prefix) Prefix of one of the pn-links. Possible Next Care-of-Address (pn-CoA) Care-of-Address configured using one of the pn-prefixes. 3. Protocol Operation This section describes how this proposed protocol works. It uses an example where MN is moving through a series of links: link1, link2, link3, etc. link1 is attached to AR1, and uses the prefix prefix1. Care-of-Address configured by using prefix1 is CoA1. Similarly, link2 is attached to AR2, uses prefix2, and MN configures CoA2 by using prefix2. 3.1. Access Router Sending Router Advertisements Layer 2 of the AR comes up with a list of links that an attached MN might be visiting in the immediate future, by using the layout of ARs in the domain and measurements (e.g. direction of MN), and applying some heuristics. This list would be the "neighborhood of MN". Neighborhood is conveyed to layer 3 in the form of a list of links (e.g. "link1, link2, link3"). Current access router, AR1, needs to map these links to prefixes advertised on each link. One possible way of implementing this mapping could be in the form of a table. This table can be a local one or a centrally maintained one. Note that even without this extension to the protocol, AR1 uses such Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 4 Internet Draft Neighborhood Routing 25 September 2000 a table to advertise its own prefixes on various links. That table can be extended to include other links a MN may visit in this domain. AR1 comes up with a list of prefixes, prefix1, prefix2, etc. after a successful lookup. The first prefix is the one for the link MN is physically attached to. The rest are the prefixes for possible next links in the order of descending possibility. Note that this list is per MN, and its elements and their order can change in time. Now AR1 can send a router advertisement (RA) to MN. This RA includes a prefix information option to carry prefix1 as current prefix, and a number of others to carry pn-prefixes (see section 5.1 3.2. MN Processing When MN receives an RA with pn-prefixes, it can configure one CoA for each prefix. CoA1 will be current CoA, and others pn-CoAs. All the pn-CoAs are marked as deprecated, so that they are not used as source addresses in outgoing packets. Now MN can receive packets that are sent to any of its CoAs. Next, MN sends a new BU to CNs and HA. This BU, in addition to current CoA, contains one pn-CoA destination option sub-option for all pn-CoAs (see section 5.2). 3.3. CN Processing After receiving a BU with pn-CoAs, whenever CN wants to send a packet to MN, it includes a routing header extension in the packet. CN uses new routing header type 1 (instead of type 0) that includes all CoAs as intermediate hops (see section 5.3). The destination of the packet is CoA1, and the routing header is initialized to contain CoA2, CoA3, ..., home address of MN as the route segments. The routing infrastructure makes a best effort to route packet through intermediate hops. But, if a router on the same link as next hop (such as AR1) determines that host at next hop (such as MN at CoA1) is not reachable, it can simply skip this hop, update the routing header, and forward the packet to the following hop (MN at CoA2). If MN is not attached to any of the links, last AR forwards the packet to the home link to be intercepted by HA since the last route segment in the routing header is the home address of the MN (see section 3.5 for more on this). Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 5 Internet Draft Neighborhood Routing 25 September 2000 3.4. Access Router Processing Data Packets When a packet with type 1 routing header arrives, AR1 will forward it to MN for a successful delivery if MN is still attached to link1. It's assumed that L2 of AR can determine whether a MN is attached or not, and convey this information to L3. If MN had already moved to link2 before the packet arrives at AR1, then AR1 would know that MN at CoA1 is no longer attached to link1. AR1 would process the routing header, so that CoA1 is skipped, and the packet is forwarded to next hop, CoA2. This time AR2, seeing that MN at CoA2 is attached to link2, forwards the packet to MN. Although sender of the packet didn't know the exact location of MN, the packet is delivered successfully by using the information about where else MN might be located currently. 3.5. Home Agent Processing As stated in [1], HA intercepts packets from various CNs and tunnels them to MN. Additionally, if HA has the knowledge of pn-CoAs, it puts a routing header type 1 in the encapsulating packet's header. The destination of this packet is CoA1, and the routing header is initialized to contain CoA2, CoA3, ... as the route segments. This way, tunneled packet will be delivered to MN at one of the CoAs. Note that since home address of MN is not included in the routing header (unlike CN processing, see section 3.3), this packet will never be forwarded back to the home link. One special case MAY need to be handled by HA. When a packet from CN with routing header type 1 is not delivered at any of CoAs, it ends up at the HA to be intercepted. If HA blindly processes, the tunneled packet could traverse the same ARs as the original packet and get dropped at the last AR. In order to prevent an extra transmission, HA MAY implement an optional check. HA MAY compare its knowledge of CoAs with the one derived from the routing header of the intercepted packet. If they are same, HA MUST discard the packet. This shows CN already tried the possibilities that HA would try. Sending the packet again won't deliver the packet. This can be the case when MN moved to a different domain, and neither CN nor HA has received the most current BU yet. 3.6. Other Details The neighborhood of MN changes as MN moves within and across links. When MN moves within the same link, current CoA stays the same but pn-CoAs may change. Current CoA changes only when MN moves to another link. Furthermore, each CoA has an associated lifetime and they are removed when their lifetime expires. Each of such changes to the list of CoAs can trigger a new BU transmission. MN proactively makes sure each CN and HA has enough information to Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 6 Internet Draft Neighborhood Routing 25 September 2000 deliver packets wherever it might move next by refining its list of CoAs. In this protocol, if AR doesn't send np-prefixes, or MN doesn't recognize np-prefixes, or MN doesn't send np-CoA sub-options, or CN and HA don't recognize np-CoA sub-options, then this protocol automatically converges to the one in draft [1]. None of the entities need to detect whether new protocol is recognized at others or not. Whenever L2 determines that MN will be staying at the current link for an extended period of time (due to low speed, very large cell, etc.), system can use only one CoA as in [1]. System can use the new protocol to configure pn-CoAs as soon as a possible move to another link is detected. Definition of "immediate future", the heuristic used to come up with a list of next possible links, and maximum number of CoAs to configure on MN are system wide tuning parameters. 4. New Requirements for IPv6 Nodes This protocol extension requires modification to the Access Routers, the Mobile Node, the Correspondent Nodes, and the Home Agent. The proposed MIPv6 extensions are optional to basic Mobile IPv6; networking elements can function with support of the new option independent to any other networking entity providing support. If the extensions are not supported by AR, MN, CN, and HA, the operation will default to the base protocol as defined in [1]. 4.1. Access Routers L3 of AR MUST be capable of interfacing with L2 to obtain a list of links that the MN may be visiting next. The actual interface is beyond the scope of this document. The AR MUST be able to map each link to the prefix information and also be capable of sending router advertisements with the N bit set for these prefixes. Additionally, L3 MUST be capable of determining if a MN is attached to its link or not. The AR MUST be able to process data packets containing the type 1 routing header extension. 4.2. Mobile Node The MN MUST recognize the use of the prefix information option with N bit set so that the extended protocol can be used. The MN MUST be able to configure one CoA for each prefix it receives. The MN MAY perform further processing on the list of prefixes it receives from the AR. This processing MAY include the reordering or reducing the Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 7 Internet Draft Neighborhood Routing 25 September 2000 list of prefixes via some heuristic. The mobile node MUST be able to send a BU with pn-CoA sub-option. The MN MUST be able to process type 1 routing header extensions. 4.3. Correspondent Nodes The CN MUST be able to recognize a BU with pn-CoA sub-option. The CN MUST be capable of maintaining binding cache entries based on the BU with pn-CoA sub-option. The CN MUST be able to send a type 1 routing header extension whenever sending packets to the MN. 4.4. Home Agent The HA MUST be able to recognize BU with pn-CoA sub-option. The HA MUST be capable of maintaining a binding cache entries based on the neighborhood binding updates. The HA MUST be able to send a router header extension of type 1 for all the intercepted packets that are tunneled. The HA MAY also check the router headers in the intercepted packets to handle the case specified in section 3.5. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 8 Internet Draft Neighborhood Routing 25 September 2000 5. Protocol Extensions 5.1. Router Advertisement This section defines a new bit as part of the prefix information that is sent as part of the router advertisement [4]. Access routers set this bit to indicate that the prefix contained in this option is a pn-prefix (see section 3.1). MN can use this information to configure the additional care of addresses and also use it in the binding updates to indicate its neighborhood. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|N|Resvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Prefix Information Option N : This indicates that the contained prefix belongs to a router where the MN could possibly be visiting in in the near future. All other fields has the same meaning as that of [4]. If the N bit is not understood by the mobile node, it MUST skip the prefix contained in the option. Thus, this mechanism provides backward compatibility to mobile nodes that does not understand the bit and hence falls back to the old scheme mentioned in the draft [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 9 Internet Draft Neighborhood Routing 25 September 2000 5.2. Binding Update This section defines a new destination option sub-option for the binding update that lists the possible next care of addresses to be used by the HA or CNs in routing header type 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address n + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Possible Next Care-of-Address Sub-Option (alignment requirement: 8n+6) len : n * 16 where n is the number of care of addresses. The source address of the BUs will be the current CoA. If this sub-option is not understood by the CN or HA, it MUST be skipped as mentioned in the draft [1]. Thus, this mechanism provides backward compatibility to nodes that does not understand the new sub-option and hence falls back to the old scheme mentioned in the draft [1]. 5.3. New Routing Header This proposal defines a new routing header type 1 which is used by CNs and HA when sending packets to MN. This MUST be sent only if CN and HA received a binding update with the new possible next Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 10 Internet Draft Neighborhood Routing 25 September 2000 care-of-address sub-option defined in section 5.2. The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. The Routing header is identified by a Next Header value of 43 in the immediately preceding header, and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Routing Header Extension All the fields of the routing header remain the same as in type 0 [5] except that the Routing Type is 1. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 11 Internet Draft Neighborhood Routing 25 September 2000 The Type 1 Routing header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=1| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[2] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Type 1 Routing Header Extension The processing of Routing header type 1 is almost the same except for the difference noted below. A Routing header type 0 is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. But in the case of routing header type 1, the last hop router that forwards the packet to the node identified by the Destination Address of the IPv6 header also processes the packet if the packet can't be delivered. If it knows readily that the node identified by the destination address is reachable, it sends the Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 12 Internet Draft Neighborhood Routing 25 September 2000 packet. If it is not reachable, it swaps the destination addresses with the next hop address contained in the route specific data, as it does with routing header type 0 and forwards the packet to the new destination address. The router that determines that the packet being forwarded is on-link, checks to see whether the destination is reachable or not. It checks for a routing header type 1 and processes it only if the destination is not reachable. The processing is as follows : If (packet being forwarded is on-link) { if (destination is reachable) { Send the packet(*) } else if (routing header type 1 present) { Process the routing header type 1 similar to routing header type 0. Swap the IPv6 destination address with the next hop address in the option and forward the packet to the new destination. } else { drop the packet. } } else { forward the packet using the default IPv6 rules. } (*)If the destination is reachable and the packet was sent to the destination connected on-link, the node receiving the packet would see one of the care of addresses (it sent in the binding update) in the destination field of the IPv6 header, depending on which link it receives the packet. It processes the packet in the following way: if (Segments Left == 0) { Send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field, and discard the packet } else { Swap the Destination address with the next hop address and feed the packet for transmission. As all the addresses belongs to this node, this will eventually stop when the last hop address is processed. } Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 13 Internet Draft Neighborhood Routing 25 September 2000 6. Security Considerations Binding updates MUST be protected by IPsec Authentication header. When Routing header type 1 is used and IPsec is also used, routing header should be protected by IPsec. The processing of routing header type 1 is the same as routing header type 0 in the context of IPsec. 7. Conclusion Standard routing expects a host to be reachable at a certain link. New protocol extends this to reaching a host at one of the possible links it might be attached at that time. All the traffic can be delivered to MN at any of those links by MN knowing which other links it might be moving to and informing CNs and HA about them. AR determines this link information using L2 knowledge and sends it to MN. This new protocol is a natural extension to the one in MIPv6 draft [1]. It doesn't define new networking entities. The data flow is the same as specified in the MIPv6 draft [1]: MN configures CoAs by using the prefixes in RAs, MN informs CNs and HA by use of BUs, CNs use routing header to deliver packets to MN, and HA intercepts packets from CNs and tunnels them. The new protocol shows up as extensions to router advertisement, binding update, and routing header. These extensions are ignored when they are not recognized by any of the networking entities, and the system automatically converges to regular MIPv6. As soon as MN moves to a new link, it can start sending and receiving packets without anyone else keeping track of instant movements of MN. This protocol allows the MIPv6 infrastructure to dynamically adapt itself to changing conditions and different deployment scenarios. If handoffs are happening frequently (fast MN movement, too small cells, etc.), MN sends more CoAs in its BUs. If no handoff is expected for a while, none of the new extensions are used, therefore only one CoA is sent and the system becomes what's described in [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 14 Internet Draft Neighborhood Routing 25 September 2000 References [1] D. Johnson and C. Perkins. "Mobility support in IPv6", draft-ietf-mobileip-ipv6-12.txt, April 2000. [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments (Best Current Practice) 2119, March 1997. [3] J. Malinen and C. Perkins. "Mobile IPv6 Regional Registrations", draft-malinen-mobileip-regreg6-00.txt, July 2000. [4] T. Narten, E. Nordmark, and W. Simpson. "Neighbor Discovery for IP Version 6 (IPv6)", Request for Comments (Draft Standard) 2461, December 1998. [5] S. Deering and R. Hinden. "Internet Protocol, Version 6 (IPv6)", Request for Comments (Draft Standard) 2460, December 1998. Author's Addresses Alper E. Yegin Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 4013 fax: +1 650 786 5896 email: Alper.Yegin@eng.sun.com Mohan Parthasarathy Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 8885 fax: +1 650 786 5896 email: Mohan.Parthasarathy@eng.sun.com Carl Williams Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 5186 fax: +1 650 786 5896 email: Carl.Williams@eng.sun.com Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 15