DNA WG JH. Choi Internet-Draft Samsung AIT Expires: December 23, 2006 DongYun. Shin Samsung Electronics W. Haddad Ericsson Research June 21, 2006 Fast Router Discovery with L2 support draft-ietf-dna-frd-01.txt 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 December 23, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract For efficient Detecting Network Attachment (DNA), a host should quickly receive a Router Advertisement (RA) message upon a new link- layer connection. This draft presents a quick RA acquisition scheme with the support of a link-layer entity, Point of Attachment (PoA). Upon a new network attachment, the PoA may either trigger an Access Choi, et al. Expires December 23, 2006 [Page 1] Internet-Draft FRD June 2006 Router (AR) to immediately send an unicast RA, "RA Triggering" or send such an RA for itself, "RA Proxying". We may put "RA Triggering" or "RA Proxying" functionality on a PoA to get the optimized result without IPv6 standard change. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6 3.2. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8 5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Manual Configuration . . . . . . . . . . . . . . . . . 9 5.1.2. Scanning . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.3. Media Independent Command Service (MICS) . . . . . . . 9 5.2. RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Choi, et al. Expires December 23, 2006 [Page 2] Internet-Draft FRD June 2006 1. Introduction Upon establishing a new link-layer connection, a host should check for link change to determine whether its IP configuration is still valid. If the host is attached to a different link, it also needs to acquire the IP configuration for the new link [2]. Detecting Network Attachment (DNA) is the process by which a host collects the appropriate information and detects the identity of its currently attached link to ascertain the validity of its IP configuration. [2]. A Router Advertisement (RA) message is necessary when the host has moved to a different link, so the number of messages needed for DNA can be minimized if the RA also can properly represent the link identity. Moreover to quickly check for link change, the host has to receive the RA without delay. DNA solution should be able to 1) correctly check for link change with a single RA message and 2) quickly get a suitable RA, i.e. the RA, such as 'RA with LinkID' or 'CompleteRA' in [4], which can properly indicate the link identity. This draft presents only the second component, quick RA acquisition. But the proposed method can work with any link identification scheme based on unsolicited RA, such as 'CPL' in [3], 'LinkID prefix' or 'CompleteRA' in [4]. There are several hindrances for sufficiently quick RA acquisition. First, Neighbor Discovery protocol [1] limits routers to a minimum interval of 3 seconds between sending multicast RA messages. Second, a host should delay a random amount of time before initial transmission of a Router Solicitation (RS) message. Third, a router MUST delay a response to a Router Solicitation by a random amount of time too. In cellular environments, it may not be cost-effective to broadcast the RA over wireless link. For DNA purposes, it's generally preferable to deliver the RA to the destination in unicast. Point of Attachment (PoA) is the link endpoint of the link [7], such as 802.11 Access Point (AP) or 802.16 Base Station (BS). We propose a scheme which uses the link-layer entity, PoA, in such a way that an RA is delivered to the host in unicast just after L2 connection is established without any random delay. When a host makes a new link-layer connection with a PoA, the PoA detects the new attachment. So at this moment, the PoA may either trigger an Access Router (AR) to immediately send a suitable RA or send such an RA for itself. For the latter case, the PoA needs to Choi, et al. Expires December 23, 2006 [Page 3] Internet-Draft FRD June 2006 cache a suitable RA. For example, if AR and PoA are in the same box, whenever a new host is attached, the PoA module can deliver Link Up event notification to the AR module so that the AR module can immediately fire an RA. Or, if AR and PoA are separated, PoA can cache a suitable RA and deliver it to a new host upon network attachment. In this draft, we design a scheme for a PoA to trigger an RA, "RA Triggering" and another one for a PoA to proxy an RA, "RA Proxying". In RA Proxying, we present a way to cache a suitable RA and send the RA in unicast without any delay. IEEE 802.21 (Media Independent Handover) standard develops a specification [13] that provides link layer intelligence and other related network information to upper layers to optimize handovers between heterogeneous media. Utilizing the services defined in 802.21 Media Independent Handover (MIH) standard, we can put 'RA Triggering' or 'RA Proxying' functionality on a PoA to get the optimized result for quick RA acquisition without IPv6 standard change. Choi, et al. Expires December 23, 2006 [Page 4] Internet-Draft FRD June 2006 2. Terminology Access Router (AR) - An Access Network Router residing on the edge of an Access Network and offers IP connectivity to hosts. Point of Attachment (PoA) - The link endpoint on the link, such as 802.11 Access Point (AP) or 802.16 Base Station (BS), where a host may be connected. Link Up - An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating data frames. Media Independent Handover Fuction (MIHF) - The MIH Function provides asynchronous and synchronous services through well defined SAPs for lower layers and upper layers. The services provided include the Media Independent Event Service (MIES), the Media Independent Command Service (MICS), and the Media Independent Information Service (MIIS). Media Independent Handover (MIH) Protocol - The Media Independent Handover protocol defines frame formats for exchanging messages between peer MIH Function entities. These messages are based on the primitives which are part of MIES, MICS and MIIS. The MIHF Protocol allows peer MIH Function entities to interact with each other. Choi, et al. Expires December 23, 2006 [Page 5] Internet-Draft FRD June 2006 3. Proposal Overview When a host establishes a link-layer connection, in the process, a link-layer entity, Point of Attachment (PoA), can detect the new attachment and get the necessary information to deliver an unicast L2 frame to the host, such as 802.11 MAC address or 802.16 Connection Identifier (CID) [11]. The PoA may forward the link-layer information to an Access Router (AR) and trigger the AR to immediately send in unicast a suitable RA. Alternatively, the PoA itself may cache such an RA beforehand and deliver the cached RA to the host in unicast as soon as the link- layer connection is established. In this draft, we refer the first scheme "RA Triggering" and the second "RA Proxying". 3.1. RA Triggering In case PoA and AR are in the same box, when a new host is attached, the link-layer (PoA module) can deliver Link UP event notification [5] to the IP layer (AR module) to generate a suitable RA and immediately send the RA (in an unicast L2 frame with the host's MAC address). In case PoA and AR are separated, upon a new network attachment, the PoA may deliver the Link Up event notification to the remote AR with the information necessary to deliver an unicast RA. Upon receiving this notification, the AR can send a suitable RA in unicast without delay. There are two ways for such a remote Link Up event notification. We may use the Media Independent Event Service (MIES) defined in IEEE 802.21 [13] or RS with Tentative Option [6]. 3.2. RA Proxying RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching is to get a suitable RA and store it. RA Delivery is to immediately send the cached RA to a new host in unicast There are several ways to cache the RA in a PoA. An administrator may manually cache the RA in the PoA or use an RA scanning scheme. An Access Router (AR) periodically multicasts a suitable RA, which goes through the PoA. So the PoA may scan incoming L2 frames and cache a suitable RA. The PoA can scan L2 frames either continuously or periodically to update the cached RA. Alternatively, PoA and AR Choi, et al. Expires December 23, 2006 [Page 6] Internet-Draft FRD June 2006 may use a special information service, such as the Media Independent Command Service (MICS) defined in IEEE 802.21 [13] in such a way that the AR can forward the PoA the information necessary to generate a suitable RA and permit it to proxy the RA. For RA Delivery, PoA may put the cached RA into an unicast L2 frame with the host's MAC address (or CID for 802.16) and deliver it to the host in unicast immediately after link-layer connection is established. Choi, et al. Expires December 23, 2006 [Page 7] Internet-Draft FRD June 2006 4. RA Triggering In case PoA and AR are in the same box, when a new host is attached, Link Up event notification with the information necessary to deliver an unicast RA, such as the host's MAC address, can be propagated upwards from the link-layer (PoA module) to the IP layer (AR module) within a local stack. Then the IP layer (AR module) can immediately send a suitable RA in an unicast L2 frame with the new host's MAC address. In case PoA and AR are separated, we may use 802.21 Media Independent Event Service (MIES) [13] to enable a PoA to trigger a remote AR to fire an immediate RA in unicast. Media Independent Event Service (MIES) refers to the events sent from the lower layers to the higher layers. Events can also be sent from a local MIH entity to a peer MIH entity. Events may carry useful information. For example, Link Up event can carry a new host's MAC address. When a new host is attached to a PoA, the PoA may use Link Up event and MIH Protocol to notify a remote AR the new attachment with the information necessary to deliver an unicast RA, such as the host's MAC address. Then the AR can immediately send a suitable RA in an unicast L2 frame with the new host's MAC address. In some specific cases, an AR can be informed of a new attachment of a host even without PoA notification. For example, in WiMAX network [14], while establishing a new link- layer connection, a host performs authentication procedure and notifies its presence to an AR. So even without explicit notification from PoA, the AR can perceive that a new host is attached and send a suitable RA upon completing registration. Choi, et al. Expires December 23, 2006 [Page 8] Internet-Draft FRD June 2006 5. RA Proxying RA Proxying is used only when AR and PoA are separated. If they are in the same box, we recommend to use RA Triggering instead. 5.1. RA Caching We present 3 different ways to store a suitable RA in a PoA. 5.1.1. Manual Configuration In the simplest way, an administrator can manually configure in PoA a suitable RA, such as an RA with the LinkID prefix or a CompleteRA defined in [4]. In many cases, AR and PoA are under the same administration and usually Router Advertisement (RA) message doesn't change so often. 5.1.2. Scanning A PoA may scan incoming L2 frames for a suitable RA and store it. First it scans L2 frame header to see whether it is a multicast frame. If not, the PoA sends that frame down link and scans the next L2 frame. If so, the PoA looks IP header to check whether it contains a suitable RA. If an incoming L2 frame doesn't contain a suitable RA, the PoA sends that frame down link and scans a next L2 frame. When the PoA finds a suitable RA, it stores it and sends a copy down link. A PoA can scan continuously, updating an old RA with a new RA. Alternatively, if it costs too much for the PoA to scan every incoming L2 frame, we can control the scanning rate. For example, we can set timer and execute scanning every T seconds. Or we can make the PoA to be able to send a Router Solicitation (RS) message. Periodically the PoA sends an RS and an AR will reply a suitable RA and the PoA caches it. It is noted that the PoA doesn't need to have IP address because it can use unspecified address as its source address. To help RA Caching, we may make a recommendation that, whenever an AR changes its RA information, the AR advertises the new information several times, so that a PoA can properly update its cached RA. 5.1.3. Media Independent Command Service (MICS) We may use 802.21 Media Independent Command Service (MICS) and Media Independent Handover (MIH) Protocol [13] to enable an AR to send a suitable RA to a PoA and delegate the PoA to proxy the RA. Choi, et al. Expires December 23, 2006 [Page 9] Internet-Draft FRD June 2006 Media Independent Command Service (MICS) refers to the commands sent from the higher layers to the lower layers. Commands can also be sent from a local MIH entity to a peer MIH entity. These commands may carry the upper layer information to the lower layers on local device entity or remote entity, and thus control the behavior of lower layers. For example, a new AR may send its IP address to old PoA with a Remote MIH Command, "MIH Network Address Information". In a similar way, it is possible to define a new Remote MIH Command, "MIH Router Advertisement Information" in 802.21 in such a way that 1) a PoA can use the command and MIP Protocol to request a suitable RA from an AR and permission to proxy the RA and 2) the AR can use the command and MIH Protocol to send a suitable RA to the PoA and delegate the PoA to deliver the RA to a new host upon network attachment. Further work is needed because this entails a change in 802.21 standard. 5.2. RA Delivery We present a way to immediately deliver an RA in unicast upon network attachement for 802.11 and 802.16 respectively. The procedures described in here can be extended to apply to other wireless technologies such as 3GPP and 3GPP.2. 5.2.1. 802.11 In 802.11 Wireless LAN technology, when a new host arrives at an AP(Access Point), it should associate with the AP. The host sends an Association Request Message with its MAC address. Then the AP sends an Association Response Message to grant association. As soon as association is made, the AP sends a cached RA to the host in an unicast 802.11 frame with the MAC address from the Association Request message. The host receives the unicast RA just after association is made, which is the earliest possible time in current standard. 5.2.2. 802.16 IEEE 802.16 spec [11], [12] is rather different from Ethernet or 802.11 and work is still on-going about how to run IPv6 over 802.16. So we give a rough sketch of RA delivery over 802.16 and mention that further work is needed. The 802.16 MAC is connection-oriented. All services, including inherently connectionless services, are mapped to a connection. Connections are referenced with 16-bit Connection Identifiers (CIDs). Choi, et al. Expires December 23, 2006 [Page 10] Internet-Draft FRD June 2006 Each 802.16 host has a standard 48-bit MAC address, but this serves mainly as an equipment identifier and a 802.16 frame carries only a CID. Upon entering the network, the host is assigned three management connections, the basic connection and the primary management connection and the secondary management connection. The secondary management connection is used for the transfer of standards-based management messages such as Dynamic Host Configuration Protocol (DHCP). It is not decided yet but Neighbor Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA (Neighbor Advertisement) may be delivered with this connection. If that's not allowed, a separate transport connection, such as Initial Service Flow (ISF) defined in WiMAX forum [14], can be created for Neighbor Discovery messages. To establish a link layer connection, an 802.16 host performs Ranging to acquire the correct timing offset and power adjustment. The host sends the RNG-REQ message and the 802.16 Base Station (BS) replies RNG-RSP message to provide Basic and Primary Management CIDs for the host. Afterwards the host performs Registration, which is the process by which the host is allowed entry into the network and receives its Secondary Management CID. After Registration is completed, the 802.16 BS may send a cached RA to the host with the Secondary CID. The RA will be delivered in unicast 802.16 frame and the host will receive it with minimum latency. We point out that it's not clear yet whether the Secondary CID can be used for the RA message transfer. In case Secondary CID can't be used, the BS can create a transport connection such as ISF with an associate CID. Afterwards the BS can send a cached RA in unicast 802.16 frame with the transport CID. Choi, et al. Expires December 23, 2006 [Page 11] Internet-Draft FRD June 2006 6. IANA Considerations No new message formats or services are defined in this document. Choi, et al. Expires December 23, 2006 [Page 12] Internet-Draft FRD June 2006 7. Security Considerations Because DNA is based on Neighbor Discovery, its trust models and threats are similar to the ones presented in RFC 3756 [9]. Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring and packet insertion attacks. Note that a DNA scheme should not result in excessive signaling. An attacker can make a bogus association with an PoA to trigger an additional RA. This may result in amplification attack and consumes wireless bandwidth. However a PoA performs FRD procedure to generate an RA message only when a new host is attached to itself. Usually there is an upper bound for the number of hosts (wireless stations) that a PoA can support at a moment. So the number of RA messages from FRD procedure is also limited by this upper bound. The threats specific to DNA are that an attacker might fool a node to detect attachment to a different link when it is in fact still attached to the same link, and conversely, the attacker might fool a node to not detect attachment to a new link. In case PoA and AR are in the same box, FRD doesn't bring forth any additional DNA specific security problem, because all procedures are executed within a local stack. In case PoA and AR are separated, FRD can be performed in secure manner only if there is a secure path between PoA and AR. For example, Media Independent Handover (MIH) services can be made available at L2 through secure port. The lack of secure path between the PoA and AR does not introduce any additional security attack when using FRD. Currently any node in a link can cache an RA and retransmit it to mislead a host to false decision. But an attacker may poison a PoA's cache with a bogus RA to save itself from having to advertise the false information for itself. Use of [8] to secure Neighbor Discovery are important in achieving reliable detection of network attachment. DNA schemes SHOULD incorporate the solutions developed in IETF SEND WG if available, where assessment indicates such procedures are required. In the presence of SEND, RA Caching may raise security concerns, since the PoA can be considered a man in the middle. Especially, it may be difficult for RA Caching with Scanning (Sec 5.1.2) to work with SEND. If a router sends an RA with a SEND Timestamp option, it puts upper bound on how long the RA remains valid after the router advertises it. So if a PoA caches the RA too long, it will become invalid and a host will discard it. However take notice that even in this case, the host will not make a false DNA decision. We may resolve this issue by including a unique 64 bit number called Choi, et al. Expires December 23, 2006 [Page 13] Internet-Draft FRD June 2006 an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash of a nonce and proves to a host that the RA was indeed generated by the router which is listed as the source of the RA. The router must keep a table associating each OP to the nonce, which was used to generate it. When an RA carrying an OP option is received, a host may ignore the SEND Timestamp option if it falls outside the allowable window. With OP, DNA procedure is as below. A PoA caches a suitable RA message with an OP. When a new host makes an attachment, the PoA sends it immediately the cached RA message with an OP. With this cached RA message, the host may perform DNA regardless of its SEND Timestamp and at the same time send an RS message with the OP option. Upon receiving the RS message, the access router may send an RA message immediately because it is solicited in unicast. When the AR responds with a solicited RA it includes the nonce used to generate the OP. Upon receiving the RA message, the host may check if the hash of this nonce matches the OP received in the initial cached RA to verify it. If not, the host stops the DNA procedure with the RA and restarts it with a new RA. In addition to the OP procedure, a sort of combination of the RA triggering and proxying mechanisms may be used, in order to provide a secure FRD procedure without requiring any involvement from the host side. Furthermore, the PoA would better avoid scanning each L2 frame, and consequently, limit the need to refresh its cache memory with a new RA message as much as possible. These requirements are fullfilled by having the AR generating one different one way hash chain (OWHC) [10] for each PoA. In this case, each PoA needs to store at the beginning one RA message, i.e., the one which carries the tip of the corresponding OWHC. After that, each time the PoA forwards the cached RA message to the MN, it sends an RS message, which includes the MN's MAC address in Tentative Option [6] and the OWHC value to the AR. At this point, the PoA should start scanning incoming L2 frame from the AR for a short period of time to capture the AR reply. Upon receiving the RS message from the PoA, the AR should send back immediately an RA message in unicast (by using the MN's MAC address), which discloses the correct value from the corresponding OWHC. The AR should also send another multicast RA message (with the same disclosed value from its OWHC) to be cached by the PoA for future use. In such scenario, the PoA should stop scanning L2 frames immediately after receiving a multicast RA message. The combination of RA triggering and proxying described above allows the PoA to keep the RA message, which carries the last disclosed value of the corresponding OWHC. It also allows the MN to perform DNA with the cached RA message, autoconfigure, if needed, a new IPv6 Choi, et al. Expires December 23, 2006 [Page 14] Internet-Draft FRD June 2006 address and quickly pursue its ongoing session(s). In fact, the RA triggering and proxying combination allows the MN to get a fresh RA message from the AR and validate the cached RA message almost in parallel with the attachment procedure. At the same time, the suggested procedure eliminates the need for the PoA to refresh its cache memory except when a cached RA message is sent to a MN. Choi, et al. Expires December 23, 2006 [Page 15] Internet-Draft FRD June 2006 8. Acknowledgment We gratefully acknowledge the generous assistance we received from Xiaoyu Liu, YounHee Han and James Kempf for notifying us the usability of 802.21 standard and clarifying the MIH Spec to us. We show our special gratitude to HeeJin Jang, Subba Reddy and Surekha Biruduraju for implementing and testing FRD scheme to provide enlightening insights. The authors wish to express our appreciation to Syam Madanapalli and Wable Ranjitsingh for valuable feedback. Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and YongGeun Hong for their contributions to this draft. Choi, et al. Expires December 23, 2006 [Page 16] Internet-Draft FRD June 2006 9. References 9.1. Normative References [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005. 9.2. Informative References [3] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix list based approach", draft-ietf-dna-cpl-02 (work in progress), January 2006. [4] Kempf, J., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-00 (work in progress), February 2006. [5] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-03 (work in progress), October 2005. [6] Daley, G., "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", draft-ietf-dna-tentative-00 (work in progress), February 2006. [7] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [9] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [10] Haddad, W., "Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol", draft-haddad-mipshop-optisend-01 (work in progress), March 2006. [11] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [12] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Choi, et al. Expires December 23, 2006 [Page 17] Internet-Draft FRD June 2006 Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 2005. [13] IEEE 802.21 Working Document (Draft Standard), "IEEE P802.21/D01.00: Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services," July, 2005 [14] WiMAX Forum Network Working Group (NWG), http://www.wimaxforum.org [15] Choi, J. and E. Nordmark, "DNA solution framework", draft-ietf-dna-soln-frame-00 (work in progress), April 2005. [16] Pentland, B., "An Overview of Approaches to Detecting Network Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in progress), February 2005. [17] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in progress), July 2005. [18] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier based approach", draft-jinchoi-dna-protocol2-01 (work in progress), July 2005. [19] Nordmark, E., "MIPv6: from hindsight to foresight?", draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), November 2001. [20] Daley, G. and J. Choi, "Movement Detection Optimization in Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in progress), May 2003. [21] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router Advertisement", draft-mkhalil-ipv6-fastra-05 (work in progress), July 2004. Choi, et al. Expires December 23, 2006 [Page 18] Internet-Draft FRD June 2006 Authors' Addresses JinHyeock Choi Samsung AIT Networking Technology Lab P.O.Box 111 Suwon 440-600 KOREA Phone: +82 31 280 9233 Email: jinchoe@samsung.com DongYun Shin Samsung Electronics Device Solution Group P.O.Box 111 Suwon 440-600 KOREA Phone: +82 2 2191 4868 Email: yun7521@samsung.com Wassim Haddad Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Email: Wassim.Haddad@ericsson.com Choi, et al. Expires December 23, 2006 [Page 19] Internet-Draft FRD June 2006 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 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 (2006). 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. Choi, et al. Expires December 23, 2006 [Page 20]