Internet Draft Pekka P„„kk÷nen Document:draft-paakkonen-nemo-prefix-delegation-00.txt Juhani Latvakoski Expires: September 2003 March 2003 Mobile Network Prefix Delegation extension for Mobile IPv6 draft-paakkonen-nemo-prefix-delegation-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft proposes a dynamic Mobile Network Prefix (MNP) delegation extension for Mobile IPv6 protocol to enable MNP delegation for mobile networks. A MNP is an IPv6 prefix used in a mobile network. The extension supports dynamic delegation, return, refreshing and updating operations related to MNP delegation operations between a Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). This extension is proposed, because there is a lack for a dynamic MNP delegation protocol related to mobile networks, and currently MNPs have to be assigned statically to enable mobile networking. P„„kk÷nen et al. Expires September 2003 [Page i] INTERNET-DRAFT MNP Delegation March 2003 Table of contents Abstract i 1. Introduction i 2. Terms 1 3. Terminology 1 4. Overview 1 4.1. MIPv6 extension overview..................................... 2 5. Protocol .......................................................... 3 5.1. Operational environment ..................................... 3 5.2. Messages .................................................... 3 5.2.1 MNP Delegation Message ................................. 4 5.3. Options ..................................................... 6 5.3.1. MNP Option ............................................ 6 5.3.2. MNP Data Option ....................................... 7 5.4. Operation ................................................... 8 5.4.1. MNP Query sequence .................................... 8 5.4.2. MNP Delegation sequence .............................. 11 5.4.3. MNP Refresh sequence ................................. 12 5.4.4. MNP Return sequence .................................. 13 5.4.5. MNP Update sequence .................................. 15 5.5. Examples ................................................... 17 5.5.1. MNP Query sequence ................................... 17 5.5.2. MNP Delegation sequence .............................. 19 5.5.3. MNP Update sequence .................................. 21 6. Constants 23 7. Security issues 23 Acknowledgements 23 References 23 Author's addresses 24 Full Copyright Statement 25 1. Introduction This document describes how one or more Mobile Network Prefixes (MNP) can be delegated to a mobile network with extensions to Mobile IPv6 [2] protocol. MNP is an IPv6 prefix used in a mobile network. By using the extensions proposed in this document it is possible to dynamically delegate MNPs for a mobile network. MNP Delegation is executed between a Mobile Router (MR) of a mobile network and its Home Agent (HA). MR acquires, refreshes and returns MNPs from its HA according to its needs. HA controls the delegation of MNPs to MRs. HA can also inform about new P„„kk÷nen et al. Expires September 2003 [Page 1] INTERNET-DRAFT MNP Delegation March 2003 valid and preferred lifetimes regarding the delegated MNPs. The extension described in this document is needed, because there is no mechanism for dynamic delegation of MNPs to mobile networks, but instead MNPs have to be assigned statically to mobile networks. 2. Terms The terminology used in this document is defined in an other Internet draft [3]. In addition to this, some new terms are defined. MNP Requestor = MR which delegates MNPs from its HAs. MNP Delegator = HA which delegates MNPs to a MR. MNP Delegation = The delegation of a MNP from a HA to a MR. MNP Refreshing = MNP delegation lease extension initiated by the MR. MNP Returning = Returning of a MNP from MR to its HA after the initial MNP delegation of the MNP. This operation is executed when the MR no longer needs the delegated MNP, and returns it back to the HA which originally delegated the MNP. MNP Updating = The delegated MNP might change for example because of renumbering operations at the HA. This function is used to inform MR of valid and preferred lifetime changes regarding the leased MNP. Transaction identifier = An identifier used to match a request message to a response. This kind of message exchange forms a transaction between communicating parties. 3. 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 [1]. 4. Overview The environment for this solution is defined in the NEMO working group (WG) [4]. The NEMO WG is developing a solution for a mobile network, which is based on one or more MRs connecting a mobile network to the Internet. The basic approach is to use Mobile IPv6 and bidirectional tunneling between the MR and its HA to enable transparent session mobility for the Mobile Nodes (MN) of the mobile network. The MNP is an IPv6 prefix of arbitrary length, which identifies an entire mobile network within the Internet topology [3]. This document focuses on the dynamic MNP delegation for a NEMO-network. Dynamic MNP assignment for a NEMO-network using MIPv6 is desirable for the following reasons: 1. Static MNP assignment for a mobile network is laborious - If a MNP will be statically allocated for each mobile network, it P„„kk÷nen et al. Expires September 2003 [Page 2] INTERNET-DRAFT MNP Delegation March 2003 demands a great deal of management and configuration work related to MNPs. There might be millions of mobile networks in the future and manual allocation of a MNP for each mobile network is laborious. 2. A mobile network may need a MNP in an ad-hoc way - MNP allocation might be managed using Router Renumbering for IPv6 [5]. But the mobile network could be formed in an ad-hoc way in which case the MR initially does not have a MNP and requests for it dynamically. In this case [5] is insufficient and a dynamic protocol for MNP delegation is needed. This requirement assumes that there is a need for dynamic mobile network formation. 3. Lifetime of the mobile network is not necessarily infinite - Use cases of such situations are expected to occur in Personal Area Networks (PAN), which require mobile networking capabilities only for a short time. Addressing resources are wasted, if the delegated MNP of the mobile network is not used. The MNP should be possible to be returned dynamically to the MNP delegator, after it is no longer used. 4. HA of the MR needs to know the MNP used in the mobile network - According to the solution defined in [6], HA needs to know the MNP used in the mobile network in the "static" MR scenario, in which a routing table entry must exist in the HA of the MR. [11] defines a solution for mobile networks, which requires a binding cache entry in the HA, binding the MNP used on the ingress interface of the mobile network to the COA used on the egress interface. Because information of the MNP used in the mobile network is needed in MR's HA, it is suggested that dynamic MNP delegation operations are executed between the MR and its HA. Because in that case MNP delegation messages are needed between the MR and its HA, it is suggested that dynamic MNP delegation functionalities are implemented as a MIPv6 extension. 4.1 MIPv6 extension overview The defined extension borrows from the Automatic IPv6 Prefix Delegation Protocol [7] and from IPv6 Prefix Options for DHCPv6 [8] drafts. Some of the features in those documents are embedded to the MIPv6 extension protocol defined in this document. MR of a mobile network acts as a MNP requestor and HA as a MNP delegator. One new ICMPv6 message and new options inside of it (MNP Delegation-Message) are defined to be used in the extension. New ICMPv6 codes for MNP delegation related signalling are also defined. This means that the MR can dynamically request, return and refresh a MNP from its HA. Also MNP lifetime updates from the HA to the MR are supported. HA allocates the MNP(s) to the MR for a certain period of time. The MNP can be delegated to the MR either temporarily or permanently. In figure 1 an example can be seen of the extension's usage. In the example MR is at a foreign domain and MR acquires a MNP and sends a MNP Delegation-Message to its HA. HA allocates a MNP for the MR and sends back a MNP Delegation response and the delegated MNP. MR receives the MNP and starts advertising it on its P„„kk÷nen et al. Expires September 2003 [Page 3] INTERNET-DRAFT MNP Delegation March 2003 local links using Router Advertisements. MR can delegate MNPs also when it is at home. More examples of the protocol usage have been demonstrated in chapter 5.5. _________ (Internet )------------Home network--HA (_______) / | 2. code: 'MNP Delegated' / /\ 1. code: 'MNP Request' | / / Foreign network / / | \/ / ( MR )-----------------------/ ( | ) ( | ) 3. Router Advertisement (MNP) ( | ) ( MN ) ---- Figure 1. MNP delegation for a MR in a foreign network. 5. Protocol In this chapter the MIPv6 protocol extension for dynamic MNP delegation is defined. 5.1 Operational environment There are two entities participating in the protocol as can be seen in figure 2. MNP delegator is MR's home agent, which can delegate MNP(s) for the MR. MR is a MNP requestor, and requests MNP(s) from its HA. MR can have multiple HAs i.e. MNP delegators. __________ ( Internet )------Home network--HA (________) (MNP delegator) | | | MR (MNP requestor) Figure 2. Protocol entities. 5.2 Messages There is one new ICMPv6 message defined for the MIPv6 protocol. MNP Delegation-Message is used by the MR to query and request HA for MNP(s), return MNP(s) and refresh the lease of MNP(s). MNP Delegation-Message can also be used by HA to signal MR of updating operations regarding the leased MNP(s). The same message type is used as a response to these operations. Different type of operations and responses are distinquished by the different ICMPv6 code types. P„„kk÷nen et al. Expires September 2003 [Page 4] INTERNET-DRAFT MNP Delegation March 2003 5.2.1 MNP Delegation-Message MNP Delegation-Message is used by MR to query, request, refresh and return MNP(s). It is also used by the HA to inform MR of updating operations. Message format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | IP fields Source Address Source IPv6 address of MR or its HA Destination Address Destination address of MR or its HA. Hop Limit Set to an initial hop limit value, similarly to any other unicast packet sent by a mobile node. Routing Header: A routing header of type 2 MUST be added to the message if HA is sending a MNP Delegation-Message to the MR and MR is not at home i.e has a binding in the HA's binding cache. Otherwise a routing header of type 2 MUST not be used. AH or ESP header: IP security is not discussed in this version of the draft. ICMP fields: Type: xxx for MNP Delegation-Message Code: P„„kk÷nen et al. Expires September 2003 [Page 5] INTERNET-DRAFT MNP Delegation March 2003 MNP Delegator Query (0) The MNP Delegator Query message is used by the MR to query MNP delegators (HAs) and their abilities to delegate MNP(s). This message is sent to MR's HA during the MNP Query sequence. MNP Request (1) The MNP Request message is used by the MR to request for MNP(s) from its HA(s). This message is sent during the MNP Delegation sequence. MNP Refresh (2) The MNP Refresh message is used by the MR to request a refresh on the lifetimes of delegated MNP(s). This message is sent during the MNP Refresh sequence. MNP Return (3) The MNP Return message is used by the MR to return delegated MNP(s) to its HA. This message is sent during the MNP Return sequence. MNP Delegator (4) A MNP Delegator message is sent by the HA during MNP Query sequence. It is used to inform MR of MNP(s) HA is capable of delegating. MNP Delegated (5) A MNP Delegated message is used by HA during MNP Delegation and MNP Refresh sequence. It is used to inform MR of delegated and refreshed MNP(s). MNP Returned (6) A MNP Returned message is sent by HA during MNP Return sequence. It is used to inform MR of returned MNP(s). MNP Unavailable (7) A MNP Unavailable message is used in all the sequences to inform of non-valid MNP(s) operations. MNP Update (8) A MNP Update message is used by HA to inform MR of lifetime changes concerning the delegated MNP(s). MNP Update-Ack (9) P„„kk÷nen et al. Expires September 2003 [Page 6] INTERNET-DRAFT MNP Delegation March 2003 A MNP Update-Ack is used by MR to responde to MNP Update messages sent by its HA. Checksum The ICMP Checksum as defined in [9]. Transaction identifier An unique identifier used to match a MNP Delegation-Message request to a corresponding MNP Delegation-Message response. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Options: Destination Option: A Home Address destination option MUST be included if MR sends a MNP Delegation-Message and is away from home. MNP Option: MUST contain one MNP Option. The MNP requestor and MNP Delegator can describe the MNP(s) by adding a MNP Option to the MNP Delegation-Message. 5.3 Options In this chapter the new options, which are used in the new ICMP message, are defined. 5.3.1 MNP Option This option is used in MNP Delegation-Message. It is used to contain MNP information in one or more MNP Data Options. Option format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Option length | Option body +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type: 0x01 P„„kk÷nen et al. Expires September 2003 [Page 7] INTERNET-DRAFT MNP Delegation March 2003 Option length: Length of option body. Option body: Message body can contain up to x MNP Data Options. However it is recommended that the IPv6 packet size is smaller the MTU for IPv6 (1280 octets) [10] which limits the number of MNP Data Options used in a MNP Option. 5.3.2 MNP Data Option MNP Data Option holds MNP information related to a single MNP. Option format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix length | IPv6 prefix (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Match | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 0x02 Preferred lifetime: The recommended lifetime for the MNP in the option expressed in seconds. A value of 0xffffffff represents infinity. Valid lifetime: The valid lifetime for the MNP in the option expressed in seconds. A value of 0xffffffff represents infinity. Prefix length: Length for this MNP in bits. P„„kk÷nen et al. Expires September 2003 [Page 8] INTERNET-DRAFT MNP Delegation March 2003 IPv6 prefix: A MNP. Match: This field is used to indicate MNP preference of the MR during MNP Query and MNP Delegation sequences. Defined values: 0, indicates that MNP query/delegation is based on both MNP and its length indicated by the values in Prefix length and IPv6 prefix fields in the MNP Data Option. 1, indicates that MNP query/delegation is based only on MNP length indicated by the value in Prefix length field in the MNP Data Option. 5.4 Operation In this chapter operation of the protocol is described. 5.4.1 MNP Query sequence The MNP Query sequence consists of a transaction between the MR and its HA. A transaction consists of a MNP Delegation-Message and MNP Delegation-Message response exchange with the same transaction identifiers. The sequence is initiated by the MR to query its HA's capabilities to delegate MNP(s) to the MR. This sequence can be performed multiple times with one or more HAs. After the MR has queried the capabilities of its HAs with this sequence, MR should advance to MNP Delegation sequence with the chosen HA to proceed with MNP delegation. MR functionality: The MR might initially know the addresses of one or more of its HAs. If the MR is at home, it learns the HA's address by receiving Router Advertisements from its HA. If MR is away from home and does not know any HA addresses, it SHOULD initiate Dynamic Home Agent Discovery as defined in section 11.4.1 of [2]. After MR knows the addresses of one or more HAs, the MNP Query sequence can be executed. The MNP Query sequence consists of a transaction between the MR and its HA. Transactions are initiated by the MR to query the capabilities of MR's HA to delegate MNPs. A transaction consists of a MNP Delegation-Message sent by the MR to its HA and a MNP Delegation-Message response sent back to the MR by the HA. MR initiates the transaction by sending a MNP Delegation-Message with code 'MNP Delegator Query' to one of its HAs. The MNP Delegation-Message is constructed by the MR always independently of its ICMPv6 code as follows: P„„kk÷nen et al. Expires September 2003 [Page 9] INTERNET-DRAFT MNP Delegation March 2003 - IP source address field: The source address SHOULD be set to its current Care-Of-Address if MR is away from home. If MR is at home, its home address MUST be used. - IP destination address field: Destination address MUST be set to HA address. If MR is away from home, the HA to which MR has a binding update list entry MUST be used. Otherwise the stored HA address SHOULD be used. - Home address destination option: MR's home address MUST be included in a Home Address destination option, if MR is not at home. - Transaction identifier: The Transaction identifier SHOULD be chosen randomly to identify this transaction uniquely. - MNP Option: A MNP Option MUST be set in the message to describe the MNP(s) MR is interested in. One MNP Data Option inside the MNP Option describes one MNP for delegation. The valid and preferred lifetimes MAY be set to indicate MR's preference for MNP(s). Match field MUST be set as described in section 5.3.2. - Binding update list: If MR is away from home it MUST have a binding entry in the binding cache at its HA, with which it is communicating. This means that the HA's address MUST be present in the binding update list of the MR. In this case the code of the MNP Delegation-Message MUST be set to 'MNP Delegator Query'. If the MR doesn't receive a MNP Delegation-Message response back within MNP_REQUEST_DELAY milliseconds, the previously sent MNP Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to the same HA. When MR receives a MNP Delegation-Message within MNP_REQUEST_DELAY milliseconds, it SHOULD check it as follows independently of its ICMPv6 code: - ICMPv6 type: Check that the ICMPv6 type of the received message is MNP Delegation-Message. - IP destination address field: If MR is at home, check that the destination address in the IP header field is MR's home address. If MR is not at home, check that the destination address is MR's COA. - IP source address field: Check that the IP source address field of the message is the same as the destination address in the corresponding MNP Delegation-Message with the same transaction identifier. - Routing header type 2: If MR is not at home, the packet MUST have a type 2 routing header with MR's home address and destination IP header field has MR's COA. - MNP Option: Check that a MNP Option with one or more MNP Data Options is present in the message. If these conditions are not met, MR MUST silently ignore the message. If the code of the MNP Delegation-Message response is 'MNP Delegator', MR knows that the HA is capable of delegating the MNP(s) in the MNP Option. If the MNP in the received MNP Data Option is all zeros, HA is not capable of delegating the wanted MNP. If MR queried for x pieces of MNPs, the information of the MNP queries are in the corresponding places in the reply. For example the second queried MNP information is in the second MNP Data Option of the received MNP Option. If the code is P„„kk÷nen et al. Expires September 2003 [Page 10] INTERNET-DRAFT MNP Delegation March 2003 'MNP Unavailable', MR knows that the HA is not capable of delegating any of the MNPs the MR queried. The queried MNPs are present in the MNP Option of the reply. If MR does not receive any response after MNP_REQUEST_MAX_RETRIES attempts, the MR MAY start the MNP Query sequence again or conclude that its HA is not capable of delegating MNPs. After the MNP Query sequence MR can decide to proceed to MNP Delegation sequence based on the received MNP information in the MNP Option or it can continue with a new MNP Query sequence. MR might continue MNP Query sequence with its HA, because MR might not be satisfied with the capabilities of the HA to delegate MNPs. In that case MR MAY change the MNP descriptions in the MNP Option of the new MNP Delegation sequence. HA functionality: After the HA receives a MNP Delegation-Message from a MR, HA has to check it as follows independently of the code of the message: - ICMPv6 type: The type of the ICMPv6 message MUST be MNP_DELEGATION_MESSAGE. - IP source address field: If the received message has a Home Address destination option, the COA in binding cache of the home address MUST be equal to the IP source address. - IP destination address field: The destination address MUST be the HA's IP address. - MNP Option: Check that the MNP Delegation-Message has a MNP Option with one or more MNP Data Options. If these checks are not valid, HA MUST silently ignore the message. In this case the ICMPv6 code of the received message MUST be 'MNP Delegator Query'. HA can now inform the MR about the MNP(s) it is capable of delegating. It SHOULD make the choice based on the received information in the MNP Option. Each MNP Data Option SHOULD be considered as one MNP information query. If the match field is set to zero in the MNP Data Option, the MNP is wanted to be queried based on MNP and its length. If the match field is set to one, MNP is wanted to be queried only based on MNP length. HA SHOULD follow these preferencies in the sequence, but can inform MNPs based on it own criteria. If a MNP is not wanted to be informed to the MR based on a MNP information query, all zeros MUST be set to the MNP field in the MNP Data Option. If the HA is not capable of delegating any MNP(s) queried for in the request, a MNP Delegation-Message with code 'MNP Unavailable' MUST be sent to the MR. In this case the MNP Data Options MUST be copied from the request message. Otherwise MNP information of the MNP(s), which HA is capable of delegating MUST be attached to the MNP Option of a MNP Delegation-Message. The MNP Data Options in the response MUST follow the order of the information queries in the request. This means that nth MNP Data Option to nth MNP query MUST be in the nth position in the MNP Option. A MNP Delegation-Message P„„kk÷nen et al. Expires September 2003 [Page 11] INTERNET-DRAFT MNP Delegation March 2003 SHOULD be constructed and sent as follows independently of its code: - IP source address field: HA's global IP address is set as source address in the IP header source address field. - IP destination address field: The corresponding MNP Delegation-Message's source address is set as destination address in the IP header destination address field. - Transaction identifier: Copy the Transaction identifier from the MNP Delegation-Message to the response's transaction identifier field. - Routing header type 2: A type 2 routing header MUST be included with the MR's home address if the received MNP Delegation-Message had a Home Address destination option. The home address is received from the Home Address destination option of the corresponding MNP Delegation-Message. - The match field: The match field MUST copied from the request message from the corresponding MNP Data Options. In this case the code 'MNP Delegator' is set as the type of the MNP Delegation-Message. HA might receive multiple identical MNP Delegation-Message messages, because of retransmissions at the MR. The HA SHOULD handle and answer to these messages identically to those received before. 5.4.2 MNP Delegation sequence The MNP Delegation sequence can be initiated by the MR after the MNP Query sequence or without it. It is used by the MR to delegate MNP(s) from its HA(s). After successfully executing the sequence, one or more MNP(s) have been delegated for the MR. MR functionality: The MNP Delegation sequence begins when MR sends a MNP Delegation-Message with an ICMPv6 code of 'MNP Request' to its HA. MR can select the HA for MNP delegation based on the MNP Query sequence. The MNP Delegation-Message is constructed and sent as described in the MNP Query sequence (chapter 5.4.1). The ICMPv6 code of the message is now 'MNP Request'. If the MR receives a MNP Delegation-Message it has to check it as described in chapter 5.4.1 for MR functionality. If the checks are valid, MR SHOULD proceed as follows: - If the code of the response is set to 'MNP Delegated', MR can consider one or more MNP(s) delegated. Those MNP Data Options which have all zeros in the MNP field, could not be delegated. The preferred and valid lifetimes in the MNP Data Options indicate the lifetimes for the delegated MNP(s). MR SHOULD store delegated MNP(s) with MNP length, HA's address and lifetimes (MNP <-> MNP length <-> HA's address <-> valid lifetime left <-> preferred lifetime left <->). This helps when returning or refreshing the delegated MNP. P„„kk÷nen et al. Expires September 2003 [Page 12] INTERNET-DRAFT MNP Delegation March 2003 - If the code is set to MNP Unavailable, none of the wanted MNP(s) were available for delegation. In this case MR MAY proceed MNP Delegation/Query sequence with different MNP preferences. If the MR doesn't receive a MNP Delegation-Message response back within MNP_REQUEST_DELAY milliseconds, the previously sent MNP Delegation-Message MAY be sent up to MNP_REQUEST_MAX_RETRIES times to the same HA. If the MR does not receive a response to its request after sending MNP_REQUEST_MAX_RETRIES requests, MR can conclude that the HA in question is not capable of delegating the wanted MNPs. HA functionality: If HA receives a MNP Delegation-Message with code 'MNP Request' it MUST check the request as described in chapter 5.4.1 for HA functionality. If the checks are valid, HA can proceed as follows: - If the wanted MNP(s) are available for delegation, HA constructs and sends a MNP Delegation-Message as described in chapter 5.4.1 for HA functionality except the ICMPv6 code is set to 'MNP Delegated'. A MNP Option is added to the message based on the MNP(s) to be delegated. The MNP Delegation occurs similarly as in the MNP Query sequence, but in this case the MNP(s) are actually delegated instead of just informing information about available MNPs. The HA SHOULD store the delegated MNP(s) with the home address of the MR, MNP length and lifetimes (MNP <-> MNP length <-> MR's home address <-> valid lifetime left <-> preferred lifetime left). This will later be helpful when refreshing or returning related to the delegated MNP(s) occur. - If the MR cannot delegate any MNP(s) for the MR, it MUST send a MNP Delegation-Message back to the MR with a code 'MNP Unavailable' as described in chapter 5.4.1 for HA functionality. The MNP Option MUST be copied from the corresponding request. The MNP Delegation-Message may not reach its destination and the same message might be retransmitted to the HA. In this case the retransmitted message MUST be handled similarly as previously received identical messages. 5.4.3 MNP Refresh sequence MNP Refresh sequence is initiated by the MR to refresh the lifetimes of leased MNP(s) with finite lifetimes. MR functionality: When the valid or preferred lifetime of a delegated MNP diminishes under a certain threshold, its lease SHOULD be renewed with the MNP Refresh sequence. The recommended time for MNP refreshing is not specified here. MR sets the MNP(s) to be refreshed in a MNP Option and sends a MNP Delegation-Message to the HA from which the MNP(s) were delegated from. The HA's address corresponding to the leased MNP should have been previously stored with the delegated MNP, from which it can P„„kk÷nen et al. Expires September 2003 [Page 13] INTERNET-DRAFT MNP Delegation March 2003 be received for refreshing. The wanted lifetimes for the new MNP delegation can be set according to the MR's preference. The MNP Refresh sequence begins when the MNP Delegation-Message message is constructed and sent as described in chapter 5.4.1 for MR functionality. The ICMPv6 code of the message is now 'MNP Refresh'. If the MR receives a MNP Delegation-Message it has to check it as described in chapter 5.4.1 and in addition to that proceed as follows: - If the code of the response is set to 'MNP Delegated', it can consider the MNP(s) refreshed. The preferred and valid lifetimes in the MNP Data Options indicate the lifetimes for the delegated MNP(s). If a MNP Data Option contains all zeros in the MNP field, the corresponding MNP can be considered as not refreshed. - If the code is set to MNP Unavailable, none of the MNP(s) could be refreshed. In this case the old lifetimes stay valid for the MNP(s). If the MR doesn't receive a MNP Delegation-Message back within MNP_REQUEST_DELAY milliseconds, the previously sent MNP Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to the same HA. If the MR does not receive a response to its request after sending MNP_REQUEST_MAX_RETRIES requests, it might be because the corresponding HA is down for some reason. In this case the MR MAY return to MNP Refresh sequence after some unspecified amount of time. HA functionality: If HA receives a MNP Delegation-Message with code 'MNP Refresh' it MUST check the request as described in chapter 5.4.1 for HA functionality. If the checks are valid, HA can proceed as follows: - If the HA is able to refresh lifetimes of one or more MNPs, HA constructs and sends a MNP Delegation-Message as described in chapter 5.4.1 for HA functionality, except the ICMPv6 code is set to 'MNP Delegated'. The lifetimes of the refreshed MNP(s) MAY be chosen by the delegating HA independently of the requested lifetimes in the MNP. The requested lifetimes SHOULD however be used as guidance when refreshing the MNP(s). All the MNP(s) which can be refreshed by the HA, MUST be included in a MNP Option, which is sent back to the requesting MR in a MNP Delegation-Message. If a MNP cannot be refreshed, all zeros MUST be set to the MNP field in the MNP Data Option. - If the MR cannot refresh any MNP(s), it MUST send a MNP Delegation-Message back to the MR with a code 'MNP Unavailable'. The MNP Option MUST be copied from the corresponding request. The MNP Delegation-Message message may not reach its destination and the same message might be retransmitted to the HA. In this case the retransmitted message MUST be handled similarly as previously received messages. 5.4.4 MNP Return sequence P„„kk÷nen et al. Expires September 2003 [Page 14] INTERNET-DRAFT MNP Delegation March 2003 MNP Return sequence is initiated by the MR when the MR no longer needs the previously delegated MNP(s). MR functionality: When MR no longer needs the leased MNP(s) for some reason, it SHOULD return them to the HA, which delegated the MNP(s). This is executed with the MNP Return sequence. The information related to the MNP(s) to be returned MUST be included inside a MNP Option, which is placed inside the MNP Delegation-Message. The MNP Return sequence begins when the MNP Delegation-Message is constructed and sent as described in chapter 5.4.1 for MR functionality. The ICMPv6 code of the message is now set to 'MNP Return'. HA's address should have been stored during MNP Delegation, and is used now as a destination address. If the MR receives a MNP Delegation-Message it has to check it as described in chapter 5.4.1 for MR functionality and if the checks are valid, proceed as follows: - If the ICMPv6 code of the response is set to 'MNP Returned', MR can consider those MNP(s) returned, which have zero lifetimes in the MNP Option. If a MNP Data Option contains all zeros in the MNP field, the corresponding MNP can be considered as not returned. - If the ICMPv6 code is set to MNP Unavailable, none of the MNP(s) in the MNP Option were returned. In this case the old lifetimes stay valid for the MNPs. If the MR doesn't receive a MNP Delegation-Message back within MNP_REQUEST_DELAY milliseconds, the previously sent MNP Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to the same HA. If the MR does not receive a response to its request after sending MNP_REQUEST_MAX_RETRIES requests, it might be because the corresponding HA is down for some reason. In this case the MR MAY return to MNP Return sequence after some unspecified amount of time. HA functionality: If HA receives a MNP Request with ICMPv6 code 'MNP Return', it MUST check the request as described in section 5.4.1 for HA functionality. If the checks are valid, the HA can proceed as follows: - HA has to determine if the returned MNP(s) have been delegated by the HA to the requesting MR. The MNP(s) which have not been delegated by the HA, MUST have all zeros in the MNP field in the MNP Data Option. The MNP(s) which have been delegated by the HA and can be returned, MUST be included in the MNP Data Options of the response. The lifetimes of those MNP(s) MUST be set to zero to indicate that they are not valid anymore. HA constructs a MNP Delegation-Message as described in chapter 5.4.1 for HA functionality except the ICMPv6 code is set to 'MNP Returned'. - If none of the MNP(s) belong to the HA, a MNP Delegation-Message with P„„kk÷nen et al. Expires September 2003 [Page 15] INTERNET-DRAFT MNP Delegation March 2003 the ICMPv6 code of 'MNP Unavailable' has to be returned to the requestor as described in chapter 5.4.1 for HA functionality. The MNP Option MUST be copied from the corresponding request. The MNP Delegation-Message message may not reach its destination and the same message might be retransmitted to the HA. In this case the retransmitted message MUST be handled similarly as previously received identical messages. 5.4.5 MNP Update sequence MNP Update sequence is initiated by the HA when the valid or preferred lifetimes of a delegated MNP are changed by the HA. With this sequence those lifetime changes are informed to the MR, which originally delegated the MNP. The MR might detect that the lifetimes of a delegated MNP have been changed to zero by its HA. This means that the MNP cannot be used anymore, and a new MNP should be delegated from the HA with the MNP Query/Delegation sequences. HA functionality: When valid or preferred lifetimes on one or more delegated MNPs are changed by the MR, that information is informed to the MR by sending a MNP Delegation-Message with ICMPv6 code 'MNP Update' to the MR as described in chapter 5.4.1 for HA functionality with the following changes to all message handling except IP source address field: - MNP Option: When updating MNP(s), a MNP Option MUST be added to the message to indicate the MNP(s) updating operation is concerned with. The new valid and preferred lifetimes are set to the MNP Data Options. - IP destination address field: The destination address in the IP header MUST be set to the MR's Home Address if that Home Address has no entry in the binding cache. This means that the MR is at home. MR's home address should have been saved during the MNP Delegation sequence with the MNP. Otherwise the COA from the binding cache MUST be used. - Transaction identifier: A new random transaction identifier MUST be used in the transaction identifier field. - Routing header type 2: A type 2 routing header MUST be included with the MR's home address, if the MR's home address has a binding cache entry. - The match field: The match field MUST set to zero in all MNP Data Options to indicate a match based on both MNP and its length. If HA doesn't receive a MNP Delegation-Message message within MNP_REQUEST_DELAY milliseconds, HA SHOULD retransmit the same message. If no response is received after MNP_REQUEST_MAX_RETRIES retransmissions, HA MAY proceed with its own preference. If the MR doesn't respond for any reason, HA MAY initiate MNP Updating sequence again after some time or it might stop sending messages to the MR. However, the HA can only be sure that MR has received the updating MNP Delegation-Message, when HA receives a MNP Delegation-Message with P„„kk÷nen et al. Expires September 2003 [Page 16] INTERNET-DRAFT MNP Delegation March 2003 ICMPv6 code of 'MNP Update Ack'. When HA receives a MNP Delegation-Message with code 'MNP Update-Ack' it SHOULD check it as described in chapter 5.4.1 for HA functionality with the following additional check: - IP source address field: Check that the IP source address field of the message is the same as the destination address in the corresponding MNP Delegation-Message request with the same transaction identifier. If the checks are valid, it SHOULD proceed as follows: - The MNP(s) in the MNP Data Options of the MNP Option indicate the MNP(s), which MR has updated. The HA SHOULD now update the lifetimes on its local storage. If a MNP Data Option contains all zeros in the MNP field, the corresponding MNP can be considered as not updated. - If the code is set to MNP Unavailable, none of the MNP(s) in the MNP Option were updated. In this case the old lifetimes stay valid for the MNPs. MR functionality: When MR receives a MNP Delegation-Message with ICMPv6 code 'MNP Update', it MUST perform checks on all items except IP source address field as described in chapter 5.4.1 for MR functionality with the following additional checks: - IP source address field: Check that the IP source address field of the message is the HA's address from which MR originally delegated the MNP. If the checks are not valid, MR MUST silently ignore the message. Otherwise - Those MNP(s) which have zero lifetimes, are going to be expired and SHOULD not be used anymore after this message is received. Those MNP(s) which have non-zero lifetimes, can be used as before, and the lifetimes of those MNP(s) SHOULD be updated on local storage. Based on the received update message a MNP Delegation-Message MUST be constructed on items concerning IP source address field, Home Address destination option and binding update list as described in chapter 5.4.1 for MR functionality. In addition the other items are constructed as follows: - IP destination address field: Destination address MUST be copied from the destination address field of the corresponding update message. - Transaction identifier: The Transaction identifier MUST be copied P„„kk÷nen et al. Expires September 2003 [Page 17] INTERNET-DRAFT MNP Delegation March 2003 from the corresponding update message. - The match field: Match field MUST be copied from the corresponding update message's MNP Data Options. - MNP Option and ICMPv6 code: MR MUST check that the MNP(s) in the update have before been delegated to the MR. Those MNP(s) which have been delegated before MUST be copied from the update message to MNP Data Option of the message. Those MNP(s) which cannot be updated, MUST have all zeros in the MNP field of the MNP Data Option. If one or more of the updated MNP(s) were updated successfully, ICMPv6 code of the message is set to 'MNP Update Ack'. If none of the MNP(s) could be updated successfully, the MNP Data Options MUST be copied from the update message to the response, and the ICMPv6 code MUST be set to 'MNP Unavailable' The MNP Delegation-Message message may not reach its destination and the same MNP Delegation-Message message might be retransmitted to the MR. In this case the retransmitted message MUST be handled similarly as previously received identical messages. 5.5 Examples In this section a transaction related to both MNP Query and MNP Delegation sequences are depicted. In the first case MR is at home and in the second case MR is at a foreign domain. Also a transaction related to MNP Updating sequence is presented as defined in chapter 5.4.5. 5.5.1 MNP Query sequence MR at home: _____________ ___________ ( ) / \ ( Internet )------|Home domain |---HA (_____________) \__________/ | MR In this example the MR is at home and proceeds with MNP Query with its HA. MR wants to be delegated an arbitrary MNP of length 48 and a certain MNP (4ffe:1:1:1/64). HA responds back to the MR by informing that a MNP of 48 can be delegated from the HA and 4ffe:1:1:1/64 MNP is not available for delegation. Message flows: MR HA -----------------------------------------------> P„„kk÷nen et al. Expires September 2003 [Page 18] INTERNET-DRAFT MNP Delegation March 2003 MNP Delegation-Message IP fields: [ Source address: MR's home address Destination address: HA address ] ICMP fields: [ Type: MNP Delegation-Message Code: MNP Delegator Query Transaction ID: 23456 Reserved: 0 MNP Option: [ Type=0x01 Option length=2*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 3600 Valid lifetime: 3600 Prefix length: 48 IPv6 Prefix: 0x0 Match: 1 ] MNP Data Option [ Preferred lifetime: 3600 Valid lifetime: 3600 Prefix length: 64 IPv6 Prefix: 4ffe:1:1:1 Match: 0 ] ] ] <----------------------------------------------- MNP Delegation-Message IP fields: [ Source address: HA's address Destination address: MR's home address ] ICMP fields: [ Type: MNP Delegation-Message P„„kk÷nen et al. Expires September 2003 [Page 19] INTERNET-DRAFT MNP Delegation March 2003 Code: MNP Delegator Transaction ID: 23456 Reserved: 0 MNP Option: [ Type=0x01 Option length=2*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 3600 Valid lifetime: 3600 Prefix length: 48 IPv6 Prefix: 3ffe:2222:2222::0 Match: 1 ] MNP Data Option [ Preferred lifetime: 0 Valid lifetime: 0 Prefix length: 64 IPv6 Prefix: 0::0 Match: 0 ] ] ] 5.5.2 MNP Delegation Sequence MR not at home: _____________ __________ ( ) / \ ( Internet )------|Home domain|---HA (_____________) \_________/ | ___|_______ | | | Foreign | | domain | \________/ | | MR In this example the MR is at a foreign domain and proceeds with MNP delegation with its HA. MR wants to be delegated a certain MNP of length 48. HA responds by delegating the MNP for the MR. Message flows: P„„kk÷nen et al. Expires September 2003 [Page 20] INTERNET-DRAFT MNP Delegation March 2003 MR HA -----------------------------------------------> MNP Delegation-Message IP fields: [ Source address: MR's COA Destination address: HA's address ] Home address destination option [ Home Address=MR's home address ] ICMP fields: [ Type: MNP Delegation-Message Code: MNP Request Transaction ID: 67890 Reserved: 0 MNP Option: [ Type=0x01 Option length=1*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 3600 Valid lifetime: 3600 Prefix length: 48 IPv6 Prefix: 3ffe:2222:2222::0 Match: 0 ] ] ] <----------------------------------------------- MNP Delegation-Message IP fields: [ Source address: HA's address Destination address: MR's COA ] Type 2 Routing Header [ Home Address=MR's Home Address P„„kk÷nen et al. Expires September 2003 [Page 21] INTERNET-DRAFT MNP Delegation March 2003 ] ICMP fields: [ Type: MNP Delegation-Message Code: MNP Delegated Transaction ID: 67890 Reserved: 0 MNP Option: [ Type=0x01 Option length=1*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 3600 Valid lifetime: 3600 Prefix length: 48 IPv6 Prefix: 3ffe:2222:2222::0 Match: 0 ] ] ] 5.5.3 MNP Updating sequence MR not at home: _____________ __________ ( ) / \ ( Internet )------|Home domain|---HA (_____________) \_________/ | ___|_______ | | | Foreign | | domain | \________/ | | MR In this example the MR is at a foreign domain and HA proceeds with updating the lifetimes of the previously delegated MNP to zero. After this sequence the updated MNP is no longer valid in the MR, and MR has to delegate a new MNP by running the MNP Query and MNP Delegation sequences. Message flows: HA MR P„„kk÷nen et al. Expires September 2003 [Page 22] INTERNET-DRAFT MNP Delegation March 2003 -----------------------------------------------> MNP Delegation Message: IP fields: [ Source address: HA address Destination address: MR's COA ] Type 2 Routing header [ Home Address=MR's home address ] ICMP fields: [ Type: MNP Delegation-Message Code: MNP Update Transaction ID: 948738 Reserved: 0 MNP Option: [ Type=0x01 Option length=1*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 0 Valid lifetime: 0 Prefix length: 48 IPv6 Prefix: 3ffe:2222:2222::0 Match: 0 ] ] ] HA MR <----------------------------------------------- MNP Delegation-Message IP fields: [ Source address: MR's COA Destination address: HA's address ] Home address destination option [ Home Address=MR's home address P„„kk÷nen et al. Expires September 2003 [Page 23] INTERNET-DRAFT MNP Delegation March 2003 ] ICMP fields: [ Type: MNP Delegation-Message Code: MNP Update-Ack Transaction ID: 948738 Reserved: 0 MNP Option: [ Type=0x01 Option length=1*sizeof(MNP Data Option) MNP Data Option [ Preferred lifetime: 0 Valid lifetime: 0 Prefix length: 48 IPv6 Prefix: 3ffe:2222:2222::0 Match: 0 ] ] ] 6. Constants MNP_REQUEST_DELAY=500 MNP_REQUEST_MAX_RETRIES=3 7. Security issues Security issues of this MIPv6 extension are not considered in the draft. These issues must be considered in the next version of the draft. Acknowledgements The author would like to thank the following persons on the NEMO mailing list for feedback in an alphabetical order: Erik Nordmark Alexandru Petrescu Mattias Pettersson References [1] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels" BCP 14, RFC 2119, Internet Engineering Task Force, March 1997. [2] D. B. Johnson, C. E. Perkins, J. Arkko "Mobility Support in IPv6" (draft-ietf-mobile-ipv6-21), Internet Draft, Internet Engineering Task Force, Feb 2003. P„„kk÷nen et al. Expires September 2003 [Page 24] INTERNET-DRAFT MNP Delegation March 2003 [3] T. Ernst, H. Lach "Network Mobility Support Terminology" (draft- ernst-nemo-terminology-01), Internet Draft, Internet Engineering Task Force, Nov 2002. [4] NEtwork MObility working group website URL: http://www.nal.motlabs. com/nemo. [5] M. Crawford "Router Renumbering for IPv6" RFC 2894, Internet Engineering Task Force, Aug 2000. [6] T. J. Kniveton, J. T. Malinen, V. Devarapalli, C. E. Perkins "Mobile Router Tunneling Protocol" (draft-kniveton-mobrtr-03) Internet Draft, Internet Engineering Task Force, Nov 2002. [7] B. Haberman, J. Martin "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)" (draft-haberman-ipngwg-auto-prefix-02), Internet Draft, Internet Engineering Task Force, Feb 2002. [8] O. Troan, R. Droms "IPv6 Prefix Options for DHCPv6" (draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03), Internet Draft, Internet Engineering Task Force, March, 2003. [9] A. Conta, S. Deering "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, Internet Engineering Task Force, Dec 1998. [10] S. Deering, R. Hinden "Internet Protocol, Version 6 (IPv6) Specification" RFC 2460, Dec 1998. [11] Wakikawa R. K. Uehara, K. Mitsuya, T. Ernst "Basic Metwork Mobility Support" (draft-wakikawa-nemo-basic-00), Internet Draft, Internet Engineering Task Force, Feb, 2003. Authors' addresses Pekka P„„kk÷nen VTT Electronics Kaitov„yl„ 1 90571 Oulu Finland email: pekka.paakkonen@vtt.fi Juhani Latvakoski VTT Electronics Kaitov„yl„ 1 90571 Oulu Finland email: juhani.latvakoski@vtt.fi P„„kk÷nen et al. Expires September 2003 [Page 25] INTERNET-DRAFT MNP Delegation March 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.