idnits 2.17.1 draft-paakkonen-nemo-prefix-delegation-00.txt: -(1): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 0) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7705 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-mobile-ipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03 ** Obsolete normative reference: RFC 2463 (ref. '9') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) -- Possible downref: Normative reference to a draft: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Pekka P��kk�nen 2 Document:draft-paakkonen-nemo-prefix-delegation-00.txt Juhani Latvakoski 3 Expires: September 2003 5 March 2003 7 Mobile Network Prefix Delegation extension for Mobile IPv6 8 draft-paakkonen-nemo-prefix-delegation-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This draft proposes a dynamic Mobile Network Prefix (MNP) delegation 38 extension for Mobile IPv6 protocol to enable MNP delegation for 39 mobile networks. A MNP is an IPv6 prefix used in a mobile network. 40 The extension supports dynamic delegation, return, refreshing and 41 updating operations related to MNP delegation operations between a 42 Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). 43 This extension is proposed, because there is a lack for a dynamic MNP 44 delegation protocol related to mobile networks, and currently MNPs have 45 to be assigned statically to enable mobile networking. 47 Table of contents 49 Abstract i 51 1. Introduction i 53 2. Terms 1 55 3. Terminology 1 57 4. Overview 1 58 4.1. MIPv6 extension overview..................................... 2 60 5. Protocol .......................................................... 3 61 5.1. Operational environment ..................................... 3 62 5.2. Messages .................................................... 3 63 5.2.1 MNP Delegation Message ................................. 4 64 5.3. Options ..................................................... 6 65 5.3.1. MNP Option ............................................ 6 66 5.3.2. MNP Data Option ....................................... 7 67 5.4. Operation ................................................... 8 68 5.4.1. MNP Query sequence .................................... 8 69 5.4.2. MNP Delegation sequence .............................. 11 70 5.4.3. MNP Refresh sequence ................................. 12 71 5.4.4. MNP Return sequence .................................. 13 72 5.4.5. MNP Update sequence .................................. 15 73 5.5. Examples ................................................... 17 74 5.5.1. MNP Query sequence ................................... 17 75 5.5.2. MNP Delegation sequence .............................. 19 76 5.5.3. MNP Update sequence .................................. 21 78 6. Constants 23 80 7. Security issues 23 82 Acknowledgements 23 84 References 23 86 Author's addresses 24 88 Full Copyright Statement 25 90 1. Introduction 92 This document describes how one or more Mobile Network Prefixes (MNP) 93 can be delegated to a mobile network with extensions to Mobile IPv6 [2] 94 protocol. MNP is an IPv6 prefix used in a mobile network. By using the 95 extensions proposed in this document it is possible to dynamically 96 delegate MNPs for a mobile network. MNP Delegation is executed between a 97 Mobile Router (MR) of a mobile network and its Home Agent (HA). MR 98 acquires, refreshes and returns MNPs from its HA according to its needs. 99 HA controls the delegation of MNPs to MRs. HA can also inform about new 100 valid and preferred lifetimes regarding the delegated MNPs. The 101 extension described in this document is needed, because there is no 102 mechanism for dynamic delegation of MNPs to mobile networks, but instead 103 MNPs have to be assigned statically to mobile networks. 105 2. Terms 107 The terminology used in this document is defined in an other Internet 108 draft [3]. In addition to this, some new terms are defined. 110 MNP Requestor = MR which delegates MNPs from its HAs. 112 MNP Delegator = HA which delegates MNPs to a MR. 114 MNP Delegation = The delegation of a MNP from a HA to a MR. 116 MNP Refreshing = MNP delegation lease extension initiated by the MR. 118 MNP Returning = Returning of a MNP from MR to its HA after the initial 119 MNP delegation of the MNP. This operation is executed when the MR no 120 longer needs the delegated MNP, and returns it back to the HA which 121 originally delegated the MNP. 123 MNP Updating = The delegated MNP might change for example because 124 of renumbering operations at the HA. This function is used to inform 125 MR of valid and preferred lifetime changes regarding the leased MNP. 127 Transaction identifier = An identifier used to match a request message 128 to a response. This kind of message exchange forms a transaction between 129 communicating parties. 131 3. Terminology 133 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 4. Overview 139 The environment for this solution is defined in the NEMO working 140 group (WG) [4]. The NEMO WG is developing a solution for a mobile 141 network, which is based on one or more MRs connecting a mobile network 142 to the Internet. The basic approach is to use Mobile IPv6 and 143 bidirectional tunneling between the MR and its HA to enable transparent 144 session mobility for the Mobile Nodes (MN) of the mobile network. The 145 MNP is an IPv6 prefix of arbitrary length, which identifies an entire 146 mobile network within the Internet topology [3]. This document focuses 147 on the dynamic MNP delegation for a NEMO-network. Dynamic MNP assignment 148 for a NEMO-network using MIPv6 is desirable for the following reasons: 150 1. Static MNP assignment for a mobile network is laborious 152 - If a MNP will be statically allocated for each mobile network, it 153 demands a great deal of management and configuration work related to 154 MNPs. There might be millions of mobile networks in the future and 155 manual allocation of a MNP for each mobile network is laborious. 157 2. A mobile network may need a MNP in an ad-hoc way 159 - MNP allocation might be managed using Router Renumbering for IPv6 [5]. 160 But the mobile network could be formed in an ad-hoc way in which case 161 the MR initially does not have a MNP and requests for it dynamically. In 162 this case [5] is insufficient and a dynamic protocol for MNP delegation 163 is needed. This requirement assumes that there is a need for dynamic 164 mobile network formation. 166 3. Lifetime of the mobile network is not necessarily infinite 168 - Use cases of such situations are expected to occur in Personal Area 169 Networks (PAN), which require mobile networking capabilities only for a 170 short time. Addressing resources are wasted, if the delegated MNP of 171 the mobile network is not used. The MNP should be possible to be 172 returned dynamically to the MNP delegator, after it is no longer used. 174 4. HA of the MR needs to know the MNP used in the mobile network 176 - According to the solution defined in [6], HA needs to know the MNP 177 used in the mobile network in the "static" MR scenario, in which a 178 routing table entry must exist in the HA of the MR. [11] defines a 179 solution for mobile networks, which requires a binding cache entry in 180 the HA, binding the MNP used on the ingress interface of the mobile 181 network to the COA used on the egress interface. Because information of 182 the MNP used in the mobile network is needed in MR's HA, it is suggested 183 that dynamic MNP delegation operations are executed between the MR and 184 its HA. Because in that case MNP delegation messages are needed between 185 the MR and its HA, it is suggested that dynamic MNP delegation 186 functionalities are implemented as a MIPv6 extension. 188 4.1 MIPv6 extension overview 190 The defined extension borrows from the Automatic IPv6 Prefix Delegation 191 Protocol [7] and from IPv6 Prefix Options for DHCPv6 [8] drafts. Some 192 of the features in those documents are embedded to the MIPv6 extension 193 protocol defined in this document. MR of a mobile network acts as a MNP 194 requestor and HA as a MNP delegator. One new ICMPv6 message and new 195 options inside of it (MNP Delegation-Message) are defined to be used in 196 the extension. New ICMPv6 codes for MNP delegation related signalling 197 are also defined. This means that the MR can dynamically request, 198 return and refresh a MNP from its HA. Also MNP lifetime updates from 199 the HA to the MR are supported. HA allocates the MNP(s) to the MR for a 200 certain period of time. The MNP can be delegated to the MR either 201 temporarily or permanently. In figure 1 an example can be seen of the 202 extension's usage. In the example MR is at a foreign domain and MR 203 acquires a MNP and sends a MNP Delegation-Message to its HA. HA 204 allocates a MNP for the MR and sends back a MNP Delegation response and 205 the delegated MNP. MR receives the MNP and starts advertising it on its 206 local links using Router Advertisements. MR can delegate MNPs also when 207 it is at home. More examples of the protocol usage have been 208 demonstrated in chapter 5.5. 210 _________ 211 (Internet )------------Home network--HA 212 (_______) / 213 | 2. code: 'MNP Delegated' / /\ 1. code: 'MNP Request' 214 | / / 215 Foreign network / / 216 | \/ / 217 ( MR )-----------------------/ 218 ( | ) 219 ( | ) 3. Router Advertisement (MNP) 220 ( | ) 221 ( MN ) 222 ---- 224 Figure 1. MNP delegation for a MR in a foreign network. 226 5. Protocol 228 In this chapter the MIPv6 protocol extension for dynamic MNP 229 delegation is defined. 231 5.1 Operational environment 233 There are two entities participating in the protocol as can be seen in 234 figure 2. MNP delegator is MR's home agent, which can delegate MNP(s) 235 for the MR. MR is a MNP requestor, and requests MNP(s) from its HA. MR 236 can have multiple HAs i.e. MNP delegators. 238 __________ 239 ( Internet )------Home network--HA 240 (________) (MNP delegator) 241 | 242 | 243 | 244 MR 245 (MNP requestor) 247 Figure 2. Protocol entities. 249 5.2 Messages 251 There is one new ICMPv6 message defined for the MIPv6 protocol. MNP 252 Delegation-Message is used by the MR to query and request HA for MNP(s), 253 return MNP(s) and refresh the lease of MNP(s). MNP Delegation-Message 254 can also be used by HA to signal MR of updating operations regarding 255 the leased MNP(s). The same message type is used as a response to these 256 operations. Different type of operations and responses are distinquished 257 by the different ICMPv6 code types. 259 5.2.1 MNP Delegation-Message 261 MNP Delegation-Message is used by MR to query, request, refresh and 262 return MNP(s). It is also used by the HA to inform MR of updating 263 operations. 265 Message format: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Code | Checksum | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Transaction Identifier | Reserved | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 | Message Body | 277 IP fields 279 Source Address 281 Source IPv6 address of MR or its HA 283 Destination Address 285 Destination address of MR or its HA. 287 Hop Limit 289 Set to an initial hop limit value, similarly to any other unicast 290 packet sent by a mobile node. 292 Routing Header: 294 A routing header of type 2 MUST be added to the message if HA is 295 sending a MNP Delegation-Message to the MR and MR is not at home i.e 296 has a binding in the HA's binding cache. Otherwise a routing header 297 of type 2 MUST not be used. 299 AH or ESP header: 301 IP security is not discussed in this version of the draft. 303 ICMP fields: 305 Type: 307 xxx for MNP Delegation-Message 309 Code: 311 MNP Delegator Query (0) 313 The MNP Delegator Query message is used by the MR to query MNP 314 delegators (HAs) and their abilities to delegate MNP(s). This 315 message is sent to MR's HA during the MNP Query sequence. 317 MNP Request (1) 319 The MNP Request message is used by the MR to request for MNP(s) 320 from its HA(s). This message is sent during the MNP Delegation 321 sequence. 323 MNP Refresh (2) 325 The MNP Refresh message is used by the MR to request a refresh 326 on the lifetimes of delegated MNP(s). This message is sent during 327 the MNP Refresh sequence. 329 MNP Return (3) 331 The MNP Return message is used by the MR to return delegated 332 MNP(s) to its HA. This message is sent during the MNP Return 333 sequence. 335 MNP Delegator (4) 337 A MNP Delegator message is sent by the HA during MNP Query 338 sequence. It is used to inform MR of MNP(s) HA is capable of 339 delegating. 341 MNP Delegated (5) 343 A MNP Delegated message is used by HA during MNP Delegation and 344 MNP Refresh sequence. It is used to inform MR of delegated and 345 refreshed MNP(s). 347 MNP Returned (6) 349 A MNP Returned message is sent by HA during MNP Return sequence. 350 It is used to inform MR of returned MNP(s). 352 MNP Unavailable (7) 354 A MNP Unavailable message is used in all the sequences to inform 355 of non-valid MNP(s) operations. 357 MNP Update (8) 359 A MNP Update message is used by HA to inform MR of lifetime 360 changes concerning the delegated MNP(s). 362 MNP Update-Ack (9) 363 A MNP Update-Ack is used by MR to responde to MNP Update 364 messages sent by its HA. 366 Checksum 368 The ICMP Checksum as defined in [9]. 370 Transaction identifier 372 An unique identifier used to match a MNP Delegation-Message 373 request to a corresponding MNP Delegation-Message response. 375 Reserved 377 This field is unused. It MUST be initialized to zero by the sender 378 and MUST be ignored by the receiver. 380 Options: 382 Destination Option: 384 A Home Address destination option MUST be included if MR sends a 385 MNP Delegation-Message and is away from home. 387 MNP Option: 389 MUST contain one MNP Option. The MNP requestor and MNP Delegator 390 can describe the MNP(s) by adding a MNP Option to the MNP 391 Delegation-Message. 393 5.3 Options 395 In this chapter the new options, which are used in the new ICMP 396 message, are defined. 398 5.3.1 MNP Option 400 This option is used in MNP Delegation-Message. It is used to contain 401 MNP information in one or more MNP Data Options. 403 Option format: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type | Option length | Option body 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 412 Type: 414 0x01 416 Option length: 418 Length of option body. 420 Option body: 422 Message body can contain up to x MNP Data Options. However it 423 is recommended that the IPv6 packet size is smaller the MTU for 424 IPv6 (1280 octets) [10] which limits the number of MNP Data 425 Options used in a MNP Option. 427 5.3.2 MNP Data Option 429 MNP Data Option holds MNP information related to a single MNP. 431 Option format: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Preferred lifetime | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | Valid lifetime | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | Prefix length | IPv6 prefix (16 octets) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 442 | | 443 | | 444 | | 445 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | Match | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Type: 451 0x02 453 Preferred lifetime: 455 The recommended lifetime for the MNP in the option expressed in 456 seconds. A value of 0xffffffff represents infinity. 458 Valid lifetime: 460 The valid lifetime for the MNP in the option expressed in 461 seconds. A value of 0xffffffff represents infinity. 463 Prefix length: 465 Length for this MNP in bits. 467 IPv6 prefix: 469 A MNP. 471 Match: 473 This field is used to indicate MNP preference of the MR during MNP 474 Query and MNP Delegation sequences. 476 Defined values: 478 0, indicates that MNP query/delegation is based on both MNP and its 479 length indicated by the values in Prefix length and IPv6 prefix 480 fields in the MNP Data Option. 482 1, indicates that MNP query/delegation is based only on MNP length 483 indicated by the value in Prefix length field in the MNP Data 484 Option. 486 5.4 Operation 488 In this chapter operation of the protocol is described. 490 5.4.1 MNP Query sequence 492 The MNP Query sequence consists of a transaction between the MR and 493 its HA. A transaction consists of a MNP Delegation-Message and MNP 494 Delegation-Message response exchange with the same transaction 495 identifiers. The sequence is initiated by the MR to query its HA's 496 capabilities to delegate MNP(s) to the MR. This sequence can be 497 performed multiple times with one or more HAs. After the MR has queried 498 the capabilities of its HAs with this sequence, MR should advance to 499 MNP Delegation sequence with the chosen HA to proceed with MNP 500 delegation. 502 MR functionality: 504 The MR might initially know the addresses of one or more of its HAs. 505 If the MR is at home, it learns the HA's address by receiving Router 506 Advertisements from its HA. If MR is away from home and does not know 507 any HA addresses, it SHOULD initiate Dynamic Home Agent Discovery as 508 defined in section 11.4.1 of [2]. After MR knows the addresses of one 509 or more HAs, the MNP Query sequence can be executed. 511 The MNP Query sequence consists of a transaction between the MR and 512 its HA. Transactions are initiated by the MR to query the capabilities 513 of MR's HA to delegate MNPs. A transaction consists of a MNP 514 Delegation-Message sent by the MR to its HA and a MNP Delegation-Message 515 response sent back to the MR by the HA. MR initiates the transaction by 516 sending a MNP Delegation-Message with code 'MNP Delegator Query' to one 517 of its HAs. The MNP Delegation-Message is constructed by the MR always 518 independently of its ICMPv6 code as follows: 520 - IP source address field: The source address SHOULD be set to its 521 current Care-Of-Address if MR is away from home. If MR is at home, 522 its home address MUST be used. 523 - IP destination address field: Destination address MUST be set to HA 524 address. If MR is away from home, the HA to which MR has a binding 525 update list entry MUST be used. Otherwise the stored HA address 526 SHOULD be used. 527 - Home address destination option: MR's home address MUST be included 528 in a Home Address destination option, if MR is not at home. 529 - Transaction identifier: The Transaction identifier SHOULD be chosen 530 randomly to identify this transaction uniquely. 531 - MNP Option: A MNP Option MUST be set in the message to describe the 532 MNP(s) MR is interested in. One MNP Data Option inside the MNP 533 Option describes one MNP for delegation. The valid and preferred 534 lifetimes MAY be set to indicate MR's preference for MNP(s). Match 535 field MUST be set as described in section 5.3.2. 536 - Binding update list: If MR is away from home it MUST have a binding 537 entry in the binding cache at its HA, with which it is 538 communicating. This means that the HA's address MUST be present in 539 the binding update list of the MR. 541 In this case the code of the MNP Delegation-Message MUST be set to 542 'MNP Delegator Query'. If the MR doesn't receive a MNP 543 Delegation-Message response back within MNP_REQUEST_DELAY milliseconds, 544 the previously sent MNP Delegation-Message SHOULD be sent up to 545 MNP_REQUEST_MAX_RETRIES times to the same HA. When MR receives a MNP 546 Delegation-Message within MNP_REQUEST_DELAY milliseconds, it SHOULD 547 check it as follows independently of its ICMPv6 code: 549 - ICMPv6 type: Check that the ICMPv6 type of the received message is 550 MNP Delegation-Message. 551 - IP destination address field: If MR is at home, check that the 552 destination address in the IP header field is MR's home address. If 553 MR is not at home, check that the destination address is MR's COA. 554 - IP source address field: Check that the IP source address field of 555 the message is the same as the destination address in the 556 corresponding MNP Delegation-Message with the same transaction 557 identifier. 558 - Routing header type 2: If MR is not at home, the packet MUST have a 559 type 2 routing header with MR's home address and destination 560 IP header field has MR's COA. 561 - MNP Option: Check that a MNP Option with one or more MNP Data 562 Options is present in the message. 564 If these conditions are not met, MR MUST silently ignore the message. If 565 the code of the MNP Delegation-Message response is 'MNP Delegator', MR 566 knows that the HA is capable of delegating the MNP(s) in the MNP Option. 567 If the MNP in the received MNP Data Option is all zeros, HA is not 568 capable of delegating the wanted MNP. If MR queried for x pieces of 569 MNPs, the information of the MNP queries are in the corresponding places 570 in the reply. For example the second queried MNP information is in the 571 second MNP Data Option of the received MNP Option. If the code is 572 'MNP Unavailable', MR knows that the HA is not capable of delegating any 573 of the MNPs the MR queried. The queried MNPs are present in the MNP 574 Option of the reply. If MR does not receive any response after 575 MNP_REQUEST_MAX_RETRIES attempts, the MR MAY start the MNP Query 576 sequence again or conclude that its HA is not capable of delegating 577 MNPs. 579 After the MNP Query sequence MR can decide to proceed to MNP 580 Delegation sequence based on the received MNP information in the MNP 581 Option or it can continue with a new MNP Query sequence. MR might 582 continue MNP Query sequence with its HA, because MR might not be 583 satisfied with the capabilities of the HA to delegate MNPs. In that case 584 MR MAY change the MNP descriptions in the MNP Option of the new MNP 585 Delegation sequence. 587 HA functionality: 589 After the HA receives a MNP Delegation-Message from a MR, HA has to 590 check it as follows independently of the code of the message: 592 - ICMPv6 type: The type of the ICMPv6 message MUST be 593 MNP_DELEGATION_MESSAGE. 594 - IP source address field: If the received message has a Home Address 595 destination option, the COA in binding cache of the home address 596 MUST be equal to the IP source address. 597 - IP destination address field: The destination address MUST be the 598 HA's IP address. 599 - MNP Option: Check that the MNP Delegation-Message has a MNP Option 600 with one or more MNP Data Options. 602 If these checks are not valid, HA MUST silently ignore the message. 604 In this case the ICMPv6 code of the received message MUST be 'MNP 605 Delegator Query'. HA can now inform the MR about the MNP(s) it is 606 capable of delegating. It SHOULD make the choice based on the 607 received information in the MNP Option. Each MNP Data Option SHOULD be 608 considered as one MNP information query. If the match field is set to 609 zero in the MNP Data Option, the MNP is wanted to be queried based on 610 MNP and its length. If the match field is set to one, MNP is wanted to 611 be queried only based on MNP length. HA SHOULD follow these 612 preferencies in the sequence, but can inform MNPs based on it own 613 criteria. If a MNP is not wanted to be informed to the MR based on a 614 MNP information query, all zeros MUST be set to the MNP field in the 615 MNP Data Option. If the HA is not capable of delegating any MNP(s) 616 queried for in the request, a MNP Delegation-Message with code 617 'MNP Unavailable' MUST be sent to the MR. In this case the MNP Data 618 Options MUST be copied from the request message. Otherwise MNP 619 information of the MNP(s), which HA is capable of delegating MUST be 620 attached to the MNP Option of a MNP Delegation-Message. The MNP Data 621 Options in the response MUST follow the order of the information queries 622 in the request. This means that nth MNP Data Option to nth MNP query 623 MUST be in the nth position in the MNP Option. A MNP Delegation-Message 624 SHOULD be constructed and sent as follows independently of its code: 626 - IP source address field: HA's global IP address is set as source 627 address in the IP header source address field. 628 - IP destination address field: The corresponding MNP 629 Delegation-Message's source address is set as destination address in 630 the IP header destination address field. 631 - Transaction identifier: Copy the Transaction identifier from the MNP 632 Delegation-Message to the response's transaction identifier field. 633 - Routing header type 2: A type 2 routing header MUST be included with 634 the MR's home address if the received MNP Delegation-Message had a 635 Home Address destination option. The home address is received from 636 the Home Address destination option of the corresponding MNP 637 Delegation-Message. 638 - The match field: The match field MUST copied from the request 639 message from the corresponding MNP Data Options. 641 In this case the code 'MNP Delegator' is set as the type of the MNP 642 Delegation-Message. HA might receive multiple identical MNP 643 Delegation-Message messages, because of retransmissions at the MR. The 644 HA SHOULD handle and answer to these messages identically to those 645 received before. 647 5.4.2 MNP Delegation sequence 649 The MNP Delegation sequence can be initiated by the MR after the MNP 650 Query sequence or without it. It is used by the MR to delegate MNP(s) 651 from its HA(s). After successfully executing the sequence, one or more 652 MNP(s) have been delegated for the MR. 654 MR functionality: 656 The MNP Delegation sequence begins when MR sends a MNP 657 Delegation-Message with an ICMPv6 code of 'MNP Request' to its HA. MR 658 can select the HA for MNP delegation based on the MNP Query sequence. 659 The MNP Delegation-Message is constructed and sent as described in the 660 MNP Query sequence (chapter 5.4.1). The ICMPv6 code of the message is 661 now 'MNP Request'. 663 If the MR receives a MNP Delegation-Message it has to check it as 664 described in chapter 5.4.1 for MR functionality. If the checks are 665 valid, MR SHOULD proceed as follows: 667 - If the code of the response is set to 'MNP Delegated', MR can 668 consider one or more MNP(s) delegated. Those MNP Data Options which have 669 all zeros in the MNP field, could not be delegated. The preferred and 670 valid lifetimes in the MNP Data Options indicate the lifetimes for the 671 delegated MNP(s). MR SHOULD store delegated MNP(s) with MNP length, HA's 672 address and lifetimes (MNP <-> MNP length <-> HA's address <-> valid 673 lifetime left <-> preferred lifetime left <->). This helps when 674 returning or refreshing the delegated MNP. 676 - If the code is set to MNP Unavailable, none of the wanted MNP(s) 677 were available for delegation. In this case MR MAY proceed MNP 678 Delegation/Query sequence with different MNP preferences. 680 If the MR doesn't receive a MNP Delegation-Message response back 681 within MNP_REQUEST_DELAY milliseconds, the previously sent MNP 682 Delegation-Message MAY be sent up to MNP_REQUEST_MAX_RETRIES times to 683 the same HA. If the MR does not receive a response to its request after 684 sending MNP_REQUEST_MAX_RETRIES requests, MR can conclude that the HA 685 in question is not capable of delegating the wanted MNPs. 687 HA functionality: 689 If HA receives a MNP Delegation-Message with code 'MNP Request' it 690 MUST check the request as described in chapter 5.4.1 for HA 691 functionality. If the checks are valid, HA can proceed as follows: 693 - If the wanted MNP(s) are available for delegation, HA constructs and 694 sends a MNP Delegation-Message as described in chapter 5.4.1 for HA 695 functionality except the ICMPv6 code is set to 'MNP Delegated'. A MNP 696 Option is added to the message based on the MNP(s) to be delegated. The 697 MNP Delegation occurs similarly as in the MNP Query sequence, but in 698 this case the MNP(s) are actually delegated instead of just informing 699 information about available MNPs. The HA SHOULD store the delegated 700 MNP(s) with the home address of the MR, MNP length and lifetimes (MNP 701 <-> MNP length <-> MR's home address <-> valid lifetime left <-> 702 preferred lifetime left). This will later be helpful when refreshing or 703 returning related to the delegated MNP(s) occur. 705 - If the MR cannot delegate any MNP(s) for the MR, it MUST send a MNP 706 Delegation-Message back to the MR with a code 'MNP Unavailable' as 707 described in chapter 5.4.1 for HA functionality. The MNP Option MUST 708 be copied from the corresponding request. 710 The MNP Delegation-Message may not reach its destination and the same 711 message might be retransmitted to the HA. In this case the retransmitted 712 message MUST be handled similarly as previously received identical 713 messages. 715 5.4.3 MNP Refresh sequence 717 MNP Refresh sequence is initiated by the MR to refresh the lifetimes 718 of leased MNP(s) with finite lifetimes. 720 MR functionality: 722 When the valid or preferred lifetime of a delegated MNP diminishes 723 under a certain threshold, its lease SHOULD be renewed with the MNP 724 Refresh sequence. The recommended time for MNP refreshing is not 725 specified here. MR sets the MNP(s) to be refreshed in a MNP Option and 726 sends a MNP Delegation-Message to the HA from which the MNP(s) were 727 delegated from. The HA's address corresponding to the leased MNP should 728 have been previously stored with the delegated MNP, from which it can 729 be received for refreshing. The wanted lifetimes for the new MNP 730 delegation can be set according to the MR's preference. The MNP Refresh 731 sequence begins when the MNP Delegation-Message message is constructed 732 and sent as described in chapter 5.4.1 for MR functionality. The ICMPv6 733 code of the message is now 'MNP Refresh'. 735 If the MR receives a MNP Delegation-Message it has to check it as 736 described in chapter 5.4.1 and in addition to that proceed as follows: 738 - If the code of the response is set to 'MNP Delegated', it can 739 consider the MNP(s) refreshed. The preferred and valid lifetimes in the 740 MNP Data Options indicate the lifetimes for the delegated MNP(s). If a 741 MNP Data Option contains all zeros in the MNP field, the corresponding 742 MNP can be considered as not refreshed. 744 - If the code is set to MNP Unavailable, none of the MNP(s) could be 745 refreshed. In this case the old lifetimes stay valid for the MNP(s). 747 If the MR doesn't receive a MNP Delegation-Message back within 748 MNP_REQUEST_DELAY milliseconds, the previously sent MNP 749 Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to 750 the same HA. If the MR does not receive a response to its request after 751 sending MNP_REQUEST_MAX_RETRIES requests, it might be because the 752 corresponding HA is down for some reason. In this case the MR MAY return 753 to MNP Refresh sequence after some unspecified amount of time. 755 HA functionality: 757 If HA receives a MNP Delegation-Message with code 'MNP Refresh' it 758 MUST check the request as described in chapter 5.4.1 for HA 759 functionality. If the checks are valid, HA can proceed as follows: 761 - If the HA is able to refresh lifetimes of one or more MNPs, HA 762 constructs and sends a MNP Delegation-Message as described in chapter 763 5.4.1 for HA functionality, except the ICMPv6 code is set to 764 'MNP Delegated'. The lifetimes of the refreshed MNP(s) MAY be chosen by 765 the delegating HA independently of the requested lifetimes in the MNP. 766 The requested lifetimes SHOULD however be used as guidance when 767 refreshing the MNP(s). All the MNP(s) which can be refreshed by the HA, 768 MUST be included in a MNP Option, which is sent back to the requesting 769 MR in a MNP Delegation-Message. If a MNP cannot be refreshed, all zeros 770 MUST be set to the MNP field in the MNP Data Option. 772 - If the MR cannot refresh any MNP(s), it MUST send a MNP 773 Delegation-Message back to the MR with a code 'MNP Unavailable'. The 774 MNP Option MUST be copied from the corresponding request. 776 The MNP Delegation-Message message may not reach its destination and 777 the same message might be retransmitted to the HA. In this case the 778 retransmitted message MUST be handled similarly as previously received 779 messages. 781 5.4.4 MNP Return sequence 782 MNP Return sequence is initiated by the MR when the MR no longer needs 783 the previously delegated MNP(s). 785 MR functionality: 787 When MR no longer needs the leased MNP(s) for some reason, it SHOULD 788 return them to the HA, which delegated the MNP(s). This is executed with 789 the MNP Return sequence. The information related to the MNP(s) to be 790 returned MUST be included inside a MNP Option, which is placed inside 791 the MNP Delegation-Message. The MNP Return sequence begins when the MNP 792 Delegation-Message is constructed and sent as described in chapter 5.4.1 793 for MR functionality. The ICMPv6 code of the message is now set to 794 'MNP Return'. HA's address should have been stored during MNP 795 Delegation, and is used now as a destination address. 797 If the MR receives a MNP Delegation-Message it has to check it as 798 described in chapter 5.4.1 for MR functionality and if the checks are 799 valid, proceed as follows: 801 - If the ICMPv6 code of the response is set to 'MNP Returned', MR can 802 consider those MNP(s) returned, which have zero lifetimes in the MNP 803 Option. If a MNP Data Option contains all zeros in the MNP field, 804 the corresponding MNP can be considered as not returned. 806 - If the ICMPv6 code is set to MNP Unavailable, none of the MNP(s) in 807 the MNP Option were returned. In this case the old lifetimes stay 808 valid for the MNPs. 810 If the MR doesn't receive a MNP Delegation-Message back within 811 MNP_REQUEST_DELAY milliseconds, the previously sent MNP 812 Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to 813 the same HA. If the MR does not receive a response to its request after 814 sending MNP_REQUEST_MAX_RETRIES requests, it might be because the 815 corresponding HA is down for some reason. In this case the MR MAY return 816 to MNP Return sequence after some unspecified amount of time. 818 HA functionality: 820 If HA receives a MNP Request with ICMPv6 code 'MNP Return', it MUST 821 check the request as described in section 5.4.1 for HA functionality. 822 If the checks are valid, the HA can proceed as follows: 824 - HA has to determine if the returned MNP(s) have been delegated by the 825 HA to the requesting MR. The MNP(s) which have not been delegated by 826 the HA, MUST have all zeros in the MNP field in the MNP Data Option. 827 The MNP(s) which have been delegated by the HA and can be returned, 828 MUST be included in the MNP Data Options of the response. The 829 lifetimes of those MNP(s) MUST be set to zero to indicate that 830 they are not valid anymore. HA constructs a MNP Delegation-Message as 831 described in chapter 5.4.1 for HA functionality except the ICMPv6 code 832 is set to 'MNP Returned'. 834 - If none of the MNP(s) belong to the HA, a MNP Delegation-Message with 835 the ICMPv6 code of 'MNP Unavailable' has to be returned to the 836 requestor as described in chapter 5.4.1 for HA functionality. The MNP 837 Option MUST be copied from the corresponding request. 839 The MNP Delegation-Message message may not reach its destination and 840 the same message might be retransmitted to the HA. In this case the 841 retransmitted message MUST be handled similarly as previously received 842 identical messages. 844 5.4.5 MNP Update sequence 846 MNP Update sequence is initiated by the HA when the valid or preferred 847 lifetimes of a delegated MNP are changed by the HA. With this sequence 848 those lifetime changes are informed to the MR, which originally 849 delegated the MNP. The MR might detect that the lifetimes of a delegated 850 MNP have been changed to zero by its HA. This means that the MNP cannot 851 be used anymore, and a new MNP should be delegated from the HA with the 852 MNP Query/Delegation sequences. 854 HA functionality: 856 When valid or preferred lifetimes on one or more delegated MNPs are 857 changed by the MR, that information is informed to the MR by sending a 858 MNP Delegation-Message with ICMPv6 code 'MNP Update' to the MR as 859 described in chapter 5.4.1 for HA functionality with the following 860 changes to all message handling except IP source address field: 862 - MNP Option: When updating MNP(s), a MNP Option MUST be added to the 863 message to indicate the MNP(s) updating operation is concerned with. 864 The new valid and preferred lifetimes are set to the MNP Data 865 Options. 866 - IP destination address field: The destination address in the IP 867 header MUST be set to the MR's Home Address if that Home Address has 868 no entry in the binding cache. This means that the MR is at home. 869 MR's home address should have been saved during the MNP Delegation 870 sequence with the MNP. Otherwise the COA from the binding cache MUST 871 be used. 872 - Transaction identifier: A new random transaction identifier MUST be 873 used in the transaction identifier field. 874 - Routing header type 2: A type 2 routing header MUST be included with 875 the MR's home address, if the MR's home address has a binding cache 876 entry. 877 - The match field: The match field MUST set to zero in all MNP Data 878 Options to indicate a match based on both MNP and its length. 880 If HA doesn't receive a MNP Delegation-Message message within 881 MNP_REQUEST_DELAY milliseconds, HA SHOULD retransmit the same message. 882 If no response is received after MNP_REQUEST_MAX_RETRIES 883 retransmissions, HA MAY proceed with its own preference. If the MR 884 doesn't respond for any reason, HA MAY initiate MNP Updating sequence 885 again after some time or it might stop sending messages to the MR. 886 However, the HA can only be sure that MR has received the updating MNP 887 Delegation-Message, when HA receives a MNP Delegation-Message with 888 ICMPv6 code of 'MNP Update Ack'. 890 When HA receives a MNP Delegation-Message with code 'MNP Update-Ack' 891 it SHOULD check it as described in chapter 5.4.1 for HA functionality 892 with the following additional check: 894 - IP source address field: Check that the IP source address field of 895 the message is the same as the destination address in the 896 corresponding MNP Delegation-Message request with the same 897 transaction identifier. 899 If the checks are valid, it SHOULD proceed as follows: 901 - The MNP(s) in the MNP Data Options of the MNP Option indicate the 902 MNP(s), which MR has updated. The HA SHOULD now update the 903 lifetimes on its local storage. If a MNP Data Option contains all 904 zeros in the MNP field, the corresponding MNP can be considered as 905 not updated. 907 - If the code is set to MNP Unavailable, none of the MNP(s) in the MNP 908 Option were updated. In this case the old lifetimes stay valid for 909 the MNPs. 911 MR functionality: 913 When MR receives a MNP Delegation-Message with ICMPv6 code 914 'MNP Update', it MUST perform checks on all items except IP source 915 address field as described in chapter 5.4.1 for MR functionality with 916 the following additional checks: 918 - IP source address field: Check that the IP source address field of 919 the message is the HA's address from which MR originally delegated 920 the MNP. 922 If the checks are not valid, MR MUST silently ignore the message. 923 Otherwise 925 - Those MNP(s) which have zero lifetimes, are going to be expired and 926 SHOULD not be used anymore after this message is received. Those 927 MNP(s) which have non-zero lifetimes, can be used as before, and 928 the lifetimes of those MNP(s) SHOULD be updated on local storage. 930 Based on the received update message a MNP Delegation-Message MUST be 931 constructed on items concerning IP source address field, Home Address 932 destination option and binding update list as described in chapter 5.4.1 933 for MR functionality. In addition the other items are constructed as 934 follows: 936 - IP destination address field: Destination address MUST be copied 937 from the destination address field of the corresponding update 938 message. 940 - Transaction identifier: The Transaction identifier MUST be copied 941 from the corresponding update message. 943 - The match field: Match field MUST be copied from the corresponding 944 update message's MNP Data Options. 946 - MNP Option and ICMPv6 code: MR MUST check that the MNP(s) in the 947 update have before been delegated to the MR. Those MNP(s) which 948 have been delegated before MUST be copied from the update message 949 to MNP Data Option of the message. Those MNP(s) which cannot be 950 updated, MUST have all zeros in the MNP field of the MNP Data 951 Option. If one or more of the updated MNP(s) were updated 952 successfully, ICMPv6 code of the message is set to 953 'MNP Update Ack'. If none of the MNP(s) could be updated 954 successfully, the MNP Data Options MUST be copied from the update 955 message to the response, and the ICMPv6 code MUST be set to 'MNP 956 Unavailable' 958 The MNP Delegation-Message message may not reach its destination and 959 the same MNP Delegation-Message message might be retransmitted to the 960 MR. In this case the retransmitted message MUST be handled similarly as 961 previously received identical messages. 963 5.5 Examples 965 In this section a transaction related to both MNP Query and MNP 966 Delegation sequences are depicted. In the first case MR is at home and 967 in the second case MR is at a foreign domain. Also a transaction related 968 to MNP Updating sequence is presented as defined in chapter 5.4.5. 970 5.5.1 MNP Query sequence 972 MR at home: 974 _____________ ___________ 975 ( ) / \ 976 ( Internet )------|Home domain |---HA 977 (_____________) \__________/ 978 | 979 MR 981 In this example the MR is at home and proceeds with MNP Query with its 982 HA. MR wants to be delegated an arbitrary MNP of length 48 and a certain 983 MNP (4ffe:1:1:1/64). HA responds back to the MR by informing that a MNP 984 of 48 can be delegated from the HA and 4ffe:1:1:1/64 MNP is not 985 available for delegation. 987 Message flows: 989 MR HA 991 -----------------------------------------------> 992 MNP Delegation-Message 994 IP fields: 995 [ 996 Source address: MR's home address 997 Destination address: HA address 998 ] 1000 ICMP fields: 1001 [ 1002 Type: MNP Delegation-Message 1003 Code: MNP Delegator Query 1004 Transaction ID: 23456 1005 Reserved: 0 1007 MNP Option: 1008 [ 1009 Type=0x01 1010 Option length=2*sizeof(MNP Data Option) 1012 MNP Data Option 1013 [ 1014 Preferred lifetime: 3600 1015 Valid lifetime: 3600 1016 Prefix length: 48 1017 IPv6 Prefix: 0x0 1018 Match: 1 1019 ] 1021 MNP Data Option 1022 [ 1023 Preferred lifetime: 3600 1024 Valid lifetime: 3600 1025 Prefix length: 64 1026 IPv6 Prefix: 4ffe:1:1:1 1027 Match: 0 1028 ] 1029 ] 1030 ] 1032 <----------------------------------------------- 1034 MNP Delegation-Message 1036 IP fields: 1037 [ 1038 Source address: HA's address 1039 Destination address: MR's home address 1040 ] 1042 ICMP fields: 1043 [ 1044 Type: MNP Delegation-Message 1045 Code: MNP Delegator 1046 Transaction ID: 23456 1047 Reserved: 0 1049 MNP Option: 1050 [ 1051 Type=0x01 1052 Option length=2*sizeof(MNP Data Option) 1054 MNP Data Option 1055 [ 1056 Preferred lifetime: 3600 1057 Valid lifetime: 3600 1058 Prefix length: 48 1059 IPv6 Prefix: 3ffe:2222:2222::0 1060 Match: 1 1061 ] 1063 MNP Data Option 1064 [ 1065 Preferred lifetime: 0 1066 Valid lifetime: 0 1067 Prefix length: 64 1068 IPv6 Prefix: 0::0 1069 Match: 0 1070 ] 1071 ] 1072 ] 1074 5.5.2 MNP Delegation Sequence 1076 MR not at home: 1078 _____________ __________ 1079 ( ) / \ 1080 ( Internet )------|Home domain|---HA 1081 (_____________) \_________/ 1082 | 1083 ___|_______ 1084 | | 1085 | Foreign | 1086 | domain | 1087 \________/ 1088 | 1089 | 1090 MR 1092 In this example the MR is at a foreign domain and proceeds with MNP 1093 delegation with its HA. MR wants to be delegated a certain MNP of length 1094 48. HA responds by delegating the MNP for the MR. 1096 Message flows: 1098 MR HA 1100 -----------------------------------------------> 1102 MNP Delegation-Message 1104 IP fields: 1105 [ 1106 Source address: MR's COA 1107 Destination address: HA's address 1108 ] 1110 Home address destination option 1111 [ 1112 Home Address=MR's home address 1113 ] 1115 ICMP fields: 1116 [ 1117 Type: MNP Delegation-Message 1118 Code: MNP Request 1119 Transaction ID: 67890 1120 Reserved: 0 1122 MNP Option: 1123 [ 1124 Type=0x01 1125 Option length=1*sizeof(MNP Data Option) 1127 MNP Data Option 1128 [ 1129 Preferred lifetime: 3600 1130 Valid lifetime: 3600 1131 Prefix length: 48 1132 IPv6 Prefix: 3ffe:2222:2222::0 1133 Match: 0 1134 ] 1135 ] 1136 ] 1138 <----------------------------------------------- 1140 MNP Delegation-Message 1142 IP fields: 1143 [ 1144 Source address: HA's address 1145 Destination address: MR's COA 1146 ] 1148 Type 2 Routing Header 1149 [ 1150 Home Address=MR's Home Address 1151 ] 1153 ICMP fields: 1154 [ 1155 Type: MNP Delegation-Message 1156 Code: MNP Delegated 1157 Transaction ID: 67890 1158 Reserved: 0 1160 MNP Option: 1161 [ 1162 Type=0x01 1163 Option length=1*sizeof(MNP Data Option) 1165 MNP Data Option 1166 [ 1167 Preferred lifetime: 3600 1168 Valid lifetime: 3600 1169 Prefix length: 48 1170 IPv6 Prefix: 3ffe:2222:2222::0 1171 Match: 0 1172 ] 1173 ] 1174 ] 1176 5.5.3 MNP Updating sequence 1178 MR not at home: 1180 _____________ __________ 1181 ( ) / \ 1182 ( Internet )------|Home domain|---HA 1183 (_____________) \_________/ 1184 | 1185 ___|_______ 1186 | | 1187 | Foreign | 1188 | domain | 1189 \________/ 1190 | 1191 | 1192 MR 1194 In this example the MR is at a foreign domain and HA proceeds with 1195 updating the lifetimes of the previously delegated MNP to zero. After 1196 this sequence the updated MNP is no longer valid in the MR, and MR has 1197 to delegate a new MNP by running the MNP Query and MNP Delegation 1198 sequences. 1200 Message flows: 1202 HA MR 1203 -----------------------------------------------> 1205 MNP Delegation Message: 1207 IP fields: 1208 [ 1209 Source address: HA address 1210 Destination address: MR's COA 1211 ] 1213 Type 2 Routing header 1214 [ 1215 Home Address=MR's home address 1216 ] 1218 ICMP fields: 1219 [ 1220 Type: MNP Delegation-Message 1221 Code: MNP Update 1222 Transaction ID: 948738 1223 Reserved: 0 1225 MNP Option: 1226 [ 1227 Type=0x01 1228 Option length=1*sizeof(MNP Data Option) 1230 MNP Data Option 1231 [ 1232 Preferred lifetime: 0 1233 Valid lifetime: 0 1234 Prefix length: 48 1235 IPv6 Prefix: 3ffe:2222:2222::0 1236 Match: 0 1237 ] 1238 ] 1239 ] 1241 HA MR 1243 <----------------------------------------------- 1245 MNP Delegation-Message 1247 IP fields: 1248 [ 1249 Source address: MR's COA 1250 Destination address: HA's address 1251 ] 1253 Home address destination option 1254 [ 1255 Home Address=MR's home address 1256 ] 1258 ICMP fields: 1259 [ 1260 Type: MNP Delegation-Message 1261 Code: MNP Update-Ack 1262 Transaction ID: 948738 1263 Reserved: 0 1265 MNP Option: 1266 [ 1267 Type=0x01 1268 Option length=1*sizeof(MNP Data Option) 1270 MNP Data Option 1271 [ 1272 Preferred lifetime: 0 1273 Valid lifetime: 0 1274 Prefix length: 48 1275 IPv6 Prefix: 3ffe:2222:2222::0 1276 Match: 0 1277 ] 1278 ] 1279 ] 1281 6. Constants 1283 MNP_REQUEST_DELAY=500 1284 MNP_REQUEST_MAX_RETRIES=3 1286 7. Security issues 1288 Security issues of this MIPv6 extension are not considered in the 1289 draft. These issues must be considered in the next version of the draft. 1291 Acknowledgements 1293 The author would like to thank the following persons on the NEMO mailing 1294 list for feedback in an alphabetical order: 1296 Erik Nordmark 1297 Alexandru Petrescu 1298 Mattias Pettersson 1300 References 1302 [1] S. Bradner "Key words for use in RFCs to Indicate Requirement 1303 Levels" BCP 14, RFC 2119, Internet Engineering Task Force, March 1304 1997. 1306 [2] D. B. Johnson, C. E. Perkins, J. Arkko "Mobility Support in IPv6" 1307 (draft-ietf-mobile-ipv6-21), Internet Draft, Internet Engineering 1308 Task Force, Feb 2003. 1310 [3] T. Ernst, H. Lach "Network Mobility Support Terminology" (draft- 1311 ernst-nemo-terminology-01), Internet Draft, Internet Engineering 1312 Task Force, Nov 2002. 1314 [4] NEtwork MObility working group website URL: http://www.nal.motlabs. 1315 com/nemo. 1317 [5] M. Crawford "Router Renumbering for IPv6" RFC 2894, Internet 1318 Engineering Task Force, Aug 2000. 1320 [6] T. J. Kniveton, J. T. Malinen, V. Devarapalli, C. E. Perkins "Mobile 1321 Router Tunneling Protocol" (draft-kniveton-mobrtr-03) Internet 1322 Draft, Internet Engineering Task Force, Nov 2002. 1324 [7] B. Haberman, J. Martin "Automatic Prefix Delegation Protocol for 1325 Internet Protocol Version 6 (IPv6)" 1326 (draft-haberman-ipngwg-auto-prefix-02), Internet Draft, Internet 1327 Engineering Task Force, Feb 2002. 1329 [8] O. Troan, R. Droms "IPv6 Prefix Options for DHCPv6" 1330 (draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03), Internet Draft, 1331 Internet Engineering Task Force, March, 2003. 1333 [9] A. Conta, S. Deering "Internet Control Message Protocol (ICMPv6) 1334 for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, 1335 Internet Engineering Task Force, Dec 1998. 1337 [10] S. Deering, R. Hinden "Internet Protocol, Version 6 (IPv6) 1338 Specification" RFC 2460, Dec 1998. 1340 [11] Wakikawa R. K. Uehara, K. Mitsuya, T. Ernst "Basic Metwork Mobility 1341 Support" (draft-wakikawa-nemo-basic-00), Internet Draft, Internet 1342 Engineering Task Force, Feb, 2003. 1344 Authors' addresses 1346 Pekka P��kk�nen 1347 VTT Electronics 1348 Kaitov�yl� 1 1349 90571 Oulu 1350 Finland 1351 email: pekka.paakkonen@vtt.fi 1353 Juhani Latvakoski 1354 VTT Electronics 1355 Kaitov�yl� 1 1356 90571 Oulu 1357 Finland 1358 email: juhani.latvakoski@vtt.fi 1359 Full Copyright Statement 1361 Copyright (C) The Internet Society (2003). All Rights Reserved. 1363 This document and translations of it may be copied and furnished to 1364 others, and derivative works that comment on or otherwise explain it 1365 or assist in its implementation may be prepared, copied, published 1366 and distributed, in whole or in part, without restriction of any 1367 kind, provided that the above copyright notice and this paragraph are 1368 included on all such copies and derivative works. However, this 1369 document itself may not be modified in any way, such as by removing 1370 the copyright notice or references to the Internet Society or other 1371 Internet organizations, except as needed for the purpose of 1372 developing Internet standards in which case the procedures for 1373 copyrights defined in the Internet Standards process must be 1374 followed, or as required to translate it into languages other than 1375 English. 1377 The limited permissions granted above are perpetual and will not be 1378 revoked by the Internet Society or its successors or assigns. 1380 This document and the information contained herein is provided on an 1381 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1382 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1383 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1384 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1385 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.