NEMO Working Group M. Kumazawa Internet-Draft Y. Watanabe Expires: April 12, 2005 T. Matsumoto S. Narayanan Panasonic October 12, 2004 Token based Duplicate Network Detection for split mobile network (Token based DND) draft-kumazawa-nemo-tbdnd-01.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 April 12, 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 share the same Mobile Network or not. Otherwise, the Home Agent may not be able to forward a data packet to a correct recipient since the recipient may not be connected to the mobile router the Home Agent chooses to forward the packet. This document describes a Token based Duplicate Network Kumazawa, et al. Expires April 12, 2005 [Page 1] Internet-Draft Token based DND October 2004 Detection mechanism that enables a Home Agent to detect whether multiple Mobile Rotuers claiming the same prefix are in the same Mobile Network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Registration as an Owner . . . . . . . . . . . . . . . . . 6 3.2 Registration as a Borrower . . . . . . . . . . . . . . . . 7 3.3 Refreshment of Token . . . . . . . . . . . . . . . . . . . 8 3.4 Registration Request from Token based DND-unaware Mobile Routers . . . . . . . . . . . . . . . . . . . . . . 9 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Mobile Network Prefix Option . . . . . . . . . . . . . . . 10 4.2 Token Option . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1 Binding Acknowledgement . . . . . . . . . . . . . . . 11 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 12 5.1 Data Structure . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Sending Binding Updates . . . . . . . . . . . . . . . . . 12 5.3 Receiving Binding Acknowledgements . . . . . . . . . . . . 13 5.4 Error Processing . . . . . . . . . . . . . . . . . . . . . 13 5.5 Token Update . . . . . . . . . . . . . . . . . . . . . . . 14 5.6 Returning Home . . . . . . . . . . . . . . . . . . . . . . 14 6. Home Agent operation . . . . . . . . . . . . . . . . . . . . . 15 6.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 15 6.1.1 Binding Cache . . . . . . . . . . . . . . . . . . . . 15 6.1.2 Prefix Table . . . . . . . . . . . . . . . . . . . . . 15 6.2 Mobile Network Prefix Registration . . . . . . . . . . . . 15 6.3 Forwarding Packets . . . . . . . . . . . . . . . . . . . . 16 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 17 7.1 Protection of Tokens . . . . . . . . . . . . . . . . . . . 17 7.2 how to generate Tokens . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Kumazawa, et al. Expires April 12, 2005 [Page 2] Internet-Draft Token based DND October 2004 1. Introduction Today, Mobile Internet Access using various kinds of wireless access technologies is gaining in popularity. 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 the network most suitable for mobile Internet access from the various access networks available according to the user's location and preference. However, it is difficult to add various wireless access interfaces to all portable devices for reasons of cost and size. Wireless PAN (W-PAN) is one possible solutions enabling ubiquity. A W-PAN consists of a collection of portable devices with short distance wireless interfaces and some of them have additional access interfaces providing 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 attachment 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 maintaining bi-directional tunnels between Mobile Routers and their Home Agents. Devices with Internet access interfaces in a W-PAN act as Mobile Routers. Mobile Network with multiple Mobile Routers providing multiple points of attachments to the Internet is one of Multihomed Mobile Networks [1][3]. It is necessary to consider the issues relevant to the support of Mobile Network Prefixes by multiple Mobile Routers in a single Mobile Network. If each Mobile Router supports different prefixes, nodes in the Mobile Network must change its source address when they send packets via a different Mobile Router, which makes it difficult to maintain continous sessions. And a Home Agent needs to forward a data packet meant for a node to just one Mobile Router which supports the prefix of the node. Hence, to provide advantages of multihoming, it is important to allow multiple Mobile Routers in the same mobile network to support the same prefix. However, 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. If Mobile Routers claiming the same prefix are in different places, packets forwarded from the Home Agent to one of the Mobile Routers might not reach correct recipient since it might be behind another Mobile Router. 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 the NEMO working group mailing list [7]. Kumazawa, et al. Expires April 12, 2005 [Page 3] Internet-Draft Token based DND October 2004 Some solutions have already been proposed in the mailing list. In the proposed solutions, a Home Agent confirms connectivity between the Mobile Routers claiming the same prefix before it acknowledges a new binding update. These solutions have the following problems: o If the bi-directional tunnel between the first Mobile Router and the Home Agent is unavailable temporarily, the DND test can't be done. o Confirmation of connectivity before acknowledgement leads to some delay. This document describes a new DND solution using Tokens (Token based DND). The Token based DND can do DND tests without above problems. Since the Token based DND is compatible with NEMO Basic Support, Token-based-DND-aware Mobile Routers and Home Agent can coexist with existing Mobile Routers and Home Agents. Kumazawa, et al. Expires April 12, 2005 [Page 4] Internet-Draft Token based DND October 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]. This document assumes that the reader is familiar with Mobile IPv6 as defined in [5] and with the concept of Mobile Router defined in the NEMO terminology document [4]. Owner When a Mobile Router owns Mobile Network prefixes (ex. manual-configured or obtains with DHCP), the Mobile Router is defined as an Owner of the Prefixes. Borrower When a Mobile Router supports a Mobile Network prefix from the Owner of the Prefix, the Mobile Router is defined as an Borrower of the Prefix. Token It is a number associated with a Mobile Network Prefix. It is generated and updated by the Owner of the Prefix. A Token is set in a Token option following the Mobile Network Prefix Option in a Binding Update and registered with its Home Agent. A Token is also distributed with the Mobile Network Prefix from the Owner to other Mobile Routers (Borrowers) using Router Advertisements. A Token is used for the Home Agent to confirm whether the Borrowers are connected to the Owner or not. The way to generate Token is discussed in Section 7.2. One of the simplest ways is just generating a random number. All zero means 'NULL' and that the Owner doesn't allow its own Prefix to be shared. Kumazawa, et al. Expires April 12, 2005 [Page 5] Internet-Draft Token based DND October 2004 3. Overview Figure 1 shows an example network for describing overview of the operation. +----+ | HA | +--+-+ | +-----------------------+ +------+ | Internet |-----+ CN | +-----------------------+ +------+ | | +-----+ +-----+ | MR1 | | MR2 | +--+--+ +--+--+ |P1:: |P2:: --------------------------- | P1::a | P2::b +--+--+ +--+--+ | LFNa| | LFNb| +-----+ +-----+ Figure 1: example network MR1 and MR2 establish bi-directional tunnels with their Home Agent. Mobile Network Prefixes MR1 and MR2 register are P1 and P2 respectively. LFNa and LFNb configures its address with P1::a and P2::b. MR1, MR2, and LFNa,LFNb are connected via a link. This configuration can be expressed as (2,1,2) based on the notation in [1]. This Mobile Network consists of two logical independent network P1::/64 and P2::/64. MR1 can neither forward LFNb's packets nor MR2 can do LFNb's ones currently. 3.1 Registration as an Owner As MR1 is the Owner of prefix P1, MR1 generates and updates a Token corresponding to P1. MR1 sends a Binding Update including a Mobile Network Prefix Option of P1 to the Home Agent when it attaches to a new access router. And MR1 sets a Prefix Delegated flag (D) to 0 in the Mobile Network Prefix option to indicate that it is the Owner of P1 and MUST put a Token option next to that in the Binding Update. If the Home Agent receives and processes the message successfully, the Home Agent stores the token and acknowledges it by sending MR1 a Binding Acknowledgement indicating that the prefix and the Token is processed successfully. Kumazawa, et al. Expires April 12, 2005 [Page 6] Internet-Draft Token based DND October 2004 After MR1 receives the Binding Acknowledgement, MR1 starts advertising P1 and the Token using Router Advertisements in the Mobile Network. After MR2 registers P2 and the corresponding Token, it advertises them in the same way as MR1. MR1(owner of P1) MR2(owner of P2) HA | | | |-----BU [P1, token, owner]--------|--------------------------------->| | | | |<---------------------------------|---------BA [status=OK]-----------| | | | |--------RA[P1, token]------------>| | | | | | |-----BU [P2, token, owner]------->| | | | | |<--------BA [status=OK]-----------| | | | |<--------RA[P2, token]------------| | Figure 2: sequence: Registration as an Owner Figure 2 shows the sequence where MR1 and MR2 register their own prefixes as Owners. 3.2 Registration as a Borrower When MR2 receives a Router Advertisement with prefix option including P1 and the corresponding Token from MR1, MR2 configures P1 as a prefix which it supports in addition to P2. To indicate support of P1 and P2 to the Home Agent, MR2 sends a Binding Update with two Mobile Network Prefix Options followed by corresponding Token options respectively. The token options for each of the prefix MUST follow the network prefix option as the ordering is used to match a particular prefix to a particular token. Figure 3 shows options in the Binding Update sent from MR2 to the Home Agent. First MNP option includes P2 with the Prefix Delegated Flag (D) set to 0 and the next MNP option includes P1 with the flag set to '1'. Kumazawa, et al. Expires April 12, 2005 [Page 7] Internet-Draft Token based DND October 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 |0| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Mobile Network Prefix(P2) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token for P2 (generated by MR2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |1| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Mobile Network Prefix(P1) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token for P1 (generated by MR1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Mobility Options of the Binding Update sent from MR2 When the Home Agent receives the Binding Update from MR2, it updates the entry of P2 and examines the Token option following the prefix option of P1. When it equals to the Token registered by MR1, the Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement. MR2 becomes the Owner of P2 and the Borrower of P1 after the registration finishes successfully. MR1 registers as the Owner of P1 and the Borrower of P2 as well. Hence data packets meant for P1 and P2 can be forwarded via either MR1 or MR2. 3.3 Refreshment of Token A Token is updated periodically and registered with a Home Agent by the Owner of the prefix. After the Owner finishes registration successfully, they include the updated Tokens in Router Advertisements. When the Borrower finds the Token updated, it sends a Binding Update with the updated Token to the Home Agent. If the Borrower moves away from the Mobile Network and Router Advertisements from the Owner do not reach it, it can't obtain the updated Token. After the Token is updated, Binding Updates with old Tokens are rejected by the Home Agent. Hence, a Borrower which moves away from the mobile network Kumazawa, et al. Expires April 12, 2005 [Page 8] Internet-Draft Token based DND October 2004 can't keep sharing the prefix. 3.4 Registration Request from Token based DND-unaware Mobile Routers A Binding Update without Token option means that the prefix 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 April 12, 2005 [Page 9] Internet-Draft Token based DND October 2004 4. Format 4.1 Mobile Network Prefix Option A new Prefix Delegated flag (D) is included in a Mobile Network Prefix Option to indicate that the prefix is owned (0) or borrowed(1) by a Mobile Router sending the Binding Update. The rest of the Mobile Network Prefix Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |D| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Delegated Flag (D) The Prefix Delegated Flag is used to indicate to its Home Agent that the Mobile Network Prefix is owned or borrowed. If the flag is set to 0, the prefix is owned by the Mobile Router. If the flag is set to 1, the prefix is borrowed from another Mobile Router(Owner). 4.2 Token Option Token options are included in a Binding Update. A Token option corresponds to a Mobile Network Prefix Option placed ahead it. Token options are also included in Router Advertisements distributed from an Owner to Borrowers. In a Router Advertisement, a Token option is placed next to a Prefix Option including the Mobile Network Prefix. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kumazawa, et al. Expires April 12, 2005 [Page 10] Internet-Draft Token based DND October 2004 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. 4.2.1 Binding Acknowledgement The Binding Acknowledgement format used in this document is the same as defined in [2]. This document introduces the following new Binding Acknowledgement status values. 2 (TBA) DND test and set up are completed successfully Kumazawa, et al. Expires April 12, 2005 [Page 11] Internet-Draft Token based DND October 2004 5. Mobile Router Operation A Mobile Router is defined as either Owner or Borrower for each Mobile Network Prefix it supports. An Owner and Borrowers share Mobile Network Prefixes using Token. 5.1 Data Structure A Mobile Router maintains a 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). The followings are relationships between Token and Prefix Delegated Flag (D). Prefix Delegated Flag (D) is set to 0 ( the Prefix is owned by the Mobile Router) * Token is generated or updated by the Owner. 'NULL' in Token field means that the Prefix is not shared. Prefix Delegated Flag (D) is set to 1 (the Prefix is borrowed from an Owner) * Token is extracted from Router Advertisements sent from the Owner. 5.2 Sending Binding Updates A Mobile Router sends a Binding Update including Mobile Network Prefix Options described in Section 5.2 of [2]. The difference from [2] is that a Mobile Router sets a Prefix Delegated Flag (D) of each Mobile Network Prefix Option and adds Token Options if necessary. A Mobile Router MUST send a Binding Update in Explicit mode when it uses any Token option. A Mobile Router includes options and sets flag of the options in the Binding Update as follows. When the Mobile Router includes Token Options in a Binding Update, it MUST put each Token Option next to the corresponding Mobile Network Prefix option. Owner The Mobile Router sets the Prefix Delegated Flag (D) to 0 in a Mobile Network Prefix Option and MUST put a Token Option next to it when the Mobile Router allows the Prefix to be shared. The Mobile Router doesn't put a Token Option when it doesn't allow sharing the Prefix. Kumazawa, et al. Expires April 12, 2005 [Page 12] Internet-Draft Token based DND October 2004 Borrower A Mobile Router sets the Prefix Delegated Flag (D) to 1 in a Mobile Network Prefix Option and puts a Token Option next to it. Mobile Network Prefix Option MUST be followed by the corresponding Token Option when its Prefix Delegated Flag is set to '1'. 5.3 Receiving Binding Acknowledgements If the status field of Binding Acknowledgement is '2' to indicate that the Home Agent processed prefixes and Tokens successfully, the Mobile Router assumes that the Home Agent set up forwarding for all the Prefixes including borrowed ones. The Mobile Router can then start using bi-directional tunnels for the Prefixes. If the status is set to '0', the Mobile Router assumes that the Home Agent isn't aware of the Token based DND and acts as described in [2]. In this case the Mobile Router SHOULD re-send the Binding Update including only its own Prefixes without Token Options. After the Binding finishes successfully, the Mobile Router then starts sending Router Advertisement including Prefixes which it owns and corresponding Tokens if any. The Mobile Router MUST NOT advertise Prefixes nor Tokens of which it is not the Owner but the Borrower. The Mobile Router SHOULD NOT include a Token option which is set to NULL in Router Advertisement messages. When the Mobile Router receives a Router Advertisement including a new Prefix and a corresponding Token from the Owner of the Prefix, it MAY become the Borrower of the Prefix by sending a Binding Update along with the token option. 5.4 Error Processing This document doesn't introduce any new Binding Acknowledgement status value for errors. Since the Token based DND operates only in Explicit mode, the Mobile Router interprets the Binding Acknowledgement status values as described in Section 5.4.2 of [2]. A Mobile Network Prefix with Prefix Delegated Flag set to '1' will be rejected in two cases. One is when the Token is different from that registered by the Owner and the other is when no Owner registers the Prefix. The Binding Acknowledgement is returned with status '141' in both of the cases. In these cases, the Mobile Router SHOULD wait until an updated Token is distributed from the Owner or send a Binding Update without the Mobile Network Prefix borrowed from the Owner. Kumazawa, et al. Expires April 12, 2005 [Page 13] Internet-Draft Token based DND October 2004 5.5 Token Update An Owner MUST update Tokens periodically. When a Borrower moves away from the mobile network, the Tokens held by the Borrower would be obsolete and enable the Home Agent to find the movement of the Borrower. The Owner MUST advertise the updated Tokens using Router Advertisement as soon as it finishes the registration of the Tokens. The Owner MUST NOT advertise the updated Tokens until it receives the Binding Acknowledgement message indicating that the Home Agent finishes the registration successfully. The Owner need not include Token options in the Binding Update when it doesn't intend to update them. The Owner sets 'NULL' to the Token in the Binding Update when it intends to stop the sharing of the prefix by other Mobile Routers (Borrowers). The Borrower MUST send a Binding Update including the update Tokens as soon as it finds the Tokens updated in Router Advertisement. 5.6 Returning Home When a Mobile Router returns home, it de-registers with its Home Agent. After de-registration, the Mobile Router MUST NOT include any Token option corresponding to its own Prefixes in Router Advertisements since Tokens can't be registered with the Home Agent at home. This means that Mobile Network Prefixes can't be shared while the Owner of the Prefixes is connected to home link. The Borrower MUST send a Binding Update not including the Prefixes as soon as it finds the corresponding Token options removed from Router Advertisement from the Owner. Kumazawa, et al. Expires April 12, 2005 [Page 14] Internet-Draft Token based DND October 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 [5] and [2]. This document introduces a new Token field and a Prefix Delegated Flag (D). A Home Agent stores a Token corresponding to a Mobile Network Prefix when the Prefix Delegated Flag is set to '0' in the Mobile Network Prefix Option. 6.1.2 Prefix Table Prefix Delegated Flag (D) might need to be introduced in a Prefix Table Entry since the Home Agent SHOLUD be able to prevent the following cases: o As an Owner, a Mobile Router claims Mobile Network Prefixes owned by another Mobile Router (Owner). o A Mobile Router borrows Mobile Network Prefixes not allowed from the Owner of them. 6.2 Mobile Network Prefix Registration A Home Agent performs the following check of all of the Mobile Network Prefix Options and Token Options in the Binding Update in addition to checks in [2] in the case Mobile Router Flag (R) is set. o If there is any Token option which isn't placed next to a Mobile Network Prefix Option, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). When the Prefix Delegated Flag (D) is set to '0', it performs the following checks. o If there is already a binding cache entry or Prefix Table entry which has the same Prefix owned by another Mobile Router (Prefix Delegated Flag (D) is set to '0'), the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 142 (Not Authorized for Prefix). When the Prefix Delegated Flag (D) is set to '1', it performs the following checks. Kumazawa, et al. Expires April 12, 2005 [Page 15] Internet-Draft Token based DND October 2004 o The Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix) in the following cases: * The Mobile Network Prefix Option isn't followed by a Token Option. * NULL (all zero) is set in a Token Option. * The Mobile Network Prefix is not registered by any Owners. * The Token is different from that registered by an Owner in the Binding Cache Entry. When the Home Agent has a valid binding cache entry with a Prefix Delegate Flag (D) set '1', it SHOULD NOT delete the entry with just one error of a Token. This is because a Borrower may not be able to obtain an updated Token as soon as the update occurs necessarily. However, the Home Agent might need to delete the entry if the number of errors exceeds threshold before it expires. If all checks are passed, the Home Agent creates a binding cache entry for Mobile Router's Home Address, or updates the binding cache entry if it already exists. When it has a valid binding cache entry with a Prefix Delegated Flag (D) set to '0' and it receives the Binding Update including the Mobile Network Prefix Option without a Token Option, the Home Agent doesn't update the Token. When it creates a binding cache entry with Prefix Delegated Flag (D) set to '0' by receiving a Binding Update including a Mobile Network Prefix Option without a Token Option, it sets NULL in the Token field of the entry. After setting up Mobile Network Prefixes and corresponding Tokens and forwarding, the Home Agent sends a Binding Acknowledgement with status set to '2' to indicate that the setup finishes successfully. If all of the tokens set up with the Binding Update are configured to 'NULL' and no Token option is included in the Binding Update, it MUST send the Binding Acknowledgement with status '0'. 6.3 Forwarding Packets When the Home Agent forwards a data packet destined for a Mobile Network Prefix, the Home Agent selects one Mobile Router among an Owner and Borrowers of the Prefix. This selection will be done based on various policies. The selection of Mobile Router is outside the scope of this document. Kumazawa, et al. Expires April 12, 2005 [Page 16] Internet-Draft Token based DND October 2004 7. Security Consideration 7.1 Protection of Tokens Tokens MUST NOT be obtained except by a Home Agent and nodes including Mobile Routers within a Mobile Network. Token Option in Binding Updates from a Mobile Router to the Home Agent would be protected with IPsec. Router Advertisements including Token Option MUST be prevented from being snooped by nodes outside the Mobile Network using some security mechanism such as layer 2 encryption. 7.2 how to generate Tokens A Token is used for a Home Agent to confirm reachability between an Owner and Borrowers via just one link. The following is not goal of using Tokens: o To indicate to the Home Agent that a Mobile Router claiming a Mobile Network Prefix is a true Owner of the Prefix. Hence it is enough to generate a random number as a Token and a Token need not be associated with any information. 8 References [1] Ernst, T., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-00 (work in progress), July 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-ernst-generic-goals-and-benefits-00 (work in progress), July 2004. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004. [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] IETF NEMO (NEtwork MObility) working group mailing list, Archive: http://www.ietf.org/html.charters/nemo-charter.html. Kumazawa, et al. Expires April 12, 2005 [Page 17] Internet-Draft Token based DND October 2004 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 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 April 12, 2005 [Page 18] Internet-Draft Token based DND October 2004 Appendix A. Change Log From -00 to -01 o Added (n,*,n) case to (n,*,1) case. o Moved Prefix Delegated Flag from Binding Update to Mobile Network Prefix Option o Only Owner can generate tokens while a Home Agent could also do in -00. Kumazawa, et al. Expires April 12, 2005 [Page 19] Internet-Draft Token based DND October 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 April 12, 2005 [Page 20]