Network Working Group M.Parthasarathy Internet Draft Basavaraj Patil Document: draft-mohan-nflm-proto-00.txt Rajeev Koodli Expires: April 2006 Nokia October 2005 Network-based Fast Handovers for Local Mobility (NFLM) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Local Mobility is IP mobility over a restricted geographical and administrative domain. This document describes a network based localized mobility management protocol which does not require host involvement while moving within such a local mobility domain. <Parthasarathy> Expires April 2006 [Page 1]
Network-based Fast Handovers for local mobility October 2005 Table of Contents 1.0 Introduction..................................................2 2.0 Terminology...................................................3 3.0 Requirements for LMM..........................................4 4.0 IP Address Configuration......................................5 4.1 DHCPv6.....................................................6 4.2 Stateless Address Autoconfiguration........................7 4.3 Duplicate Address Detection................................7 5.0 Local Domain Configuration....................................8 6.0 Protocol Details..............................................8 6.1 Predictive handoff.........................................9 6.2 Reactive handoff..........................................10 7.0 Packet Forwarding in local domain............................12 8.0 Message Formats..............................................12 8.1 MN identifier option......................................12 8.2 Handover Initiate message.................................13 8.3 Handover Acknowledgement message..........................14 8.4 Fast Binding Update.......................................14 8.5 Fast Binding Acknowledgement..............................14 9.0 IANA Considerations..........................................14 10.0 Security considerations.....................................15 11.0 Normative References........................................16 12.0 Informative References......................................16 13.0 Acknowledgments.............................................16 14.0 Author's Addresses..........................................16 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................17 Copyright Statement..............................................18 Acknowledgment...................................................18 1.0 Introduction Localized mobility management has been addressed by various protocols like HMIPv6 [3]. These protocols involve the host to manage the mobility on their own when moving within the local domain. This document describes a protocol where the mobility is managed by the network without the involvement of the host. The protocol is based on FMIPv6 [2] message exchanges. In FMIPv6 [2], the handoff is either initiated by the network or the mobile node. In either case, the host sends a fast binding update (FBU) to setup a tunnel with the access router on the previous link. By establishing such a tunnel, the mobile node ensures that the packets can keep flowing as it updates the home agent and the correspondent node using the Mobile IPv6 [10] signaling over the Internet, including the Return Routability <Parthasarathy> Expires January 2006 [Page 2]
Network-based Fast Handovers for local mobility October 2005 procedure. The protocol described in this document does not involve the host to send the FBU; instead the Access router sends the FBU to a Mobility Anchor Point (MAP) on behalf of the mobile node. This ensures that the packets can continue to flow from the MAP towards the new access router while the mobile node does not even know that it has changed access routers. We refer to this protocol as Network- based Fast Handovers for Local Mobility (NFLM). This document is organized as follows. First, it discusses the requirements of the localized mobility management protocol(LMM). Next, it discusses the IP address configuration mechanism followed by the protocol description. All the messages defined in this document are taken from [2]. There are no new messages defined here. There are a few extra options needed by NFLM which are defined in Section 8.0. 2.0 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 [1]. The following terminology and abbreviations are taken from [2] and modified for NFLM. Mobile Node (MN) A Mobile IPv6 host. Access Point (AP) A Layer 2 device connected to an IP subnet that offers wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also referred to as a Base Station Subsystem ID (BSSID). Access Router (AR) The MN's default router. Previous Access Router (PAR) The MN's default router prior to its handover. New Access Router (NAR) The MN's default router subsequent to its handover. Previous CoA (PCoA) <Parthasarathy> Expires January 2006 [Page 3]
Network-based Fast Handovers for local mobility October 2005 The MN's Care of Address valid on PAR's subnet. Handover The process by which a mobile node moves from one point of attachment to another point of attachment, resulting in the MN terminating existing connectivity and establishing new IP connectivity. Fast Binding Update (FBU) A message from the NAR instructing the MAP to redirect traffic (toward NAR). Fast Binding Acknowledgment (FBack) A message from the MAP in response to an FBU. Handover Initiate (HI) A message from the PAR to the NAR regarding an MN's handover. Handover Acknowledge (HAck) A message from the NAR to the PAR as a response to HI. MN identifier An identifier to uniquely identify a mobile node in the local domain. This can be a link-layer address or some other identifier depending on the access technology. MAP Mobility Anchor Point. The router that maintains reachability for hosts in the local domain using host routes. 3.0 Requirements for LMM The requirements for a localized mobility management protocol can be considered as follows. 1) The protocol should address mobility within the local domain as shown in Figure 1 without the involvement of the host. To be more specific, the protocol is used when the MN moves between AP 2 and AP 3. 2) The host should be able to maintain the same IP address when moving within the local mobility domain. <Parthasarathy> Expires January 2006 [Page 4]
Network-based Fast Handovers for local mobility October 2005 Localized Mobility Localized Mobility Management Domain A Management Domain B +-------+ +-------+ | MAP | | MAP | +-------+ +-------+ / \ | / \ | / \ | / \ | / \ | / \ | +-----+ +-----+ +-----+ |AR A1| |AR A2| |AR B1| +-----+ +-----+ +-----+ * * * * * * * * * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ +--+ +--+ |MN|----->|MN| +--+ +--+ Local Mobility Figure 1) Localized Mobility Management Domain 3) The host should not have any involvement in its mobility management (except for advertising its presence on the new link), when moving within the local mobility domain. 4) Access Routers should be able to discover MAPs and prefixes dynamically without the need for manual configuration. 4.0 IP Address Configuration The mobile node configures the IP address when it enters the local domain for the first time. The mobile node configures the IP address as it would do when it moves to a new IP link i.e., there is nothing special required from the mobile node. Once it has configured the IP <Parthasarathy> Expires January 2006 [Page 5]
Network-based Fast Handovers for local mobility October 2005 address as described below, the MN does not have to configure a new IP address as long as it stays within the local domain. This implies that when the mobile node connects to a new access router, it should not determine that it has moved to a new IP link. Otherwise, it will configure a new IP address which should be avoided. This influences the address configuration method. Following sections describe the address configuration options. 4.1 DHCPv6 DHCPv6 [4] may be used for address configuration in the local domain. This can be enabled in different ways. . As specified in stateless autoconfiguration [6], the host attempts to use stateful autoconfiguration if no routers are present on the link. This can be achieved by turning of the router advertisements on the Access Routers. . Routers can be configured to send router advertisements without including any prefixes but setting the Managed address configuration flag (M bit) in the router advertisement. This will trigger the host to invoke DHCPv6 for address configuration. Since mobile hosts are expected to send router solicitation to detect whether they moved links or not, the latter option SHOULD be used. As specified in [4], the client MUST include the client identifier option in the DHCP request message. Any valid DHCP unique identifier specified in [4] can be used. When the client may have moved to a new link (e.g. switching wireless access point), the client should use the CONFIRM message along with the client Identifier option that was sent with the DHCP request message. The client performs DAD and declines the address if the address is used already on the link. The DHCP server SHOULD be located centrally so that it is able to assign the same address to the client as long as it remains in the local domain. The DHCP relay agent will be present on the Access routers, forwarding the DHCP messages towards the DHCP server. When the server receives the DHCP message from the relay agent, either the link-address or the interface ID option will be present. The link-address field is assigned from the interface on which the message is received from the client. If there is more than one prefix on the interface from which the packet was received, the DHCP relay agent may not be able to pick the right prefix to insert in the link- address field. The link-address field should match the prefix of the client's address in the CONFIRM request. As the server uses the link- address field to select an appropriate address for the client, <Parthasarathy> Expires January 2006 [Page 6]
Network-based Fast Handovers for local mobility October 2005 inserting a wrong link-address value can lead the server to reject the request and return NotOnLink status in its reply. Hence, this option should not be used by the relay agent unless it can insert the prefix matching the address in the CONFIRM request. The DHCPv6 relay agent may use the Interface-ID field to influence the address assignment policy on the server. As this is considered to be opaque, the agent may copy the prefix of the requested address in the CONFIRM request to the Interface-ID. Then the server may be configured to use the Interface-ID for policy assignment i.e the interface-ID SHOULD match the prefix of the requested address. 4.2 Stateless Address Autoconfiguration The client may also autoconfigure the address using the prefix information in the Router advertisements (RA) sent by the Access Router. As the client needs to keep the same address across all the links that moves in the NELMM domain, all the access routers in the local mobility domain SHOULD advertise the same set of client prefixes so that the clients believe that they have not moved at layer 3. The router advertisement normally contains prefixes that are valid for the link. The prefix information option contained in the RA has two bits for each prefix. The A bit indicates whether the prefix can be used to auto-configure an address. This bit MUST be set on at least one prefix so that the mobile nodes can autoconfigure an address. There is another bit in the RA namely the L bit which is used to determine the on-link status. As the mobile nodes roam around in the local domain keeping the same address, it is not possible to use the prefix information to determine the current point of attachment of a given node. Both the Access router and the MAP use the host routes to learn about the current Point of Attachment of the clients. Hence, the on-link flag MUST NOT be set on any prefixes. When the client configures the address for the first time, it would send a router solicitation with unspecified source address. The router advertisement MUST contain the same set of prefixes that will be advertised by all Access routers in the local mobility domain. The mobile node follows the procedure described in [5] and [6] for configuring the address. When the MN believes that it may have moved to a new link, it should send a router solicitation with the address configured earlier. This is used by the new access router to set up any tunnel if needed. 4.3 Duplicate Address Detection Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of <Parthasarathy> Expires January 2006 [Page 7]
Network-based Fast Handovers for local mobility October 2005 whether they are obtained through stateless address autoconfiguration or DHCPv6 [6]. This procedure verifies that another node on the link is not using the same address. But the LMM requirements require that the node maintains the same address in the local domain. This implies that one has to make sure that no two nodes on any link has the same address. NFLM achieves this by MAP verifying that there is only one binding for a given MN address. But as the node moves to a different link, the binding needs to be updated. If the MAP would check whether a binding exists already, the update would fail as the binding was created when the node was on a previous link. Hence, the MAP uses a unique client identifier to verify that it is the same client that moved to a new link. The security issues related to this are discussed later. 5.0 Local Domain Configuration The local domain configuration consists of two parts. 1. Discovery of MAP by Access Routers. 2. Discovery of the prefixes that needs to be advertised to the clients by Access Routers. RFC 2782 [8] defines the service resource record (SRV RR), that allows a client to locate the address of a particular service/protocol. This can be used by the Access Routers to discover MAP in the local domain. A new service name ("netlmm-aflm") for NFLM needs to be defined and the protocol name is 'ipv6'. All the Access routers advertise prefixes for clients to configure an address that is valid in the local domain. These prefixes can be learnt from the MAP using Mobile Prefix discovery as defined in RFC 3775 [8]. 6.0 Protocol Details The NFLM protocol begins when the mobile node is handing over to a new Access Router. In some wireless technologies, the handover control may reside in the network (Access Router). NFLM supports both Predictive handoff and Reactive handoff. MN does not do anything special in the NFLM protocol. It does what a node would do when it receives a L2 trigger. The next two sections discuss the Predictive and reactive handoff. <Parthasarathy> Expires January 2006 [Page 8]
Network-based Fast Handovers for local mobility October 2005 6.1 Predictive handoff The Predictive handoff happens when the MN is already connected to the local domain and the Access Router receives a L2 trigger informing it of a certain MN's upcoming movement to a new Access Router. The trigger provides enough information from which the IP address of the new access router (NAR) and IP address of the MN can be obtained. MN PAR NAR MAP | | | | | | | | | --L2 Trigger -->|------ HI------>|---- FBU -->| | | | | | |<------HAck-----|-----FBack--| | | | | Disconnect | | | | | | | Connect | | | | --NA---------->| | | | | | | | | forward packets| | |<==================================|<===========| | | | | When the PAR receives the L2 trigger, PAR sends a Handoff Initiate message to the NAR. The Handoff Initiate message contains the MN's IP address (PCoA) and MN's identifier. When NAR receives the HI message, it SHOULD check whether a tunnel to the MAP exists for PCoA or not. If the tunnel already exists, it could mean one of two things. The HI message from PAR is spurious and NAR already had setup a tunnel with MAP when it saw the L2 trigger earlier. It could also mean that there is already a node with the same PCoA address on the link. The NAR could verify the MN's identifier to see whether it is the same node or a different node. If it is the same node, then it continues processing the HI message. Otherwise, it returns failure indicating Duplicate Address. When PAR receives such a message, it SHOULD fail the handover process if possible. If the handover has already happened, then the MN would figure out that it has a duplicate address when it does DAD on the new link. If NAR successfully processes the HI message, it sends a Fast Binding Update message to the MAP to redirect the tunnel from the old Access Router to itself. The FBU message contains PCoA as the home address, NAR's address as the Care-of address and an option to carry the MN's unique identifier. When MAP receives the FBU message, it does the following checks. <Parthasarathy> Expires January 2006 [Page 9]
Network-based Fast Handovers for local mobility October 2005 . It checks to see if there is a binding for the PCoA. If it does not exist, it creates a new binding entry. . If a binding already exists, it checks to see if the MN's identifier in the FBU matches with the identifier in the binding. If it does not match, it fails the request. If it matches, then it updates the binding information. Once the MAP successfully processes the FBU, it sets (or updates) the tunnel to NAR for sending and receiving packets from PCoA. Normally a host route will be added for PCoA pointing to the tunnel. When the NAR receives a successful FBack message, it checks to see if the FBU was processed successfully. If there is a failure, the same is indicated in the HAck message. If FBack indicates success, it creates a tunnel to the MAP and sets up the forwarding in such a way that packets with source address as PCoA gets forwarded into the tunnel. It also maintains state (similar to the binding state) which can be used to verify duplicates or spurious indications from PAR or MN. It also creates a host route for forwarding packets to the MN. NAR sends a HAck message back to the PAR indicating that it successfully processed the Handoff procedure. When PAR receives the HAck message, it removes the PAR-MAP tunnel and host routes for PCoA. When the MN connects to the new link, it sends out a Neighbor advertisement. The NAR can use this indication to start forwarding packets to the PCoA. It will also forward the buffered packets (if any) when the NA indication is received. 6.2 Reactive handoff This handoff procedure happens when the MN connects to the local domain for the first time or it connects to a new Access Router as a result of L2 change. This is explained separately depending on how the address is configured. 6.2.1 Autoconfiguration When the MN connects to the local domain for the first time, following things could happen. . MN sends a router solicitation with unspecified address . MN sends a router solicitation with an address configured from a previous network probing to see if it is still connected to the same network. In either case, NAR just sends a Router advertisement. <Parthasarathy> Expires January 2006 [Page 10]
Network-based Fast Handovers for local mobility October 2005 If the MN receives the RA, it assigns the IP address if there any valid prefixes present and then it SHOULD send a unsolicited NA to indicate its presence. When the NAR receives the unsolicited NA, it sends the FBU message to the MAP and the rest of the processing is the same as the previous section. The unsolicited NA should contain the MN's identifier in the SLLA option [5]. If there is a failure in the FBU processing, the MAP and NAR does not forward packets to the MN. The NAR SHOULD send an RA with NAACK indicating failure [2]. If the MN has already configured an address in the local domain and just handing over to a new Access Router, it would send a router solicitation and/or a neighbor solicitation to verify whether it is still connected to the same access router or not. If the old Access Router receives this message, it does not do any NFLM specific operation. If it handed off to a new Access Router, the NS/RS message is an indication that a new MN is possibly trying to get access. The NAR checks to see if a tunnel/binding already exists for the PCoA. If it exists, it checks to see if the MN's identifier matches with the binding state. If there is a mismatch, router advertisement is sent with NAACK option indicating failure. If it is successful, then the NAR sends FBU to the MAP. The MAP also SHOULD add the IP address of the PAR in the FBack option. This enables the NAR to send an unsolicited HAck to PAR for cleaning up the host routes. Rest of the processing by MAP and NAR is similar to the previous section. 6.2.2 DHCP Configuration If the client is booting up for the first time, then it would send a REQUEST [4] message to acquire the IP address. When the server sends a successful DHCPv6 reply message to the client, the client assigns the address normally and sends an unsolicited NA. This can be used as an indication to setup the tunnel with the MAP as described in the previous section. If the client is handing off to a new Access Router, it SHOULD send a CONFIRM [4] message. A successful reply to the CONFIRM can be taken as an indication to send the FBU to the MAP. DISCUSS: The DHCP server does not seem to check the client identifier option in the CONFIRM request to match with the client identifier option that was sent earlier during the REQUEST. <Parthasarathy> Expires January 2006 [Page 11]
Network-based Fast Handovers for local mobility October 2005 MN NAR MAP | | | | | | L2 Trigger -->| RtSol/NA/DHCP-->| ------- FBU -->| | | | | |<-------FBack---| | | | | | | | | | | forward packets | |<================|<===============| | | | 7.0 Packet Forwarding in local domain The communication between a mobile node in the local domain and a node in the external domain happens through MAP. MAP intercepts packets from the external network and forwards it to the Access Router (via the tunnel) to where the node is attached currently. MAP always knows the correct point of attachment of the mobile node. The communication between two nodes in the local domain can happen through multiple ways. As the on-link (L bit) prefix is not set in the RA, all packets from the MN are sent to the Access Router. If the attached node is connected to the same Access Router, then the router may forward the packets directly to the attached node without going through MAP. It may also send a redirect to the mobile node so that it can directly reach the peer node. If the peer node is not connected to the same Access Router, then it forwards to the MAP which in turn forwards to the right Access Router where the node is located. 8.0 Message Formats The messages defined in [2] will be used by NFLM. Instead of Link- layer option, this document defines a new MN identifier option which will be used by the network to identify a mobile node. The messages used by NFLM are Handover Initiate message, Handover Acknowledgement message, Fast Binding Update and Fast Binding Acknowledgement. Following sections describe the differences between NFLM and FMIPv6 [2]. 8.1 MN identifier option This is a new option defined by NFLM. Though this has resemblance to the Link Layer address option, this subsumes the functionality of the link-layer address option. <Parthasarathy> Expires January 2006 [Page 12]
Network-based Fast Handovers for local mobility October 2005 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 | Option-Code | Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length The size of this option in 8 octets including Type, Option- code, and Length fields. Option-code TBD Identifier A unique identifier for the MN in the local domain. It MAY be a link-layer address of the MN or any other unique identifier that can be used to uniquely identify a given node in the local domain. Appropriate padding MUST be used to ensure that the option size is a multiple of 8 octets. 8.2 Handover Initiate message The Handover Initiate message is an ICMPv6 message sent by an Access Router (PAR) to another Access Router (AR) to initiate the process of a MN's handover. The message format is identical to [2] except for the options. Following options MUST be included. MN-identifier option The unique value to identify the MN in the local network Previous care-of Address The IP address used by the MN while attached to the router where this message is originating. It is the same as the MN's address that is configured in the local domain. <Parthasarathy> Expires January 2006 [Page 13]
Network-based Fast Handovers for local mobility October 2005 8.3 Handover Acknowledgement message The Handover Acknowledgement message is an ICMPv6 message sent by an Access Router (NAR) to another Access Router (PAR) to acknowledge the MN's handover. NAR also sends an unsolicited HAck to flush the host routes in PAR for the reactive handoff case. MN-identifier option This SHOULD be included to help PAR locate any state if needed. A new code value should be defined to indicate that PCoA is not valid. 8.4 Fast Binding Update The Fast Binding Update message is sent by the Access router to the Mobility anchor point to update the current binding of the MN. The Home Address is PCoA and care-of address is the IP address of the router originating this message (NAR). The MN-identifier option SHOULD also be included in the message. 8.5 Fast Binding Acknowledgement The Fast Binding Acknowledgement message is sent by the MAP to the Access Router to acknowledge the Binding Update. The MN-identifier option MAY be included in the message. The Alt-coa option defined in [2] is not needed. The MAP SHOULD also include the IP address of the PAR in its response. This is used by NAR to send an unsolicited message to PAR to clean up the host routes. 9.0 IANA Considerations This document specifies the following messages which require new Type assignment from IANA. 1. Fast Binding Update: Section 8.4 2. Fast Binding Acknowledgment: Section 8.5 3. Handover Initiate: Section 8.2 4. Handover Acknowledgment: Section 8.3 <Parthasarathy> Expires January 2006 [Page 14]
Network-based Fast Handovers for local mobility October 2005 The Handover Acknowledgment message needs an additional Type assignment to support unsolicited transmission mode. This document specifies the following new option which requires Type assignment from IANA. 1. Mobile Node Identifier Option: Section 8.1 This document specifies a new code value for the HAck message. 1. PCoA Not valid, Duplicate Address The future versions of this document may specify additional IANA assignments. 10.0 Security considerations As the MAP and AR is under the same trusted domain, the communication between them (MAP-AR and AR-AR) can be secured using IPsec [10]. Fast Binding Updates are sent by the Access Router to redirect traffic destined to a particular address (PCoA) to itself. Fast Binding Updates are triggered by unsolicited NA, Router Solicitation, L2 trigger, DHCPv6 reply and DHCPv6 confirm messages. An attacker may be able to send false messages to trigger the FBU and hence redirecting the traffic to either itself or the victim. The victim will be located on the link because the care-of address would be NAR. Access Router check to see if a binding already exists by checking both the IP address and the MN-identifier. This prevents an attacker on the link to redirect traffic to itself. But the attacker can move to a new link and cause the same attack by spoofing the MN-identifier and the IP address. This is limited in the Predictive handoff case because only L2 triggers can cause the access router to send the FBU. If L2 triggers cannot be spoofed, such attacks can be avoided. If neighbor discovery messages are secured using SEND [7], then the attacker cannot spoof IP addresses within the local domain. A legitimate owner of the IP address can still spoof MAC address as it is not protected by SEND. But this attack is not specific to NFLM. Even if DHCP messages are secured, the attacker can still trigger false FBU by sending a CONFIRM message. SEND does not apply to addresses configured using DHCP. Attacker can pre-create a binding if it knows the IP address that will be assigned to the MN. If SEND is used, then the attacker cannot spoof the IP address. <Parthasarathy> Expires January 2006 [Page 15]
Network-based Fast Handovers for local mobility October 2005 11.0 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] R. Koodli et al., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005 12.0 Informative References [3] H. Soliman et al., "Hierarchical Mobile IPv6 Mobility Management", RFC 4140, August 2005 [4] R. Droms et. al, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003 [5] T. Narten et al., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-04.txt, work in progress [6] S. Thomson et. al, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08.txt, work in progress [7] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 [8] A. Gulbrandsen et. al, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000 [9] D. Johnson et. al, "Mobility support in IPv6", RFC 3775, June 2004 [10] S. Kent et. al, "Security Architecture for the Internet Protocol", draft-ipsec-rfc2401bis-06.txt, work in progress 13.0 Acknowledgments The authors would like to thank Charles Perkins for providing a very good feedback on this document. 14.0 Author's Addresses Mohan Parthasarathy NOKIA 313 Fairchild Drive Mountain View CA-94043 <Parthasarathy> Expires January 2006 [Page 16]
Network-based Fast Handovers for local mobility October 2005 Email: mohan.parthasarathy@nokia.com Rajeev Koodli NOKIA 313 Fairchild Drive Mountain View CA-94043 Email: Rajeev.Koodli@nokia.com Basavaraj Patil Nokia 6000 Connection drive, Irving, TX 75039 Email: basavaraj.patil@nokia.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE <Parthasarathy> Expires January 2006 [Page 17]
Network-based Fast Handovers for local mobility October 2005 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. <Parthasarathy> Expires January 2006 [Page 18]