NEMO Working Group M. Kumazawa Internet-Draft Y. Watanabe Expires: January 7, 2005 T. Matsumoto S. Narayanan Panasonic July 9, 2004 Token based Duplicate Network Detection for split mobile network (Token based DND) draft-kumazawa-nemo-tbdnd-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract When multiple Mobile Routers share the same prefix, a Home Agent must be able to verify whether the mobile routers are in the same Mobile Network or not. Otherwise, the Home Agent may not be able to forward a data packet to the correct recipient since it may not be connected to the mobile router the home agent chooses to forward the packet. This document describes a Token based Duplicate Network Detection Kumazawa, et al. Expires January 7, 2005 [Page 1]
Internet-Draft Token based DND July 2004 mechanism that enables a home agent to detect whether the mobile rotuers claiming the same prefix are in the same mobile network. Kumazawa, et al. Expires January 7, 2005 [Page 2]
Internet-Draft Token based DND July 2004 1. Introduction Today, Mobile Internet Access using third generation network and the use of public Internet access services by Wireless LAN is gaining in popularity. Various new access technologies will emerge in the near future. This leads to the demand for ubiquitous networking, where portable devices can be connected to the Internet anywhere, at any time. To realize ubiquity, it is necessary to select from the various access networks available the network most suitable for mobile Internet access according to the user's location and situation. However, it is difficult to add various wireless interfaces to all portable devices for reasons of cost and size. Wireless PAN (W-PAN) is one of possible solutions enabling ubiquity. In W-PAN portable devices with short distance wireless interfaces are connected and some of them have additional access interfaces and provide connectivity to the Internet. Devices with such Internet access interfaces need to provide session continuity of all nodes in W-PAN even when they change points of attachement to the Internet. The Nemo Basic Support [2] provides the mobility of an entire network. It realizes session continuity to all nodes in the Mobile Network by maintaing bi-directional tunnels between mobile routers and a Home Agent. Devices with Internet access interfaces in W-PAN act as Mobile Routers. Mobile networks with mulitple mobile routers providing multiple points of attachments to the Internet are called Multihomed Mobile Network[1][3]. Mobile Routers are required to construct just one logical network even though the physical mobile router providing connectivity to the Internet could vary based on location. This means that multiple mobile router in the same mobile network may have to claim the same prefix. This kind of configuration is introduced as (N,*,1) in [1]. However, this configuration has an issue. In the Nemo Basic Support protocol, a Home Agent can't know whether Mobile Routers claiming the same prefix are in the same Mobile Network or not. So, correct recipient may not be connected to the Mobile Router the Home Agent chooses to forward packets. This problem is called "split mobile network" and the solution to detect split mobile network is called Duplicate Network Detection (DND) and they have been discussed in NEMO working group mailing list [5]. The solution described in this document requires sharing of a token corresponding to a Mobile Network Prefix between Mobile Routers within a network and a Home Agent. Since the token is updated periodically, Mobile Routers which exist outside or move away can't obtain it and share the prefix. Kumazawa, et al. Expires January 7, 2005 [Page 3]
Internet-Draft Token based DND July 2004 2. Terminology The keywords "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[6]. Owner A Mobile Router which owns a Mobile Network prefix (ex. manual-configured or obtained with DHCP) Borrower A Mobile Router which borrows a Mobile Network prefix from the owner. Token It is a random number created, or updated by an owner or a Home Agent. A token is set in a token option in a Binding Update message when the owner creates or a Binding Acknowledgement message when the Home Agent creates. A token is distributed with a Mobile Network prefix from the owner to borrowers. A token is used for Home Agent to confirm whether the borrowers are connected to the owner or not. Kumazawa, et al. Expires January 7, 2005 [Page 4]
Internet-Draft Token based DND July 2004 3. Overview Figure 1 shows an example network for describing overview of the operation. +----+ | HA | +--+-+ | +-----------------------+ +------+ | Internet |-----+ CN | +-----------------------+ +------+ | | +-----+ +-----+ | MR1 | | MR2 | +--+--+ +--+--+ | | ----------------------- 1:: | 100 +--+--+ | LFN | +-----+ Figure 1: example network A LFN is connected to a Mobile Network whose prefix is 1::, and the Mobile Network is connected to the Internet via two mobile routers MR1 and MR2. This example assumes that both mobile routers register to the same Home Agent. Hence this document describes only (N,1,1) [1] case. (N,N,1) [1] would need some inter Home Agent protocol, and the Token based DND would work with such protocol. In this example, MR1 acts as an owner of 1:: and MR2 as a borrower of 1::. 3.1 Registration as an Owner MR1 sends a Binding Update message to the Home Agent when it attaches to a new access router. MR1 sets a Prefix Delegated flag (D) to zero to indicate that it is an owner of 1:: and puts a token option to indicate that 1:: can be shared with other mobile routers having a correct token in the message. The token may be generated by either the owner (MR1) or the Home Agent. If MR1 generates a token, it is set in the token option, or if MR1 requests the Home Agent to create a token, MR1 sets the token to zero in the option. When a Home Agent receives a Binding Update message, it searches its binding cache and prefix table if any. If the Home Agent doesn't find any other owner of the same prefix (1:: in this example) in the Kumazawa, et al. Expires January 7, 2005 [Page 5]
Internet-Draft Token based DND July 2004 binding cache or prefix table, the Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement with status '0' to MR1. When the token is set to zero in the Binding Update, Home Agent generates a token and sets it in the token option in the Binding Acknowledgement message. A token option is included in a Binding Acknowledgement message regardless of the value in a corresponding Binding Update, to indicate that the Home Agent interprets a token option in the Binding Update and is aware of Token based DND. MR1 receives the Binding Acknowledgement message and confirm whether it includes a token option or not. If the message doesn't include token option, MR1 concludes that the Home Agent is not aware of Token based DND, and operates without Token based DND. MR1 starts advertising 1:: and a corresponding token with router advertisement message in the Mobile Network when it receives a Binding Acknowledgement message including a token option. The Router Advertisement multicasted from MR1 includes a prefix option of 1:: and a token option. LFN configures its address (1::100 in this example) in the first reception of a router advertisement message with a prefix option and begins communication with CN. MR2(Borrower) MR1(Owner) HA | | | | |-----BU [1::, token,owner]---->| | | | | |<-----BA [status=0,token]------| | | | | |=====bi-directional tunnel=====| |<--------RA[1::,token]---------| | Figure 2: sequence: Registration as an Owner Figure 2 shows the sequence MR1 registers as an owner. This section assumes that MR1 (owner) generates and updates tokens. If a Home Agent finds that another owner of 1:: already registers, the Home Agent rejects the Binding Update from MR1 and sets status to '141' (Invalid Prefix) in a corresponding Binding Acknowledgement message. 3.2 Registration as a Borrower When MR2 receives a Router Advertisement message with prefix option including 1:: and a token option from MR1, MR2 sends a Binding Update Kumazawa, et al. Expires January 7, 2005 [Page 6]
Internet-Draft Token based DND July 2004 message with a token option and a Mobile Network Prefix option including 1:: and sets the Prefix delegated flag (D) to 1 to indicate that it borrows 1:: to the Home Agent. MR2 sets the token received from MR1 in the Binding Update to indicate that it borrows 1:: from MR1. When a Home Agent receives the Binding Update from MR2, it compares the token of the MR2 and the token registered by MR1. If they are the same, the Home Agent acknowledges the Binding Update and sends Binding Acknowledgement with status '0' and a token option. If they are different or the prefix in the Binding Update from MR2 is not registered by any owner, the Home Agent rejects it and sets the status 141 (Invalid Prefix) of Binding Acknowledgement. There are now two mobile routers MR1 and MR2 which claim 1:: in the Binding Cache in the Home agent, and the Home Agent chooses one based on various policies (eg. load balancing) when forwarding packets for LFN. Now, while both MR1 and MR2 MUST advertise the prefix in their router advertisment messages, MR2 MUST NOT include the token option in its router advertisment messages. Only the owner of the prefix is allowed to advertise the corresponding token. 3.3 Refreshment of Token The token is updated periodically and exchanged between a Home Agent and the owner. After MR1 receives a Binding Acknowledgement with a token option and realizes that re-binding and update of the token has finished successfuly, it includes the updated token in Router Advertisement messages. When MR2 finds the token updated, it sends a Binding Update message with the new token to the Home Agent. If MR2 moves away from the mobile network and Router Advertisement messages from MR1 do not reach it, it can't follow token updates. After a token is updated, Binding Update messages with old tokens are rejected by a Home Agent. Since MR2 can't re-register to the Home Agent to update its Binding, the entry of MR2 in the Home Agent will expire. Figure 3 shows the sequence of the case MR2 moves away. Kumazawa, et al. Expires January 7, 2005 [Page 7]
Internet-Draft Token based DND July 2004 MR2(Borrower) MR1(Owner) HA | | | moves away |--BU [1::,updated token,owner]-->| | | | | |<------BA [status=0,token]-------| | | | | unreachable | | | <--RA[1::,updated token]--| | | | | |-------------------------------+--BU [1::,old token,borrower]--->| | | | |<------------------------------+-----BA [status=141]-------------| | | | | | The entry of MR2 expires Figure 3: sequence: MR2 moves away 3.4 After Detection of Splitting When MR2 moves away from MR1 and LFN remains connected to MR1, LFN can keep communication with CN using the same address 1::100. If LFN moves away with MR2 from MR1, LFN can't keep communication using 1::100 since MR2 doesn't own 1:: yet. When MR2 stops receiving router advertisements from MR1, it realizes that the owner (MR1) of the prefix 1:: has either failed or moved away. Upon realizing this, MR2 MUST stop including the prefix 1:: in its router advertisment messages. Node still attached to MR2 (possibly including the LFN), will stop receiving RA messages that include 1:: and hence their internal movement detection mechanisms will reconfigure their addresses for communication. If all the nodes that are using 1:: are attached to MR2, it makes sense to allow MR2 to take ownership of the prefix rather than re-configuring every node in the network. Detecting such a situation and achieving the trasfer of ownership is outside the scope of this document. 3.5 Registration Request from Token based DND-unaware Mobile Routers A Binding Update without token option or Prefix Delegated Flag (D) means that the Mobile Network prefix in the Binding Update must not be shared with any mobile router. Hence Mobile Network Prefixes owned by mobile routers unaware of Token based DND will not be shared. Kumazawa, et al. Expires January 7, 2005 [Page 8]
Internet-Draft Token based DND July 2004 4. Format 4.1 Binding Update A new Prefix Delegated flag (D) is included in the Binding Update to indicate that the Mobile Network Prefix is owned (zero) or borrowed (one). The rest of the Binding Update format remains the same as defined in [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|D| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Delegated Flag (D) The Prefix Delegated Flag is set to indicate to the Home Agent that Mobile Network prefix is owned or borrowerd. If the flag is set to 0, the prefix is owned by a Mobile Router. If the flag is set to 1, the prefix is borrowed from a Mobile Router(owner). However, when Mobile Router Flag (R) is set to zero, the Home Agent MUST ignore the D flag. 4.2 Token Option A token option is included in the Binding Update and the Binding Acknowledgement to share the token corresponding to the Mobile Network prefix between an owner and a Home Agent. When the owner requests the Home agent to generate or update the token, it sets zero in the token field of the Binding Update. When the owner generates or updates token by itself, the owner sets the value. A token option is also included in router advertisements multicasted from an owner to distribute the prefix and the token to borrowers within the Mobile Network. A token option is also used to indicate that a Home Agent is aware of Token based DND. If the Binding Acknowledgement from the Home Agent doesn't include a token option while an owner or a borrower includes a token option in the Binding Update, Token based DND is not implemented in the Home Agent. Kumazawa, et al. Expires January 7, 2005 [Page 9]
Internet-Draft Token based DND July 2004 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 8 bit unsigned integer indicating the length in octests of the option excluding the type and length fields. Set to 8. token 2 bytes field contains token. Kumazawa, et al. Expires January 7, 2005 [Page 10]
Internet-Draft Token based DND July 2004 5. Mobile Router Operation A Mobile Router acts as either an owner or a borrower. Major differences from Mobile Router's operation in [2] are the followings. Binding Updates includes a D flag and a token option. An owner multicasts Router Advertisement including a Mobile Network Prefix and a token option. 5.1 Data Structure An owner or a borrower also maintains Binding Update List, described in Section 5.1 of NEMO Basic support specification[2]. This document introduces a new token field and a Prefix Delegated Flag (D). Prefix Delegated Flag (D) is set to zero (owner's case) This indicates that a mobile router acts as an owner of the Mobile Network prefix. The owner stores a token generated or updated by itself or a Home Agent. Prefix Delegated Flag (D) is set to one (borrower's case) This indicates that a mobile router acts as a borrower of the Mobile Network prefix. The borrower stores the token included in router advertisements sent from the owner. 5.2 Owner Operation 5.2.1 Sending Binding Updates An owner includes a token option in a Binding Update message if it allows other mobile routers (borrowers) to share the Mobile Network prefix. An owner doesn't include token option if it doesn't allow share of the prefix. An owner MUST maintain a token with a Home Agent using a token option to share the prefix with borrowers. An owner can choose itself or the Home Agent to generate and update the token. In the case an owner generates or updates a token, the owner sets the value in the option in a Binding Update. If the owner requests the Home Agent to generate or update the token, the owner sets zero in the token field. The owner can choose to generate/update the tokens or allow the home agent to do the same. The periodicity of the updates (token change) will be controlled by the owner or the home agent based on who is generating/updating the token. Kumazawa, et al. Expires January 7, 2005 [Page 11]
Internet-Draft Token based DND July 2004 An owner can operate in either Implicit or Explicit mode. In implicit mode, the Mobile Router does not include a Mobile Network Prefix Option in the Binding Update. In explicit mode, the Mobile Router includes a Mobile Network Prefix Option in the Binding Update. These modes are defined in [2]. 5.2.2 Receiving Binding Acknowledgements After the owner completes the Binding as a mobile router successfully, it checks the token option in the Binding Acknowledgement. If token option is not included in the Binding Acknowledgement while the owner included a token option in the correspoinding Binding Update, the owner assumes that the Home Agent is not aware of Token based DND. In this case the owner acts as a mobile router in [2] and doesn't include token option in Router Advertisement messages. If a token option is included in the Binding Acknowledgement, the owner checks the value of token in the case the owner requests the Home Agent to generate or update token by setting zero to the token option in the corresponding Binding Update. If the value of the token option in the Binding Acknowledgement is zero, which means that an error is occurred in the Home Agent. In the case the owner MUST NOT include token option in Router Advertisement messages. If the value is not zero, the owner stores it in the Binding Update List. When the owner succeeds in checking token option in the Binding Acknowledgement, it starts multicasting Router Advertisement including a token option. The owner MUST NOT include the token option in the Router Advertisement before it confirms that the Home Agent processes the token successfully. 5.2.3 Error processing Error processing of an owner is the same as described in [2]. 5.2.4 token update A token SHOULD be updated frequently using the token option in Binding Updates and Binding Acknowledgement. The owner need not include token option in Binding Updates when it doesn't intend to update a token. The owner MUST NOT include an updated token in Router Advertisements before it confirms the token is processed successfuly by the Home Agent. 5.2.5 Returning Home When the owner returns home, it de-registers with the Home Agent. After de-registration, the owner MUST NOT include token option in Kumazawa, et al. Expires January 7, 2005 [Page 12]
Internet-Draft Token based DND July 2004 Router Advertisements since token can't be exchanged using Binding messages between an owner and a Home Agent at home. This means that a Mobile Network prefix can't be shared while an owner is connected to home link. 5.3 Borrower Operation 5.3.1 Sending Binding Update When a borrower receives a Router Advertisement including a prefix option and a token option from an owner, the borrower sends a Binding Update including token option with the same value and Prefix Delegated Flag (D) set to one. A borrower MUST NOT use implicit mode. A borrower can use only explicit mode. 5.3.2 Receiving Binding Acknowledgement When a borrower receives Binding Acknowledgement and realizes that Home Agent sets up forwarding successfully, the borrower begins Mobile Router operation. A borrower MUST NOT include token option in Router Advertisement. 5.3.3 Receiving Router Advertisement When a borrower finds a token in Router Advertisements updated, the borrower MUST send a Binding Update including the updated token to the Home Agent immediately. When a borrower finds Router Advertisement from an owner stopped, the borrower can assume that the owner failed or moved away. The borrower MAY try to become a new owner of the Prefix. The mechanism to change the ownership of a prefix is outside the scope of the current document. This will involve invalidating the binding cache entry of the old owner in the home agent, either by time expiry or a de-registration by the owner. When a borrower notices that an owner removes token option from Router Advertisements, the borrower can assume that an owner prohibits the share of its Prefix (ex. the owner returns home). In this case the borrower may try to obtain a new prefix and become a new owner of it or de-register with the Home Agent. Operations of borrowers when an owner stops allowing the share of its Prefix are outside the scope of this document. Kumazawa, et al. Expires January 7, 2005 [Page 13]
Internet-Draft Token based DND July 2004 5.3.4 Error Processing Since a borrower can use only explicit mode and Binding Updates sent from the borrower are not rejected by the Home Agent using Prefix Table, it interprets only error status '140' (Mobile Router Operation not permitted) and '141' (Invalid Prefix). A borrower MUST discard Binding Acknowledgements with status '142' or '143'. Error status '141' is returned when a Mobile Network prefix is not registered by an owner or when value of a token option is invalid. These two cases are not differentiated with status value because of security reason. When a borrower receives a Binding Acknowledgement with status '141', it SHOULD wait until token is updated in Router Advertisements from an owner. Kumazawa, et al. Expires January 7, 2005 [Page 14]
Internet-Draft Token based DND July 2004 6. Home Agent operation 6.1 Data Structures 6.1.1 Binding Cache The Binding Cache is a conceptual data structure described in detail in [4] and [2]. This document introduces a new token field and a Prefix Delegated Flag (D). A Home Agent stores tokens corresponding to the Mobile Network Prefixes associated with owners. This information is used when the Home Agent decides whether it acknowledges requests for sharing the prefixes from borrowers or not. The Home Agent also stores the status of Prefix Delegated Flag (D) extracted from a Binding Update. 6.1.2 Prefix Table Since borrowers can claim Mobile Network Prefixes that belongs to owners using Token based DND. Prefix Table MUST NOT be used when processing Binding Updates from borrowers. 6.2 Mobile Network Prefix Registration The Home Agent performs the following checks of a Binding Update in addition to checks in [2] in the case Mobile Router Flag (R) is set. If Mobile Router Flag (R) of the Binding Update is not set, the Home Agent MUST ignore the Prefix Delegation flag (D). Prefix Delegation flag is set to zero in explicit mode If the Home Agent has a binding cache entry with a Prefix Delegation Flag (D) set to zero and the Mobile Network Prefix in the Binding Update is the same as the existing entry, the Home Agent rejects it and sends Binding Acknowledgement with status set to 141. If the Home Agent verifies the prefix information with the Prefix Table and the check fails, the Home Agent MUST reject the Binding Update and send a Binding Acknowldegement with status set to 142 (Not Authorized for Prefix). Prefix Delegation flag is set to one in explicit mode The Home Agent rejects the Binding Update and sends a Binding Acknowledgement with status set to 141 in the following cases. -The Binding Update doesn't include token option. Kumazawa, et al. Expires January 7, 2005 [Page 15]
Internet-Draft Token based DND July 2004 -When the Binding Update includes a token option and the Home Agent doesn't have any entry with Prefix Delegated Flat set to zero, the same prefix, and the same token. Prefix Delegation flag is set to zero in implicit mode The Home Agent checks the Binding Update as described in [2]. Prefix Delegation flag is set to one in implicit mode The Home Agent rejects the Binding Update and sends Binding Acknowledgement with status set to 143. When the Home Agent has a valid binding cache entry with a Prefix Delegate Flag (D) set to one and rejects the corresponding Binding Update because of an invalid token, the Home Agent SHOULD NOT delete the existing entry with just one rejection. The Home Agent MAY use the number of errors or the lifetime of the entry to decide whether the Home Agent deletes the entry or not. This is because borrowers may not be able to obatin an updated token as soon as the update occurs. If all checks are passed, the Home Agent creates a binding cache entry for an owner or an borrower, or updates the binding cache entry if it already exists. If the Binding Update from unregistered owner without token option arrives, the Home Agent sets zero in the token field of the binding cache entry. If the Binding Update from registered owner without token option arrives, the Home Agent doesn't update the token field of the entry. If the token is set to zero in the Binding Update with Prefix Delegated Flag (D) set to zero, the Home Agent generates or updates a token if necessary. After setting up Binding Cache Entry and forwarding, the Home Agent sends the Binding Acknowledgement with status set to zero. If the Binding Update from an owner or a borrower includes the token option, the Home Agent includes a token option in the Binding Acknowledgement. If the Binding Update doesn't include token option, the Home Agent SHOULD NOT include token option in the Binding Acknowledgement. When the token is zero in the Binding Update sent from an owner, the Home Agent sets the value generated by itself in the Binding Acknowledgement. Kumazawa, et al. Expires January 7, 2005 [Page 16]
Internet-Draft Token based DND July 2004 6.3 Forwarding Packets When the Home Agent forwards a data packet destined for the mobile network, the Home Agent selects one Mobile Router among an owner and borrowers if any. This selection will be done based on various policies. Selection of Mobile Router for data forwarding is outside the scope of this document. Kumazawa, et al. Expires January 7, 2005 [Page 17]
Internet-Draft Token based DND July 2004 7. Security Consideration A token is used for a Home Agent to confirm reachability between an owner and borrowers within a link. Hence, token sent from an owner should be protected with security mechanisms like layer 2 encryption. And exchange of token between an owner and a Home Agent should be protected with IPsec. 8 References [1] Ng, C. and J. Charbon, "Multi-Homing Issues in Bi-Directional Tunneling", draft-ng-nemo-multihoming-issues-03 (work in progress), February 2004. [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004. [3] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] IETF NEMO (NEtwork MObility) working group mailing list, Archive: http://www.ietf.org/html.charters/nemo-charter.html. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Masayuki Kumazawa Panasonic (Matsushita Electric Industrial Co., Ltd.) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2729 EMail: kumazawa.masayuki@jp.panasonic.com Kumazawa, et al. Expires January 7, 2005 [Page 18]
Internet-Draft Token based DND July 2004 Yasuhiko Watanabe Panasonic (Matsushita Electric Industrial Co., Ltd.) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2729 EMail: watanabe.yasuhiko@jp.panasonic.com Taisuke Matsumoto Panasonic (Matsushita Electric Industrial Co., Ltd.) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2729 EMail: matsumoto.taisuke@jp.panasonic.com Sathya Narayanan Panasonic Digital Networking Lab Two Research Way, 3rd Floor Princeton, NJ 08536 USA Phone: 609 734 7599 EMail: sathya@research.panasonic.com Kumazawa, et al. Expires January 7, 2005 [Page 19]
Internet-Draft Token based DND July 2004 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 (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kumazawa, et al. Expires January 7, 2005 [Page 20]