idnits 2.17.1 draft-ietf-mip4-nemo-haaro-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 16, 2011) is 4545 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'MR A' is mentioned on line 2093, but not defined == Missing Reference: 'MR B' is mentioned on line 1973, but not defined == Missing Reference: 'MR C' is mentioned on line 2093, but not defined == Missing Reference: 'Node A' is mentioned on line 2093, but not defined == Missing Reference: 'HA' is mentioned on line 2093, but not defined == Missing Reference: 'Node C' is mentioned on line 2093, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-mip4-multiple-tunnel-support-02 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Makela 3 Internet-Draft Aalto University, Department of 4 Intended status: Experimental Communications and 5 Expires: May 19, 2012 Networking (Comnet) 6 J. Korhonen 7 Nokia Siemens Networks 8 November 16, 2011 10 Home Agent assisted Route Optimization between Mobile IPv4 Networks 11 draft-ietf-mip4-nemo-haaro-07 13 Abstract 15 This document describes a Home Agent assisted Route Optimization 16 functionality to IPv4 Network Mobility Protocol. The function is 17 designed to facilitate optimal routing in cases where all nodes are 18 connected to a single Home Agent, thus the use case is Route 19 Optimization within single organization or similar entity. The 20 functionality adds the possibility to discover eligible peer nodes 21 based on information received from Home Agent, Network Prefixes they 22 represent, and how to establish a direct tunnel between such nodes. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 19, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and motivations . . . . . . . . . . . . . . . . . 4 59 2. Terms and definitions . . . . . . . . . . . . . . . . . . . . 6 60 3. Mobile IPv4 route optimization between mobile networks . . . . 8 61 3.1. Maintaining route optimization information . . . . . . . . 9 62 3.1.1. Advertising route-optimizable prefixes . . . . . . . . 9 63 3.1.2. Route Optimization cache . . . . . . . . . . . . . . . 11 64 3.2. Return routability procedure . . . . . . . . . . . . . . . 13 65 3.2.1. Router keys . . . . . . . . . . . . . . . . . . . . . 15 66 3.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . 16 67 3.2.3. Updating Router keys and Nonces . . . . . . . . . . . 16 68 3.3. Mobile-Correspondent Router operations . . . . . . . . . . 17 69 3.3.1. Triggering Route Optimization . . . . . . . . . . . . 17 70 3.3.2. Mobile Router routing tables . . . . . . . . . . . . . 17 71 3.3.3. Inter-Mobile Router registration . . . . . . . . . . . 18 72 3.3.4. Inter-Mobile Router tunnels . . . . . . . . . . . . . 20 73 3.3.5. Constructing route-optimized packets . . . . . . . . . 21 74 3.3.6. Handovers and Mobile Routers leaving network . . . . . 21 75 3.4. Convergence and synchronization issues . . . . . . . . . . 22 76 4. Data compression schemes . . . . . . . . . . . . . . . . . . . 23 77 4.1. Prefix compression . . . . . . . . . . . . . . . . . . . . 24 78 4.2. Realm compression . . . . . . . . . . . . . . . . . . . . 26 79 4.2.1. Encoding of compressed realms . . . . . . . . . . . . 26 80 4.2.2. Searching algorithm . . . . . . . . . . . . . . . . . 27 81 4.2.3. Encoding example . . . . . . . . . . . . . . . . . . . 28 82 5. New Mobile IPv4 messages and extensions . . . . . . . . . . . 30 83 5.1. Mobile Router Route Optimization capability . . . . . . . 30 84 5.2. Route optimization reply . . . . . . . . . . . . . . . . . 31 85 5.3. Mobile-Correspondent authentication extension . . . . . . 32 86 5.4. Care-of address Extension . . . . . . . . . . . . . . . . 33 87 5.5. Route optimization prefix advertisement . . . . . . . . . 33 88 5.6. Home-Test Init message . . . . . . . . . . . . . . . . . . 35 89 5.7. Care-of-Test Init message . . . . . . . . . . . . . . . . 36 90 5.8. Home Test message . . . . . . . . . . . . . . . . . . . . 36 91 5.9. Care-of test message . . . . . . . . . . . . . . . . . . . 37 92 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 38 93 6.1. NATs and stateful firewalls . . . . . . . . . . . . . . . 38 94 6.2. Handling of concurrent handovers . . . . . . . . . . . . . 40 95 6.3. Foreign Agents . . . . . . . . . . . . . . . . . . . . . . 40 96 6.4. Multiple Home Agents . . . . . . . . . . . . . . . . . . . 40 97 6.5. Mutualness of Route Optimization . . . . . . . . . . . . . 41 98 6.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 42 99 6.7. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 42 100 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 43 101 8. Example signaling scenarios . . . . . . . . . . . . . . . . . 43 102 8.1. Registration request . . . . . . . . . . . . . . . . . . . 43 103 8.2. Route optimization with return routability . . . . . . . . 44 104 8.3. Handovers . . . . . . . . . . . . . . . . . . . . . . . . 46 105 9. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 47 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 107 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 108 11.1. Return Routability . . . . . . . . . . . . . . . . . . . . 50 109 11.2. Trust relationships . . . . . . . . . . . . . . . . . . . 50 110 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 111 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 112 13.1. Normative References . . . . . . . . . . . . . . . . . . . 51 113 13.2. Informative References . . . . . . . . . . . . . . . . . . 51 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 116 1. Introduction and motivations 118 Traditionally, there has been no method for route optimization in 119 Mobile IPv4 [RFC5944] apart from an early attempt 120 [I-D.ietf-mobileip-optim]. Unlike Mobile IPv6 [RFC3775], where Route 121 Optimization has been included from the start, with Mobile IPv4 route 122 optimization hasn't been addressed in a generalized scope. 124 Even though general route optimization may not be of interest in the 125 scope of IPv4, there are still specific applications for Route 126 Optimization in Mobile IPv4. This document proposes a method to 127 optimize routes between networks behind Mobile Routers, as defined by 128 NEMO [RFC5177]. Although NAT and the pending shortage of IPv4 129 addresses makes widespread deployment of end-to-end route 130 optimization infeasible, using Route Optimization from a Mobile 131 router to Mobile router is still a practical scenario. Note that the 132 method specified in this document is only for Route Optimization 133 between Mobile Routers; any network prefix not advertised by a Mobile 134 Router would still be routed via the Home Agent, although an MR could 135 advertise very large address spaces, e.g. by acting as an Internet 136 gateway. 138 A particular use case concerns setting up redundant yet economical 139 enterprise networks. Recently, a trend has emerged where customers 140 prefer to maintain connectivity via multiple service providers. 141 Reasons include redundancy, reliability, and availability issues. 142 These kinds of multi-homing scenarios have traditionally been solved 143 by using such technologies as multihoming BGP. However, a more 144 lightweight and economical solution is desirable. 146 From a service provider perspective a common topology for an 147 enterprise customer network consists of one to several sites 148 (typically headquarters and various branch offices). These sites are 149 typically connected via various Layer 2 technologies (ATM or Frame 150 relay PVCs), MPLS VPNs, or Layer 3 site-to-site VPNs. With a Service 151 Level Agreement, a customer can obtain a very reliable and well 152 supported intranet connectivity. However, compared to the cost of 153 "consumer-grade" broadband Internet access the SLA-guaranteed version 154 can be considered very expensive. These consumer-grade options, 155 however, are not reliable approach for mission-critical applications. 157 Mobile IP, especially Mobile Routers, can be used to improve 158 reliability of connectivity even when implemented over consumer-grade 159 Internet access. The customer becomes a client for a virtual service 160 provider, which does not take part in the actual access technology. 161 The service provider has a backend system and an IP address pool that 162 it distributes to customers. Access is provided by multiple, 163 independent, possibly consumer-grade ISPs, with Mobile IP providing 164 seamless handovers if service from a specific ISP fails. The 165 drawback of this solution is that it creates a star topology; All 166 Mobile IP tunnels end up at the service provider hosted home agent, 167 causing heavy load at the backend. Route Optimization between mobile 168 networks addresses this issue, by taking network load off the home 169 agent and the backend. 171 An example network is pictured below: 173 +----------------------------+ 174 | Virtual Operator Backend | 175 +------------+ +-----+ 176 | Home Agent | | AAA | 177 +------------+---------+-----+ 178 | 179 .--. 180 _(. `) 181 _( ISP `)_ 182 ( Peering `) 183 ( ` . Point ) ) 184 `--(_______)--' 185 ____ / | \ 186 / | \ 187 .--. .--. .--. 188 _( `. _( `. _( `. 189 ( ISP A ) ( ISP B ) ( ISP C ) 190 ( ` . ) ) ( ` . ) ) ( ` . ) ) 191 `--(___.-' `--(___.-' `--(___.-' 192 | ______/ \ / 193 | / \ / 194 | / \ / 195 +----+ +----+ 196 |MR A| |MR B| 197 +----+ +----+ 198 | | 199 .--. .--. 200 _( `. _( `. 201 ( Site A ) ( Site B ) 202 ( ` . ) ) ( ` . ) ) 203 `--(___.-' `--(___.-' 205 Virtual service provider architecture using NEMOv4 207 In this example case, the organization network consists of two sites 208 that are connected via 2 ISPs for redundancy reasons. Mobile IP 209 allows fast handovers without problems of multi-homing and BGP 210 peering between each individual ISP and the organization. The 211 traffic however takes a non-optimal route through the virtual 212 operator backend. 214 Route optimization addresses this issue, allowing traffic between 215 Sites A and B to flow directly through ISP B's network, or in case of 216 a link failure, via the ISP peering point (such as MAE-WEST). The 217 backend will not suffer from heavy loads. 219 The specification in this document is meant to be experimental, with 220 the primary design goal is to limit the load on the backend to 221 minimum. Additional design goals include extensibility to a more 222 generalized scope, such as not requiring all MRs to be homed on the 223 same Home Agent. Experiences are mostly sought on applicability to 224 real-world operations, and protocol-specific issues such as signaling 225 scalability, interworking with other Mobile IP extensions not 226 specifically addressed in the document and behavior of end-user 227 applications over route-optimized paths. 229 The aforementioned use-case is the original application. Moving to 230 standards track should be considered after enough deployment 231 experience has been gathered. Besides the aforementioned issues, 232 additional elements that might require refinement based on real-world 233 experiences are delivery of information on networks managed by peer 234 Mobile Routers, conducting of the MR<->MR authentication, reaction 235 and recovery methods to connectivity breakdowns and other break- 236 before-make topology changes, keepalive timer intervals, formats of 237 signaling extensions, behavior in NAT/firewalled environment and the 238 prefix and realm compression algorithms. 240 2. Terms and definitions 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in RFC 2119 [RFC2119]. 246 Care-of Address (CoA) 248 RFC 5944 [RFC5944] defines Care-of Address as the termination 249 point of a tunnel toward a mobile node, for datagrams forwarded 250 to the mobile node while it is away from home. The protocol can 251 use two different types of care-of address: a "foreign agent 252 care-of address" which is an address of a foreign agent with 253 which the mobile node is registered, and a "co-located care-of 254 address", which is an externally obtained local address which 255 the mobile node has associated with one of its own network 256 interfaces. However, in the case of Network Mobility, foreign 257 agents are not used, so no foreign care-of addresses are used 258 either. 260 Correspondent Router (CR) 262 RFC 5944 [RFC5944] defines a Correspondent node as a peer with 263 which a mobile node is communicating. Correspondent Router is a 264 peer Mobile Router which MAY also represent one or more entire 265 networks. 267 Home Address (HoA) 269 RFC 5944 [RFC5944] defines Home Address as an IP address that is 270 assigned for an extended period of time to a mobile node. It 271 remains unchanged regardless of where the node is attached to 272 the Internet. 274 Home Agent (HA) 276 RFC 5944 [RFC5944] defines Home Agent as a router on a mobile 277 node's home network which tunnels datagrams for delivery to the 278 mobile node when it is away from home, and maintains current 279 location information for the mobile node. For this application, 280 the "home network" sees limited usage. 282 Host Network Prefix 284 Network Prefix with the mask of /32. e.g. 192.0.2.254/32, 285 consisting of a single host. 287 Mobility Binding 289 RFC 5944 [RFC5944] defines Mobility Binding as the association 290 of Home Address with a Care-of address, along with the lifetime 291 remaining for that association. 293 Mobile Network Prefix RFC 5177 [RFC5177] defines Mobile Network 294 Prefix as the network prefix of the subnet delegated to a Mobile 295 Router as the Mobile Network. 297 Mobile Router (MR) 299 Mobile Router as defined by RFC 5177 [RFC5177] and RFC 5944 300 [RFC5944]. They define a Mobile Router as a mobile node that 301 can be a router that is responsible for the mobility of one or 302 more entire networks moving together, perhaps on an airplane, a 303 ship, a train, an automobile, a bicycle, or a kayak. 305 Route Optimization Cache 307 Data structure maintained by Mobile Routers on possible 308 destinations for Route Optimization. Contains information (Home 309 Addresses) on potential Correspondent Routers and their 310 associated Mobile Networks. 312 Return Routability, RR 314 Procedure to bind a Mobile Router's Home Address to a Care-of 315 address on a Correspondent Router with a degree of trust. 317 | (Concatenation) 319 Some formulas in this specification use the symbol "|" to 320 indicate bytewise concatenation, as in A | B. This concatenation 321 requires that all of the octets of the datum A appear first in 322 the result, followed by all of the octets of the datum B. 324 First (size, input) 326 Some formulas in this specification use a functional form "First 327 (size, input)" to indicate truncation of the "input" data so 328 that only the first "size" bits remain to be used. 330 3. Mobile IPv4 route optimization between mobile networks 332 This section describes the changed functionality of Home Agent and 333 Mobile Router compared to the base NEMOv4 operation defined in 334 [RFC5177]. The basic premise is still the same; Mobile Routers, when 335 registering to the Home Agent, may inform the Home Agent of the 336 mobile network prefixes they are managing (explicit mode) or the Home 337 Agent already knows the prefix assignments. However, instead of 338 prefix <-> Mobile Router mapping information only remaining on the 339 Home Agent and the single Mobile Router, this information will now be 340 distributed to the other Mobile Routers as well. 342 The Home Agent-assisted Route Optimization is primarily intended for 343 helping to optimize traffic patterns between multiple sites in a 344 single organization or administrative domain; however, extranets can 345 also be reached with optimized routes, as long as all Mobile Routers 346 connect to the same Home Agent. The procedure aims to maintain 347 backwards compatibility; with legacy nodes or routers full 348 connectivity is always preserved even though optimal routing cannot 349 be guaranteed. 351 The scheme requires a Mobile Router to be able to receive messages 352 from other Mobile Routers unsolicited - that is, without first 353 initiating a request. This behavior - accepting unsolicited messages 354 - is similar to the registration revocation procedure [RFC3543]. 355 Many of the mechanisms are the same - including the fact that 356 advertising route optimization support upon registration implies 357 capability to receive registration requests and return routability 358 messages from other Mobile Routers. 360 Compared to IPv6, where Mobile Node <-> Correspondent node bindings 361 are maintained via Mobility Routing header and Home Address options, 362 Mobile IPv4 always requires the use of tunnels. Therefore, inter- 363 mobile-router tunnel establishment has to be conducted. 365 3.1. Maintaining route optimization information 367 During registration, a registering Mobile Router MAY request 368 information on route-optimizable network prefixes. The Mobile Router 369 MAY also allow redistribution of information on its managed network 370 prefixes regardless of whether they are explicitly registered or 371 already configured. These are indicated with a Mobile Router Route 372 Optimization capability extension; see Section 5.1. If the Home 373 Agent accepts the request for Route Optimization, this is indicated 374 with a Route Optimization Reply extension (Section 5.2) in the 375 registration reply. 377 Note that the redistribution of network prefix information from the 378 Home Agent happens only during the registration signaling. There are 379 no "routing updates" from the Home Agent except during re- 380 registrations triggered by handovers, registration timeouts, and 381 specific solicitation. The solicitation re-registration MAY occur if 382 a Correspondent Router receives a registration request from a unknown 383 Mobile Router (see Section 3.3.3). 385 3.1.1. Advertising route-optimizable prefixes 387 As noted, a NEMO-supporting Home Agent already maintains information 388 on which network prefixes are reachable behind specific Mobile 389 Routers. The only change to this functionality is that this 390 information can now be distributed to other Mobile Routers upon 391 request. This request is implied by including a Route Optimization 392 capability extension Route Optimization capability extension 393 (Section 5.1) and setting the 'R' bit. 395 When a Home Agent receives a registration request, standard 396 authentication and authorization procedures are conducted. 398 If registration is successful and the Route Optimization capability 399 information extension was present in the registration request, the 400 reply message MUST include Route Optimization Reply extension 401 (Section 5.2) to indicate that Route Optimization Capability 402 extension was understood. Furthermore, the extension also informs 403 the Mobile Router whether NAT was detected between Home Agent and the 404 Mobile Router using the procedure in RFC 3519 [RFC3519], which is 405 based on the discrepancy between requester's indicated Care-of 406 address and packet's source address. 408 The reply message MAY also include one route optimization prefix 409 advertisement extension which informs the Mobile Router of existing 410 mobile network prefixes and the Mobile Routers that manage them, if 411 eligible for redistribution. The networks SHOULD be included in 412 order of priority, with the prefixes determined by policy as most 413 desirable targets for Route Optimization listed first. The extension 414 is constructed as shown in Section 5.5. The extension consists of a 415 list where each Mobile Router, identified by Home Address, is listed 416 with corresponding prefix(es) and their respective realm(s). 418 Each network prefix can be associated with a realm[RFC4282], usually 419 in the form 'organization.example.com'. Besides the routers in the 420 customer's own organization, the prefix list may also include other 421 Mobile Routers, e.g. a default prefix (0.0.0.0/0) pointing towards an 422 Internet gateway for Internet connectivity or additional prefixes 423 belonging to possible extranets. The realm information can be used 424 to make policy decisions on the Mobile Router, such as preferring 425 optimization within a specific realm only. Furthermore, the unique 426 realm information can be used to differentiate between overlapping 427 address spaces utilized by the same or different organizations 428 concurrently and adjusting forwarding policies accordingly. 430 In a typical scenario where Network Prefixes are allocated to Mobile 431 Routers connecting to a single Home Agent, the prefixes are usually 432 either continuous or at least very close to each other. Due to these 433 characteristics, an optional prefix compression mechanism is 434 provided. Another, optional, compression scheme is in use for realm 435 information, where realms often share the same higher-level domains. 436 These compression mechanisms are further explained in Section 4. 438 Upon receiving a registration reply with a Route Optimization prefix 439 advertisement extension, the Mobile Router SHALL insert the Mobile 440 Router Home Addresses included in the extension as host-prefixes to 441 the local Route Optimization Cache if they do not already exist. If 442 present, any additional prefixes information SHALL also be inserted 443 into the Route Optimization Cache. 445 The Mobile Router MAY discard entries from a desired starting point 446 onwards, due to memory or other policy related constraints. The 447 intention of listing the prefixes in order of priority is to provide 448 implicit guidance for this decision. If the capacity of the device 449 allows, the Mobile Router SHOULD use information on all advertised 450 prefixes. 452 3.1.2. Route Optimization cache 454 Mobile routers supporting route optimization will maintain a Route 455 Optimization Cache. 457 The Route Optimization Cache contains mappings between potential 458 Correspondent Router HoA's, network(s) associated with each HoA, 459 information on reachability related to NAT and other divisions, and 460 Return Routability procedure-related information. The Cache is 461 populated based on information received from the Home Agent in Route 462 optimization prefix advertisements and in registration messages from 463 Correspondent Routers. Portions of the cache may also be configured 464 statically. 466 The Route Optimization Cache contains the following information for 467 all known Correspondent Routers. Note that some fields may contain 468 multiple entries. For example, during handovers, there may be both 469 old and new CoA's listed. 471 CR-HoA 473 Correspondent Router's Home Address. Primary key 474 identifying each CR. 476 CR-CoAs 478 Correspondent Router's Care-of Address(es). May be empty 479 if none known. Potential tunnel's destination address(es). 481 MR-CoAs 483 Mobile Router's Care-of Address(es) used with this 484 Correspondent Router. Tunnel's source address. 486 Tunnels 488 Tunnel interface(s) associated with this Correspondent 489 Router. The tunnel interface itself handles all the 490 necessary operations to keep the tunnel operational, e.g. 491 Sending keepalive messages required by UDP encapsulation. 493 NAT states 495 A table of booleans, set for all pairs of potential MR- 496 CoA's and CR-CoA's which require NAT awareness and the 497 behavior is known, populated either statically or based on 498 discovery. If set to true, the MR can establish a UDP 499 tunnel towards the CR, using this pair of CoA's. A 500 received advertisement can indicate this to be set 501 initially false for all respective CR's CoA's. Affects 502 tunnel establishment direction; see Section 3.3.4 and the 503 registration procedure in deciding which Care-of-addresses 504 to include in the Care-of-address extension in registration 505 reply. If set to true, mandates use of UDP encapsulation. 507 RRSTATEs 509 Return routability state for each CR-HoA and MR-CoA pair. 510 States are INACTIVE, IN PROGRESS and ACTIVE. If state is 511 INACTIVE, return routability procedure must be completed 512 before forwarding route-optimized traffic. If state is IN 513 PROGRESS or ACTIVE, the information concerning this 514 Correspondent Router MUST NOT be removed from Route 515 Optimization Cache as long as a tunnel to the Correspondent 516 Router is established. 518 KRms 520 Registration management key for each CR-HoA - MR-CoA pair. 521 This field is only used if configured statically - if the 522 KRm was computed using Return Routability procedure, it is 523 calculated in-situ based on nonces and router key. If 524 configured statically, RRSTATE is permanently set to 525 ACTIVE. 527 Care-of nonce indices 529 If the KRm was established with Return Routability 530 procedure, contains the Care-of nonce index for each MR-CoA 531 - CR-HoA pair. 533 Care-of keygen token 535 If the KRm was established with Return Routability 536 procedure, contains the Care-of keygen token for each MR- 537 CoA - CR-HoA pair. 539 Home nonce indices 541 If the KRm was established with Return Routability 542 procedure, contains the Home nonce index for each CR-HoA 544 Home keygen token 546 If the KRm was established with Return Routability 547 procedure, contains the Home keygen token for each CR-HoA. 549 Network Prefixes 551 A list of destination network prefixes reachable via this 552 Correspondent Router. Includes network and prefix length, 553 e.g. 192.0.2.0/25. Always contains at least a single 554 entry, the CR-HoA host network prefix in the form of 555 192.0.2.1/32. 557 Realms 559 Each prefix may be associated with a realm. May also be 560 empty, if realm is not provided by advertisement or 561 configuration. 563 Prefix_Valid 565 Boolean field for each prefix - CR-HoA pair, which is set 566 to true if this prefix's owner has been confirmed. The 567 Host Network Prefix consisting of the Correspondent Router 568 itself does need validation beyond Return Routability 569 procedure. For other prefixes, the confirmation is done by 570 soliciting the information from HA. Traffic for prefixes 571 which have unconfirmed ownership should not be routed 572 through the tunnel. 574 Information that is no longer valid due to expirations or topology 575 changes MAY be removed from the Route Optimization Cache as desired 576 by the Mobile Router. 578 3.2. Return routability procedure 580 The purpose of return routability procedure is to establish Care-of- 581 Address <-> Home Address bindings in a trusted manner. The return 582 routability procedure for Mobile IPv6 is described in [RFC3775]. The 583 same principles apply to the Mobile IPv4 version: two messages are 584 sent to the Correspondent Router's Home Address, one via Home Agent 585 using Mobile Router's Home Address, and the other directly from the 586 Mobile Router CoA, with two responses coming through same routes. 588 Registration management key is derived from token information carried 589 on these messages. This registration management key (KRm) can then 590 be used to authenticate registration requests (comparable to Binding 591 Updates in Mobile IPv6). 593 The Return Routability procedure is a method provided by the Mobile 594 IP protocol to establish the KRm in a relatively lightweight fashion. 595 If desired, the KRm's can be configured to Mobile Routers statically, 596 or using a desired external secure key provisioning mechanism. If 597 KRm's are known to the Mobile Routers via some other mechanism, the 598 Return Routability procedure can be skipped. Such provisioning 599 mechanisms are out of scope for this document. 601 The main assumption on traffic patterns is that the Mobile Router 602 that initiates the RR procedure can always send outbound messages, 603 even when behind NAT or firewall. This basic assumption made for NAT 604 Traversal in [RFC3519] is also applicable here. In case the 605 Correspondent Router is behind such obstacles, it receives these 606 messages via the reverse tunnel to CR's Home Address, thus any 607 problem regarding the CR's connectivity is addressed during the 608 registration to the Home Agent. 610 The Return Routability procedure consists of four Mobile IP messages: 611 Home Test Init, Care-of Test Init, Home Test and Care-of Test. They 612 are constructed as shown in Section 5.6 through Section 5.9. If the 613 Mobile Router has included the Mobile Router Route Optimization 614 capability extension in its Registration Request, it MUST be able to 615 accept Return Routability messages. The messages are delivered as 616 Mobile IP signaling packets. The destination address of HoTI and 617 CoTI messages is set to Correspondent Router's HoA with the sources 618 being MR's home and care-of-address, respectively. 620 The return routability procedure begins with the Mobile Router 621 sending HoTI and CoTI messages, each containing a (different) 64-bit 622 random value, the cookie. The cookie is used to bind specific 623 signaling exchange together. 625 Upon receiving the HoTI or CoTI message the Correspondent Router MUST 626 have a secret Kcr and nonce. If it does not have this material yet, 627 it MUST produce it before continuing with the return routability 628 procedure. 630 Correspondent Router responds to HoTI and CoTI messages by 631 constructing HoT and CoT messages, respectively, as replies. The HoT 632 message contains home init cookie, current home nonce index and home 633 keygen token. The CoT message contains care-of init cookie, current 634 care-of nonce index and care-of keygen token. 636 The Home Keygen token is constructed as follows: 638 Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address | nonce 639 | 0))) 641 The Care-of Keygen token is constructed as follows: 643 Care-of keygen token = First (64, HMAC_SHA1 (Kcr, (Care-of address | 644 nonce | 1))) 646 Note that the Care-of address in this case is the source address of 647 the received CoTI message packet. The address may have changed in- 648 transit due to network address translation. This does not affect 649 registration process; subsequent registration requests are expected 650 to arrive from the same translated address. 652 Return Routability procedure SHOULD be initiated when the Route 653 Optimization Cache's RRSTATE field for the desired Care-of Address 654 with target Correspondent Router is INACTIVE. If the state was 655 INACTIVE, the state MUST be set to IN PROGRESS when Return 656 Routability procedure is initiated. In case of handover occurring, 657 the Mobile Router SHOULD only send a CoTI message to obtain a new 658 care-of keygen token; The home keygen token may still be valid. If 659 the reply to a registration indicates that one or both of the tokens 660 has expired, the RRSTATE MUST be set to INACTIVE. The Return 661 Routability procedure may then be restarted as needed. 663 Upon completion of Return Routability procedure, the Routing 664 Optimization Cache's RRSTATE field is set to ACTIVE, allowing for 665 registration requests to be sent. The Mobile Router will establish a 666 registration management key KRm by default using SHA1 hash algorithm: 668 KRm = SHA1 (home keygen token | care-of keygen token) 670 When de-registering (by setting time to zero), care-of keygen token 671 is not used. Instead the Registration management key is generated as 672 follows: 674 KRm = SHA1 (home keygen token) 676 Like in Mobile IPv6, the Correspondent Router does not maintain any 677 state for the Mobile Router until after receiving a registration 678 request. 680 3.2.1. Router keys 682 Each Mobile Router maintains a 'correspondent router key', Kcr, which 683 MUST NOT be shared with any other entity. Kcr is used for 684 authenticating peer Mobile Routers in the situation where a mobile 685 router is acting as a CR. This is analogous to node key, Kcn, in 686 Mobile IPv6. A Correspondent Router uses its router key to verify 687 that the keygen tokens sent by a peer Mobile Router in a registration 688 request are the CR's own. The router key MUST be a random number, 16 689 octets in length, generated with a good random number generator 690 [RFC4086]. 692 The Mobile Router MAY generate a new key at any time to avoid 693 persistent key storage. If desired, it is RECOMMENDED to expire the 694 keys in conjunction with nonces; see Section 3.2.3. 696 3.2.2. Nonces 698 Each Mobile Router also maintains one or more indexed nonces. Nonces 699 SHOULD be generated periodically with a good random number generator 700 [RFC4086]. The Mobile Router may use the same nonces with all Mobile 701 Routers. Nonces MAY be of any length, with the RECOMMENDED length 702 being 64 bits. 704 3.2.3. Updating Router keys and Nonces 706 The router keys and nonce updating guidelines are similar to ones in 707 Mobile IPv6. Mobile Routers keep both the current nonce and small 708 set of valid previous nonces whose lifetimes have not expired yet. 709 Nonce should remain valid for at least MAX_TOKEN_LIFETIME (see 710 Section 9) seconds after it has first been used in constructing a 711 return routability response. However, the correspondent router MUST 712 NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 9) 713 after the first use. As the difference between these two constants 714 is 30 seconds, a convenient way to enforce the above lifetimes is to 715 generate a new nonce every 30 seconds. The node can then continue to 716 accept keygen tokens that have been based on the last 8 717 (MAX_NONCE_LIFETIME / 30) nonces. This results in keygen tokens 718 being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds 719 after they have been sent to the mobile node, depending on whether 720 the token was sent at the beginning or end of the first 30 second 721 period. Note that the correspondent node may also attempt to 722 generate new nonces on demand, or only if the old nonces have been 723 used. This is possible, as long as the correspondent node keeps 724 track of how long a time ago the nonces were used for the first time, 725 and does not generate new nonces on every return routability request. 727 If Kcr is being updated, the update SHOULD be done at the same time 728 as nonce is updated. This way, nonce indexes can be used to refer to 729 both Kcr's and nonces. 731 3.3. Mobile-Correspondent Router operations 733 This section deals with the operation of Mobile and Correspondent 734 Routers performing route optimization. Note that in the context of 735 this document all routers work as both Mobile Router and 736 Correspondent Router. The term "Mobile Router" applies to the router 737 initiating the Route Optimization procedure, and "Correspondent 738 Router" indicates the peer router. 740 Especially compared to Mobile IPv6 route optimization there are two 741 issues that are different regarding IPv4. First of all, since Mobile 742 IPv4 always uses tunnels, there must be a tunnel established between 743 MR and CR's Care-of addresses. The Correspondent Router learns of 744 Mobile Router's Care-of address as it is provided by the Registration 745 Request. The Mobile Router learns the Correspondent Router's Care-of 746 address by a new extension, "Care-of Address", in the registration 747 reply. The second issue is a security consideration: in a 748 registration request, the Mobile Router claims to represent an 749 arbitrary IPv4 network. If the CR has not yet received this 750 information (HoA <-> Network prefix), it SHOULD perform a re- 751 registration to the Home Agent to verify the claim. 753 An additional aspect is that Mobile Router MAY use a different Care- 754 of-Address for different Correspondent Routers (and Home Agent). 755 This is useful in situations where the network provides only partial- 756 mesh connectivity, and specific interfaces must be used to reach 757 specific destinations. In addition, this allows for load balancing. 759 3.3.1. Triggering Route Optimization 761 Since each Mobile Router knows the eligible route-optimizable 762 networks, the route optimization between all Correspondent Routers 763 can be established at any time; however a better general practice is 764 to conduct Route Optimization on-demand only. It is RECOMMENDED to 765 start Route optimization only when sending a packet that originates 766 from a local managed network (and the network is registered as route 767 optimizable) and whose destination address falls within the network 768 prefixes of the Route Optimization Cache. With a small number of 769 Mobile Routers, such on-demand behavior may not be necessary and 770 full-mesh route-optimization may be in place constantly. 772 3.3.2. Mobile Router routing tables 774 Each Mobile Router maintains a routing table. In a typical 775 situation, the Mobile Router has one or more interface(s) to the 776 local networks, one or more interface(s) to wide-area networks (such 777 as provided by ISPs), and a tunnel interface to the Home Agent. 778 Additional tunnel interfaces become activated as Route Optimization 779 is being performed. 781 The routing table SHOULD typically contain Network Prefixes managed 782 by Correspondent Routers associated with established route-optimized 783 tunnel interfaces. A default route MAY point to the reverse tunnel 784 to the Home Agent if not overridden by prefix information. The 785 routing table MAY also include additional routes if required by 786 tunneling implementation. 788 The route for the Home Address of Correspondent Router SHOULD also be 789 pointing towards the tunnel taking the optimized path. 791 If two prefixes overlap each other, e.g. 192.0.2.128/25 and 792 192.0.2.128/29, the standard longest match rule for routing is in 793 effect. However, overlapping private address SHOULD be considered an 794 error situation. Any aggregation for routes in private address space 795 SHOULD be conducted only at HA. 797 3.3.3. Inter-Mobile Router registration 799 If route optimization between a Mobile Router and a Correspondent 800 Router is desired, either the Return Routability procedure must have 801 been performed ( See Section 3.2), or key KRm must be pre-shared 802 between the Mobile and Correspondent Router. If either condition 803 applies, a Mobile Router MAY send a registration request to the 804 Correspondent Router's HoA from the desired interface. 806 The registration request's source address and Care-of address field 807 are set to the address of the desired outgoing interface on the 808 Mobile Router. The address MAY be same as the Care-of address used 809 with the Home Agent. The Home Agent field is set to the Home Agent 810 of the Mobile Router. The registration request MUST be sent to (have 811 a destination address of) the Home Address of the Correspondent 812 Router. The registration request MUST include a Mobile-Correspondent 813 Authentication extension defined in Section 5.3 and SHOULD include a 814 Mobile Network Request Extension defined in [RFC5177]. If present, 815 the Mobile Network Request Extension MUST contain the network 816 prefixes, as if registering in explicit mode. If timestamps are 817 used, the Correspondent Router MUST check the identification field 818 for validity. The Authenticator field is hashed with the key KRm. 820 The Correspondent Router replies to the request with a Registration 821 Reply. The registration reply MUST include a Mobile-Correspondent 822 Authentication extension defined in Section 5.3 and, if Mobile 823 Network Request Extension was present in the request, a Mobile 824 Network Acknowledgement extension. 826 The encapsulation can be set as desired, except in the case where the 827 Route Optimization Cache Entry has NAT entries for the Correspondent 828 Router, or the Mobile Router itself is known to be behind NAT or 829 firewall. If either of the conditions apply, the Registration 830 Request MUST specify UDP encapsulation. It is RECOMMENDED to always 831 use UDP encapsulation to facilitate detection of path failures via 832 keepalive mechanism. 834 The Correspondent Router first checks the registration request's 835 authentication against Kcr and nonce indexes negotiated during Return 836 Routability procedure. This ensures that the registration request is 837 coming from a correct Mobile Router. If the check fails, an 838 appropriate registration reply code is sent (see Section 10). If the 839 failure is due to nonce index expiring, the Mobile Router sets 840 RRSTATE for the CR to INACTIVE. Return routability procedure MAY 841 then be initiated again. 843 If the check passes, the Correspondent Router MUST then check it's 844 Route Optimization Cache for whether the Mobile Router exists is 845 associated with the prefixes included in the request (Prefixes are 846 present and Flag HA is true for each prefix). Note that the 847 viewpoint is always local; the Correspondent Router compares CR-HoA 848 entries against the MR's Home Address - from the CR's perspective the 849 Mobile Router is also a "Correspondent Router". 851 If the check against the cache fails, the Correspondent Router SHOULD 852 send a re-registration request to Home Agent with the 'S' 853 (solicitation) bit set, thus obtaining the latest information on 854 Network Prefixes managed by the incoming Mobile Router. If, even 855 after this update, the prefixes still don't match, the reply's Mobile 856 Network Acknowledgement code MUST be set to "MOBNET_UNAUTHORIZED". 857 The registration MAY also be rejected completely. This verification 858 is done to protect against Mobile Routers claiming to represent 859 arbitrary networks; however, since the Home Agent is assumed to 860 provide trusted information, it can authorize the Mobile Router's 861 claim. If the environment itself is considered trusted, the 862 Correspondent Router can, as a policy, accept registrations without 863 this check; however, this is NOT RECOMMENDED as a general practice. 865 If the prefixes match, the Correspondent Router MAY accept the 866 registration. If the CR chooses to accept, the CR MUST check if a 867 tunnel to the Mobile Router already exists. If the tunnel does NOT 868 exist or has wrong endpoints (CoAs), a new tunnel MUST be established 869 and the Route Optimization Cache updated. The reply MUST include a 870 list of eligible care-of-addresses (see Section 5.4), with which the 871 Mobile Router may establish a tunnel. The reply MUST also include 872 Mobile-Correspondent Authentication extension (See Section 5.3). 874 Upon receiving the registration reply, the Mobile Router MUST check 875 if a tunnel to the Correspondent Router already exists. If the 876 tunnel does NOT exist, or has wrong endpoints (CoAs), a new tunnel 877 MUST be established and Route Optimization Cache updated. This is 878 covered in detail in Section 3.3.4. 880 The Correspondent Router's routing table MUST be updated to indicate 881 that the Mobile Router's networks are reachable via the direct tunnel 882 to the Mobile Router. 884 After the tunnel is established, the Mobile Router MAY update it's 885 routing tables to reach all Correspondent Router's Prefixes via the 886 tunnel, although it is RECOMMENDED to wait for the Correspondent 887 Router to perform it's own, explicit registration. This is primarily 888 a policy decision depending on the network environment. See 889 Section 6.5. 891 Due to the fact that the route optimization procedures may occur 892 concurrently at two Mobile Routers, each working as each other's 893 Correspondent Router, there may be a situation where two routers are 894 attempting to establish separate tunnels between them at the same 895 time. If a router with a smaller Home Address (meaning a normal 32- 896 bit integer comparison treating IPv4 addresses as 32-bit unsigned 897 integers) receives a registration request (in CR role) while its own 898 registration request (sent in MR role) is pending, the attempt should 899 be accepted with reply code "concurrent registration" (Value TBA_S1). 900 If receiving such an indication, the recipient SHOULD consider the 901 registration a success, but only act on it once the peer has 902 completed it's own registration. 904 3.3.4. Inter-Mobile Router tunnels 906 Inter-Mobile Router tunnel establishment follows establishing 907 standard reverse tunnels to the Home Agent. The registration request 908 to Correspondent Router includes information on the desired 909 encapsulation. It is RECOMMENDED to use UDP encapsulation. In the 910 cases of GRE [RFC2784], IP over IP [RFC2003] or minimal encapsulation 911 [RFC2004] no special considerations regarding the reachability are 912 necessary; The tunnel has no stateful information; The packets are 913 simply encapsulated within the GRE, IP, or minimal header. 915 The tunnel origination point for the Correspondent Router is its 916 Care-of Address, not the Home Address where the registration requests 917 were sent. This is different from creation of the Reverse Tunnel to 918 Home Agent, which reuses the channel from registration signaling. 920 Special considerations rise from using UDP encapsulation, especially 921 in cases where one of the Mobile Routers is located behind NAT or 922 firewall. A deviation from RFC 3519 [RFC3519] is that keepalives 923 should be sent both from ends of the tunnel to detect path failures 924 after the initial keepalive has been sent - this allows both MR and 925 CR to detect path failures. 927 The initial UDP keepalive SHOULD be sent by the MR. Only after first 928 keepalive is successfully completed, SHOULD the tunnel be considered 929 eligible for traffic. If reply to the initial keepalive is not 930 received, the MR may opt to attempt sending the keepalive with other 931 Care-of addresses provided by the registration reply to check whether 932 they provide better connectivity, or if all of these fail, perform a 933 re-registration via alternative interface, or deregister completely. 934 See Section 6.1. Once the initial keepalive packet has reached the 935 CR and reply has been sent, the CR MAY start sending its own 936 keepalives. 938 The original specification for UDP encapsulation suggests a keepalive 939 interval default of 110 seconds. However, to provide fast response 940 time and switching to alternate paths, it is RECOMMENDED, if power 941 and other constraints allow, to use considerably shorter periods, 942 adapting to the perceived latency as needed. However, the maximum 943 amount of keepalives should at no point exceed MAX_UPDATE_RATE times 944 per second. The purpose of keepalive is not to keep NAT or firewall 945 mappings in place, but serve as a mechanism to provide fast response 946 in case of path failures. 948 If both the Mobile Router and the Correspondent Router are behind 949 separate NATs, route optimization cannot be performed between them. 950 Possibilities to set up mutual tunneling when both routers are behind 951 NAT, are outside the scope of this document. However, some of these 952 issues are addressed in Section 6.1. 954 The designations "MR" and "CR" only apply to the initial tunnel- 955 establishment phase. Once a tunnel is established between two 956 routers, either of them can opt to either tear down the tunnel or 957 perform a handover. Signaling messages have to be authenticated with 958 valid KRm. 960 3.3.5. Constructing route-optimized packets 962 All packets received by the Mobile Router are forwarded using normal 963 routing rules according to the routing table. There are no special 964 considerations when constructing the packets, the tunnel interface's 965 own processes will encapsulate any packet automatically. 967 3.3.6. Handovers and Mobile Routers leaving network 969 Handovers and connection breakdowns can be categorized as either 970 ungraceful or graceful, also known as "break-before-make" (bbm) and 971 "make-before-break" (mbb) situations. 973 As with establishment, the "Mobile Router" discussed here is the 974 router wishing to change connectivity state, "Correspondent Router" 975 being the peer. 977 When a Mobile Router wishes to join its home link, it SHOULD, in 978 addition to sending the registration request to the Home Agent with 979 lifetime set to zero, also send such a request to all known 980 Correspondent Routers to their Home Address. The Correspondent 981 Router(s), upon accepting this request and sending the reply, will 982 check whether Route Optimization Cache contains any prefixes 983 associated with the requesting Mobile Router. These entries should 984 be removed and routing table updated accordingly (traffic for the 985 prefixes will be forwarded via the Home Agent again). The tunnel 986 MUST then be destroyed. A short grace period SHOULD be used to allow 987 possible in-transit packets to be received correctly. 989 In the case of a handover, the Correspondent Router simply needs to 990 update the tunnel's destination to the Mobile Router's new Care-of 991 Address. Mobile Router SHOULD keep accepting packets from both old 992 and new care-of Addresses for a short grace period, typically on the 993 order of ten seconds. In the case of UDP encapsulation, it is 994 RECOMMENDED to use same port numbers for both registration signaling 995 and tunneled traffic if possible. The initial keepalive message sent 996 by the MR will verify that direct connectivity exists between MR and 997 CR - if the keepalive fails, the MR SHOULD attempt alternate paths. 999 If the Mobile Router was unable to send the re-registration request 1000 before handover, it MUST send it immediately after handover has been 1001 completed and tunnel with the Home Agent is established. Since 1002 Care-of Address(es) changing invalidates the Krm, it is RECOMMENDED 1003 to conduct partial Return Routability by sending CoTI message via the 1004 new Care-of-Address and obtaining new care-of keygen token. In all 1005 cases, necessary tokens have also to be acquired if the existing ones 1006 have expired. 1008 If a reply is not received for a registration request to a 1009 Correspondent Router, any routes to the network prefixes managed by 1010 the Correspondent Router MUST be removed from the routing table, thus 1011 causing the user traffic to be forwarded via the Home Agent. 1013 3.4. Convergence and synchronization issues 1015 The information the Home Agent maintains on Mobile Network prefixes 1016 and the Mobile Routers' Route Optimization Caches do not need to be 1017 explicitly synchronized. This is based on the assumption that at 1018 least some of the traffic between nodes inside mobile networks is 1019 always bidirectional. If using on-demand route optimization, this 1020 also implies that when a node in a mobile network talks to a node in 1021 another mobile network, if the initial packet does not trigger Route 1022 Optimization, the reply packet will. 1024 Consider a situation with three mobile networks, A, B, C handled by 1025 three Mobile Routers, MR A, MR B and MR C respectively. If they 1026 register to a Home Agent in this order, the situation goes as 1027 follows: 1029 MR A registers and receives no information on other networks from HA, 1030 as no other MR has registered yet. 1032 MR B registers and receives information on mobile network A being 1033 reachable via MR A. 1035 MR C registers and receives information on both of the other mobile 1036 networks. 1038 If a node in mobile network C is about to send traffic to mobile 1039 network A, the route optimization is straightforward; MR C already 1040 has network A in its Route Optimization Cache. Thus, packet 1041 transmission triggers Route Optimization towards MR A. When MR C 1042 registers to MR A (after Return Routability procedure is completed), 1043 MR A does not have information on mobile network C; Thus it will 1044 perform a re-registration to the Home Agent on-demand. This allows 1045 MR A to verify that MR C is indeed managing network C. 1047 If a node in mobile network B sends traffic to mobile network C, MR B 1048 has no information on network C. No route optimization is triggered. 1049 However, when the node in network C replies and the reply reaches MR 1050 C, route optimization happens as above. Further examples of 1051 signaling are in Section 8. 1053 Even in the very rare case of completely unidirectional traffic from 1054 an entire network, the re-registrations to the Home Agent caused by 1055 timeouts will eventually cause convergence. However, this should be 1056 treated as a special case. 1058 Note that all Mobile Routers are connected to same Home Agent. For 1059 possibilities concerning multiple Home Agents, see Section 6.4 1061 4. Data compression schemes 1063 This section defines the two compression formats used in Route 1064 Optimization Prefix Advertisement extensions. 1066 4.1. Prefix compression 1068 The prefix-compression is based on the idea that prefixes usually 1069 share common properties. The scheme is simple delta-compression. In 1070 the prefix information advertisement, Section 5.5, the D bit 1071 indicates whether receiving a "master" or a "delta" prefix. This, 1072 combined with the Prefix Length information, allows for compression 1073 and decompression of prefix information. 1075 If D=0, what follows in the "Prefix" field are bits 1..n of the new 1076 master prefix, where n is PLen. This is rounded up to nearest full 1077 octet. Thus, prefix lengths of /4 and /8 take 1 octet, /12 and /16 1078 take 2 octets, /20 and /24 three, and larger than that full 4 octets. 1080 If D=1, what follows in the "Prefix" field are bits m..PLen of the 1081 prefix, where m is the first changed bit of previous master prefix, 1082 with padding from the master prefix filling the field to full octet. 1083 Maximum value of Plen-m is 8 (that is, delta MUST fit into one 1084 octet). If this is not possible, a new master prefix has to be 1085 declared. If the prefixes are equal, for example in the case where 1086 same prefix appears in multiple realms, then one octet is still 1087 encoded, consisting completely of padding from the master prefix. 1089 Determining the order of prefix transmission should be based on 1090 saving maximum space during transmission. 1092 Example of compression and transmitted data, where network prefixes 1093 192.0.2.0/28, 192.0.2.64/26 and 192.0.2.128/25 are transmitted are 1094 illustrated in Figure 1. Because of the padding to full octets, 1095 redundant information is also sent. The bit-patterns being 1096 transmitted are: 1098 =+= shows the prefix mask 1099 --- shows the master prefix for delta coded prefixes 1100 192.0.2.0/28, D=0 1102 0 1 2 3 1103 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 2 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0| 1106 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+ 1107 ^ ^ 1108 +---------------------------- encoded ------------------------------+ 1109 ^ ^ 1110 +-pad-+ 1111 192.0.2.64/26, D=1 1113 0 1 2 3 1114 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 2 1115 +-------------------------------------------------------------+-+-+-+-+ 1116 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0| 1117 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+ 1118 ^ ^ 1119 +--- encoded ---+ 1120 ^ ^ 1121 +-- padding --+ 1122 192.0.2.128/25, D=1 1124 0 1 2 3 1125 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 2 1126 +-------------------------------------------------------------+-+-+-+-+ 1127 |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0| 1128 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+ 1129 ^ ^ 1130 +--- encoded ---+ 1131 ^ ^ 1132 +- padding -+ 1134 Figure 1: Prefix Compression Example 1136 First prefix, 192.0.2.0/28, is considered a master prefix and is 1137 transmitted in full. The PLen of 28 bits determines that all four 1138 octets must be transmitted. If the prefix would have been e.g. 1139 192.0.2.0/24, three octets would have sufficed since 24 bits fit into 1140 3 octets. 1142 For the following prefixes, the D=1. Thus, they are deltas of the 1143 previous prefix where D was zero. 1145 192.0.2.64/26 includes bits 19-26 (full octet). Bits 19-25 are 1146 copied from master prefix, but bit 26 is changed to 1. The final 1147 notation in binary is "1001", or 0x09. 1149 192.0.2.128/25 includes bits 18-25 (full octet). Bits 18-24 are 1150 copied from master prefix, but bit 25 is changed to 1. The final 1151 notation in binary is "101", or 0x05. 1153 The final encoding thus becomes: 1155 +----------------+--------+-+---------------------+ 1156 | Prefix | Plen |D| Transmitted Prefix | 1157 +----------------+--------+-+---------------------+ 1158 | 192.0.2.0/28 | 28 |0| 0xc0 0x00 0x02 0x00 | 1159 | 192.0.2.64/26 | 26 |1| 0x09 | 1160 | 192.0.2.128/25 | 25 |1| 0x05 | 1161 +----------------+--------+-+---------------------+ 1163 It should be noted that in this case the order of prefix transmission 1164 would not affect compression efficiency. If prefix 192.0.2.128/25 1165 would have been considered the master prefix and the others as deltas 1166 instead, the resulting encoding still fits into one octet for the 1167 subsequent prefixes. There would be no need to declare a new master 1168 prefix. 1170 4.2. Realm compression 1172 4.2.1. Encoding of compressed realms 1174 In order to reduce the size of messages, the system introduces a 1175 realm compression scheme, which reduces the size of realms in a 1176 message. The compression scheme is a simple dynamically updated 1177 dictionary based algorithm, which is designed to compress arbitrary 1178 length text strings. In this scheme, an entire realm, a single label 1179 or a list of labels may be replaced with an index to a previous 1180 occurrence of the same string stored in the dictionary. The realm 1181 compression defined in this specification was inspired by the RFC 1182 1035 [RFC1035] DNS domain name label compression. Our algorithm is, 1183 however, improved to gain more compression. 1185 When compressing realms, the dictionary is first reset and does not 1186 contain a single string. The realms are processed one by one so the 1187 algorithm does not expect to see them all or the whole message at 1188 once. The state of the compressor is the current content of the 1189 dictionary. The realms are compressed label by label or as a list of 1190 labels. The dictionary can hold a maximum of 128 strings, after 1191 that, a rollover MUST occur and existing contents will be 1192 overwritten. Thus, when adding the 129th string into the dictionary, 1193 the first entry of the dictionary MUST be overwritten and the index 1194 of the new string will become 0. 1196 The encoding of an index to the dictionary or an uncompressed run of 1197 octets representing a single label has purposely been made simple and 1198 the whole encoding works on an octet granularity. The encoding of an 1199 uncompressed label takes the form of a one octet: 1201 0 1202 0 1 2 3 4 5 6 7 1203 +-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+ 1204 |0| LENGTH | 'length' octets long string.. | 1205 +-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+ 1207 This encoding allows label lengths from 1 to 127 octets. A label 1208 length of zero (0) is not allowed. The "label length" tag octet is 1209 then followed by up to 127 octets of the actual encoded label string. 1211 The index to the dictionary (the "label index" tag octet) takes the 1212 form of a one octet: 1214 0 1215 0 1 2 3 4 5 6 7 1216 +-+-+-+-+-+-+-+-+ 1217 |1| INDEX | 1218 +-+-+-+-+-+-+-+-+ 1220 The above encodings do not allow generating an output octet value of 1221 zero (0). The encapsulating Mobile IPv4 extension makes use of this 1222 property and uses the value of zero (0) to mark the end of compressed 1223 realm or to indicate an empty realm. It is also possible to encode 1224 the complete realm using only "label length" tags. In this case no 1225 compression takes place. This allows the sender to skip compression, 1226 for example to reduce computation requirements when generating 1227 messages. However, the receiver MUST always be prepared to receive 1228 compressed realms. 1230 4.2.2. Searching algorithm 1232 When compressing the input realm, the dictionary is searched for a 1233 matching string. If no match could be found, the last label is 1234 removed from the right-hand side of the used input realm. The search 1235 is repeated until the whole input realm has been processed. If no 1236 match was found at all, then the first label of the original input 1237 realm is encoded using the "label length" tag and the label is 1238 inserted into the dictionary. The previously described search is 1239 repeated with the remaining part of the input realm, if any. If 1240 nothing remains, the realm encoding is complete. 1242 When a matching string is found in the dictionary the matching part 1243 of the input realm is encoded using the "label index" tag. The 1244 matching part of the input realm is removed and the search is 1245 repeated with the remaining part of the input realm, if any. If 1246 nothing remains, the octet value of zero (0) is inserted to mark the 1247 end of encoded realm. 1249 The search algorithm also maintains the "longest non-matching string" 1250 for each input realm. Each time the search in dictionary fails and a 1251 new label gets encoded using the "label length" tag and inserted into 1252 the dictionary, the "longest non-matching string" is concatenated by 1253 this label including the separating "." (dot, i.e. Hexadecimal 1254 0x2e). When a match is found in the dictionary the "longest non- 1255 matching string" is reset (i.e. Emptied). Once the whole input 1256 realm has been processed and encoded, all possible suffixes longer 1257 than one label are taken from the string and inserted into the 1258 dictionary. 1260 4.2.3. Encoding example 1262 This section shows an example how to encode a set of realms using the 1263 specified realm compression algorithm. For example, a message might 1264 need to compress the realms "foo.example.com", "bar.foo.example.com", 1265 "buz.foo.example.org", "example.com" and "bar.example.com.org". The 1266 following example shows the processing of input realms on the left 1267 side and the contents of the dictionary on the right hand side. The 1268 example uses hexadecimal representation of numbers. 1270 COMPRESSOR: DICTIONARY: 1271 1) Input "foo.example.com" 1272 Search("foo.example.com") 1273 Search("foo.example") 1274 Search("foo") 1275 Encode(0x03,'f','o','o') 0x00 "foo" 1276 +-> "longest non-matching string" = "foo" 1277 Search("example.com") 1278 Search("example") 1279 Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example" 1280 +-> "longest non-matching string" = "foo.example" 1281 Search("com") 1282 Encode(0x03,'c','o','m') 0x02 "com" 1283 +-> "longest non-matching string" = "foo.example.com" 1284 0x03 "foo.example.com" 1285 0x04 "example.com" 1286 Encode(0x00) 1287 2) Input "bar.foo.example.com" 1288 Search("bar.foo.example.com") 1289 Search("bar.foo.example") 1290 Search("bar.foo" 1291 Search("bar") 1292 Encode(0x03,'b','a','r') 0x05 "bar" 1293 +-> "longest non-matching string" = "bar" 1294 Search("foo.example.com") -> match to 0x03 1295 Encode(0x83) 1296 +-> "longest non-matching string" = NUL 1297 Encode(0x00) 1298 3) Input "buz.foo.example.org" 1299 Search("buz.foo.example.org") 1300 Search("buz.foo.example") 1301 Search("buz.foo") 1302 Search("buz") 1303 Encode(0x03,'b','u','z') 0x06 "buz" 1304 +-> "longest non-matching string" = "buz" 1305 Search("foo.example.org") 1306 Search("foo.example") 1307 Search("foo") -> match to 0x00 1308 Encode(0x80) 1309 +-> "longest non-matching string" = NUL 1310 Search("example.org") 1311 Search("example") -> match to 0x01 1312 Encode(0x81) 1313 +-> "longest non-matching string" = NUL 1314 Search("org") 1315 Encode(0x03,'o','r','g') 0x07 "org" 1316 +-> "longest non-matching string" = "org" 1317 Encode(0x00) 1318 4) Input "example.com" 1319 Search("example.com") -> match to 0x04 1320 Encode(0x84) 1321 Encode(0x00) 1322 5) Input "bar.example.com.org" 1323 Search("bar.example.com.org") 1324 Search("bar.example.com") 1325 Search("bar.example") 1326 Search("bar") -> match to 0x05 1327 Encode(0x85) 1328 Search("example.com.org") 1329 Search("example.com") -> match to 0x04 1330 Encode(0x84) 1331 Search("org") -> match to 0x07 1332 Encode(0x87) 1333 Encode(0x00) 1335 As can be seen from the example, due the greedy approach of encoding 1336 matches, the search algorithm and the dictionary update function is 1337 not the most optimal one. However, we do not claim the algorithm 1338 would be the most efficient. It functions efficiently enough for 1339 most inputs. In this example, the original input realm data was 79 1340 octets and the compressed output excluding the end mark is 35 octets. 1342 5. New Mobile IPv4 messages and extensions 1344 This section describes the construction of all new information 1345 elements. 1347 5.1. Mobile Router Route Optimization capability 1349 This skippable extension MAY be sent by a Mobile Router to a Home 1350 Agent in the registration request message. 1352 0 1 2 3 1353 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 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Type | Length | Sub-type |A|R|S|O| Rsvd | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 ~ Optional Mobile Router HoA ~ 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 Type TBA_T1. Skippable; If Home Agent does not support route 1361 optimization advertisements, it can ignore this request and 1362 simply not include any information in the reply. "Short" 1363 extension format. 1365 Sub_Type 1 1367 Reserved Set to zero, MUST be ignored on reception. 1369 A Advertise my networks. If 'A' bit is set, the Home Agent 1370 is allowed to advertise the networks managed by this Mobile 1371 Router to other Mobile Routers. This also indicates that 1372 the Mobile Router is capable of receiving route 1373 optimization registration requests. In effect, this allows 1374 the Mobile Router to work in Correspondent Router role. 1376 R Request mobile network information. If 'R' bit is set, the 1377 Home Agent MAY respond with information about mobile 1378 networks in the same domain. 1380 S Soliciting prefixes managed by a specific Mobile Router. 1381 The Mobile Router is specified in the Optional Mobile 1382 Router HoA field. 1384 O Explicitly specifying the requesting Router is only able to 1385 initiate outgoing connections, not accept any incoming 1386 ones, due to NAT device, stateful firewall, or similar 1387 issue on any interface. This is reflected by the Home 1388 Agent in the reply, and distributed in Prefix 1389 Advertisements to other Mobile Routers. 1391 Optional Mobile Router HoA 1393 Solicited Mobile Router's Home Address. This field is only 1394 included if flag 'S' is set. 1396 5.2. Route optimization reply 1398 This non-skippable extension MUST be sent by a Home Agent to a Mobile 1399 Router in the registration reply message, if Mobile Router indicated 1400 support for Route Optimization in registration message and Home Agent 1401 supports Route Optimization. 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Type | Length | Sub-Type |O|N|S| Code | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 Type TBA_T2 (Non-skippable), "short" extension format 1411 Sub-Type 1 1413 O The 'O' flag in Mobile Router Route Optimization capability 1414 extension was set during registration. 1416 N Presence of NAT was detected by Home Agent. This informs 1417 the Mobile Router that it is located behind NAT. The 1418 detection procedure is specified in RFC 3519 [RFC3519], and 1419 is based on the discrepancy between registration packet's 1420 source address and indicated Care-of Address. The Mobile 1421 Router can use this information to make decisions about 1422 Route Optimization strategy. 1424 S Responding to a solicitation. If 'S' bit was present in 1425 Mobile router Route optimization capability extension 1426 (Section 5.1), this is set, otherwise unset. 1428 The Reply code indicates whether Route Optimization has been 1429 accepted. Values of 0..15 indicate assent and values 16..63 indicate 1430 Route Optimization is not done. 1432 0 Will do Route Optimization 1434 16 Route Optimization declined, reason unspecified. 1436 5.3. Mobile-Correspondent authentication extension 1438 Mobile-Correspondent authentication extension is included in 1439 registration requests sent from Mobile Router to Correspondent 1440 Router. The existence of this extension indicates that the message 1441 is not destined to a Home Agent, but another Mobile Router. The 1442 format is similar to the other Authentication Extensions defined in 1443 [RFC5944], with SPIs replaced by Nonce Indexes. 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Type | Length | Sub-Type | Reserved | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Home Nonce Index | Care-of Nonce Index | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Authenticator... ~ 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 The Home Nonce Index field tells the Correspondent Router which nonce 1456 value to use when producing the home keygen token. The Care-of Nonce 1457 Index field is ignored in requests to remove a binding. Otherwise, 1458 it tells the Correspondent Router which nonce value to use when 1459 producing the Care-of Keygen Token. 1461 Type TBA_T2 (non-skippable). "Short" extension format. 1463 Sub-Type 2 1465 Reserved Set to zero, MUST be ignored on reception. 1467 Home Nonce Index 1469 Home Nonce Index in use. 1471 Care-of Nonce Index 1473 Care-of Index in use. 1475 Authenticator 1477 Authenticator field, by default constructed with First(128, 1478 HMAC_SHA1 (KRm, Protected Data)) 1480 The protected data, just like on other cases where Authenticator is 1481 used, consists of 1483 o the UDP payload (i.e., the Registration Request or Registration 1484 Reply data), 1486 o all prior Extensions in their entirety, and 1488 o the Type, Length, and Nonce Indexes of this Extension. 1490 5.4. Care-of address Extension 1492 The Care-of Address extension is added to a registration reply sent 1493 by the Correspondent Router to inform the Mobile Router of the 1494 upcoming tunnel endpoint. 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Type | Length | Sub-type | Reserved | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 1..n Times the following information structure 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Care-of Address | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 Type TBA_T2 (Non-skippable), "short" extension format 1507 Length Total length of the packet. When processing the 1508 information structures, if Length octets have been reached, 1509 this is an indication that the final information structure 1510 was reached as well. 1512 Sub-Type 3 1514 Care-of Address 1516 Care-of address(es) which may be used for tunnel with 1517 Mobile Router, in order of priority. Multiple CoA's MAY be 1518 listed to facilitate faster NAT traversal. 1520 5.5. Route optimization prefix advertisement 1522 This non-skippable extension MAY be sent by a Home Agent to a Mobile 1523 Router in the registration reply message. The extension is only 1524 included when explicitly requested by the Mobile Router in the 1525 registration request message, setting 'R'-flag of the Mobile Router 1526 Route Optimization capability extension. Implicit prioritization of 1527 prefixes is caused by the order of extensions. 1529 The extension contains a sequence of information structures. An 1530 information structure may consist of either an MR HoA or a network 1531 prefix. Any network prefixes following an MR HoA are owned by that 1532 MR. An MR HoA MUST be first in sequence, since you cannot have 1533 prefixes without an MR. 1535 0 1 2 3 1536 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 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Type | Sub-type | Length | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 1..n times the following information structure 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 |D|M| Plen/Info | Optional Mobile Router HoA, 4 octets ~ 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 ~ | Optional Prefix, 1,2,3 or 4 octets ~ 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 ~ Realm (1..n characters) ~ 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 Type TBA_T3 (Non-skippable), "long" extension format 1551 Sub-Type 1 1553 Length Total length of the packet. When processing the 1554 information structures, if Length octets have been reached, 1555 this is an indication that the final information structure 1556 was reached as well. 1558 D Delta. If D=1, the prefix is a delta from last Prefix 1559 where D=0. MUST be zero on first information structure, 1560 MAY be zero or one on subsequent information structures. 1561 If D=1, the Prefix field is one octet in length. See 1562 Section 4.1 for details. 1564 M Mobile Router HoA bit. If M=1, the next field is Mobile 1565 Router HoA, and Prefix and Realm are omitted. If M=0, the 1566 next field is Prefix followed by Realm, and Mobile Router 1567 HoA is omitted. For the first information structure, M 1568 MUST be set to 1. If M=1, the D bit is set to zero and 1569 ignored upon reception. 1571 PLen/Info This field is interpreted differently depending on whether 1572 M is set or not. If M=0, this indicates the length of the 1573 prefix advertised. 6 bits, allows for values from 0 to 63, 1574 of which 33-63 are illegal. If M=1, the Information field 1575 can be set to zero to indicate no specific information, or 1576 to 1 to indicate "outbound connections only". This 1577 indicates that the target Mobile Router can only initiate, 1578 not receive, connections on any of it's interfaces (apart 1579 from the reverse tunnel to HA). This is set if the Mobile 1580 Router has explicitly requested it by the 'O' flag in 1581 Mobile router Route optimization capability extension 1582 (Section 5.1). 1584 Mobile router HoA 1586 Mobile Router's Home address. All prefixes in the 1587 following information structures where M=0 are maintained 1588 by this Mobile Router. This field is present only when M = 1589 1. 1591 Prefix The IPv4 prefix advertised. If D=0, the field length is 1592 Plen bits, rounded up to nearest full octet. Least- 1593 significant bits starting off Plen (and are zeros) are 1594 omitted. If D=1, field length is one octet. This field is 1595 present only when M = 0. 1597 Realm The Realm that is associated with the advertised Mobile 1598 Router HoA and prefix. If empty, MUST be set to '\0'. For 1599 realm encoding and optional compression scheme, refer to 1600 Section 4.2. This field is present only when M = 0. 1602 5.6. Home-Test Init message 1604 This message is sent from Mobile Router to Correspondent Router when 1605 performing Return Routability procedure. The source and destination 1606 IP addresses are set to MR's Home Address and CR's Home Address, 1607 respectively. The UDP source port MAY be randomly chosen. The UDP 1608 destination port is 434. 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Type | Reserved | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1614 | Home Init Cookie | 1615 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 Type TBA_MIP1 1621 Reserved Set to zero, MUST be ignored on reception. 1623 Home Init Cookie 1625 64-bit field which contains a random value, the Home Init 1626 Cookie. 1628 5.7. Care-of-Test Init message 1630 This message is sent from Mobile Router to Correspondent Router when 1631 performing Return Routability procedure. The source and destination 1632 IP addresses are set to MR's Care-of-Address and CR's Home Address, 1633 respectively. The UDP source port MAY be randomly chosen. The UDP 1634 destination port is 434. 1635 0 1 2 3 1636 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 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Type | Reserved | | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1640 | Care-of Init Cookie | 1641 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 Type TBA_MIP2 1647 Reserved Set to zero, MUST be ignored on reception. 1649 Care-of Init Cookie 1651 64-bit field which contains a random value, the Care-of 1652 Init Cookie. 1654 5.8. Home Test message 1656 This message is sent from Correspondent Router to Mobile Router when 1657 performing Return Routability procedure as a reply to Home-Test Init 1658 message. The source and destination IP addresses, as well as UDP 1659 ports, are reversed from the Home-Test Init message the message is 1660 constructed for. As such, the UDP source port is always 434. 1662 0 1 2 3 1663 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 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Type | Reserved | Nonce Index | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | | 1668 + Home Init Cookie + 1669 | | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | | 1672 + Home Keygen Token + 1673 | | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 Type TBA_MIP3 1678 Reserved Set to zero, MUST be ignored on reception. 1680 Nonce Index 1682 This field will be echoed back by the Mobile Router to the 1683 Correspondent Router in a subsequent registration request's 1684 authentication extension. 1686 Home Init Cookie 1688 64-bit field which contains a random value, the Home Init 1689 Cookie. 1691 Home Keygen Token 1693 This field contains the 64 bit home keygen token used in 1694 the Return Routability procedure. Generated from cookie + 1695 nonce. 1697 5.9. Care-of test message 1699 This message is sent from Correspondent Router to Mobile Router when 1700 performing Return Routability procedure as a reply to Care-of-test 1701 Init message. The source and destination IP addresses, as well as 1702 UDP ports, are reversed from the Care-of-test Init message the 1703 message is constructed for. As such, the UDP source port is always 1704 434. 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Type | Reserved | Nonce Index | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | | 1712 + Care-of Init Cookie + 1713 | | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | | 1716 + Care-of Keygen Token + 1717 | | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 Type TBA_MIP4 1722 Reserved Set to zero, MUST be ignored on reception. 1724 Care-of Nonce Index 1726 This field will be echoed back by the Mobile Router to the 1727 Correspondent Router in a subsequent registration requests' 1728 authentication extension. 1730 Care-of Init Cookie 1732 64-bit field which contains a random value, the Home Init 1733 Cookie. 1735 Care-of Keygen Token 1737 This field contains the 64 bit home keygen token used in 1738 the Return Routability procedure. Generated from cookie + 1739 nonce. 1741 6. Special Considerations 1743 6.1. NATs and stateful firewalls 1745 Mechanisms described in MIP NAT traversal [RFC3519] allow the Home 1746 Agent to work with Mobile Routers situated behind a NAT device or a 1747 stateful firewall. Furthermore, the Home Agent may also detect 1748 whether NAT device is located between the Mobile Node and the HA. 1749 Mobile Router may also explicitly state it is behind a NAT or 1750 firewall on all interfaces, and this information is passed on to the 1751 other Mobile Routers with the information field in Route optimization 1752 prefix advertisement extension (Section 5.5). Home Agent may also 1753 detect presence of NAT and informs the registering Mobile Router with 1754 the 'N' flag in Route Optimization Reply extension (Section 5.2). In 1755 the case of one or both of the routers is known to be behind NAT or 1756 similarly impaired (not being able to accept incoming connections), 1757 the tunnel establishment procedure needs to take this into account. 1759 In the case where Mobile Router is behind NAT (or firewall) and 1760 Correspondent Router is not, the Mobile Router will, when tunnel has 1761 been established, send keepalive messages (ICMP echo requests) 1762 through the tunnel. Until a reply has been received, the tunnel 1763 SHOULD NOT be considered active. Once reply has been received, NAT 1764 mapping is in place and traffic can be sent. 1766 Source address may change due to NAT in CoTI and Registration Request 1767 messages. This does not affect the process - the hash values are 1768 calculated by the translated address, and the Registration Request 1769 will also appear from the same translated address. 1771 Unlike in communication with the Home Agent, in the case of Route 1772 Optimization the path used for signaling is not used for tunneled 1773 packets, as signaling always uses Home Addresses, and MR <-> CR 1774 tunnel is from CoA to CoA. It is assumed that even though port 1775 numbers may change, NAT processing rarely allocates more than one 1776 external IP address to a single internal address, thus the IP address 1777 seen in the Registration Request and Tunnel packets remains the same. 1778 However, the UDP source port number may be different in Registration 1779 Request and incoming tunnel packets due to port translation. This 1780 must not cause an error situation - the Correspondent Router MUST be 1781 able to accept tunneling packets from a different UDP source port 1782 than what was used in the Registration Request. 1784 Since Mobile Routers may have multiple interfaces connecting to 1785 several different networks, it might be possible that specific Mobile 1786 Routers may only be able to perform Route Optimization using specific 1787 Care-of-address pairs, obtained from specific networks, for example 1788 in a case where two Mobile Routers have an interface behind same NAT. 1789 Similar case may be applicable to nested NATs. In such cases, Mobile 1790 Router MAY attempt to detect eligible Care-of-Address pairs by 1791 performing a registration and attempting to establish a tunnel 1792 (sending keepalives) with each Care-of-Address listed in the 1793 Registration Reply's Care-of-Address extension. The eligible pairs 1794 should be recorded in Route Optimization cache. If tunnel cannot be 1795 established with any CoA's, the Mobile Router MAY attempt to repeat 1796 the procedure with alternative interfaces. The above information on 1797 network topology can also be configured to the Mobile Routers either 1798 statically or via some external feedback mechanism. 1800 If both the Mobile Router and the Correspondent Router are behind two 1801 separate NATs, some sort of proxy or hole-punching technique may be 1802 applicable. This is out of scope of this document. 1804 6.2. Handling of concurrent handovers 1806 If both Mobile Router and Correspondent Router move at the same time, 1807 this causes no issues from signaling perspective, as all requests are 1808 always sent from a Care-of-Address to Home Addresses. Thus, the 1809 recipient will always receive the request and can send the reply. 1810 This applies even in break-before-make situations where both MR and 1811 CR get disconnected at same time - once the connectivity is restored, 1812 one end-point of the signaling messages is always the Home Address of 1813 respective router, and it is up to the Home Agent to provide 1814 reachability. 1816 6.3. Foreign Agents 1818 Since Foreign Agents have been dropped from Network Mobility for 1819 Mobile IPv4 work, they are not considered here. 1821 6.4. Multiple Home Agents 1823 Mobile Routers can negotiate and perform route optimization without 1824 the assistance of Home Agent - if they can discover each others 1825 existence and thus know where to send registration messages. This 1826 document only addresses a logically single Home Agent that 1827 distributes network prefix information to the Mobile Routers. 1828 Problems arise from possible trust relationships; In this document 1829 the Home Agent serves as a way to provide verification that a 1830 specific network is managed by a specific router. 1832 If Route Optimization is desired between nodes attached to separate 1833 Home Agents, there are several possibilities. Note that standard 1834 high availability redundancy protocols, such as VRRP, can be 1835 utilized; However, in such case the Home Agent is still a single 1836 logical entity even if consisting of more than a single node. 1838 Several possibilities exist for achieving Route Optimization between 1839 Mobile Routers attached to separate Home Agents, such as a new 1840 discovery/probing protocol, routing protocol between Home Agents or 1841 DNS SRV records, or a common AAA architecture. There already is a 1842 framework for HA to retrieve information from AAA so it can be 1843 considered as the most viable possibility. See Section 6.6 for 1844 information on possibility to generalize the method. 1846 Any discovery/probing protocols are out of scope for this document. 1848 6.5. Mutualness of Route Optimization 1850 The procedure as specified is asymmetric; That is, if bidirectional 1851 route optimization is desired while maintaining consistency, the 1852 route optimization (RR check and registration) has to be performed in 1853 both directions, but this is not strictly necessary. This is 1854 primarily a policy decision depending on how often the mobile 1855 prefixes are reconfigured. 1857 Consider the case where two networks, A and B, are handled by Mobile 1858 Routers A and B respectively. If the routers are set up in such a 1859 fashion that Route Optimization is triggered when a packet is 1860 received from a Network Prefix in Route Optimization Cache, the 1861 following occurs if a node in network A starts sending ICMP echo 1862 requests (pinging) a node in network B. 1864 MR B sees the incoming ICMP echo request packet, which is travelling 1865 inside the reverse tunnel to the Home Agent. MR B sees that the 1866 destination is in network B, and furthermore, source is in network A 1867 which exists in the cache. This triggers Route Optimization 1868 processing. Until RO is active, the ping packets (echo requests and 1869 replies) are routed via the reverse tunnel. 1871 MR B completes RR procedure and registration with MR A, which thus 1872 becomes a Correspondent Router for MR B. A tunnel is created between 1873 the routers. MR A updates its routing tables so that network B is 1874 reachable via MR A <-> MR B tunnel. 1876 The traffic pattern is now that packets from network B to network A 1877 are sent over the direct tunnel, but the packets from A to B are 1878 transmitted via the Home Agent and reverse tunnels. MR A now 1879 performs its own registration towards MR B. Upon completion, MR A 1880 notices that a tunnel to MR B already exists, but updates its routing 1881 table so that network B is now reachable via the MR A <-> MR B 1882 tunnel. From this point onward, traffic is bidirectional. 1884 In this scenario, if MR A does NOT perform a separate route 1885 optimization (RR check and registration), but instead simply updates 1886 its routing table to reach network B via the tunnel, problems may 1887 arise if MR B has started to manage another network B' before the 1888 information has propagated to MR A. The end result is that MR B 1889 starts to receive packets for network B' via the Home Agent and for 1890 network B via direct tunnel. If Reverse Path checking or similar 1891 mechanism is in use on MR B, packets from network A could be black 1892 holed. 1894 Whether to perform this mutual registration or not thus depends on 1895 the situation, and whether Mobile Routers are going to start managing 1896 additional Network Prefixes during operation. 1898 6.6. Extensibility 1900 The design considerations include several mechanisms which might not 1901 be strictly necessary if Route Optimization would only be desired 1902 between individual customer sites in a managed network. The 1903 registration procedure (with the optional Return Routability part), 1904 which allows for Correspondent Routers to learn Mobile Router's 1905 Care-of Addresses is not strictly necessary; The CoA's could have 1906 been provided by HA directly. 1908 However, this approach allows the method to be extended to a more 1909 generic route optimization. The primary driver for having Home Agent 1910 to work as a centralized information distributer is to provide Mobile 1911 Routers with the knowledge of not only the other routers, but to 1912 provide information on which networks are managed by which routers. 1914 The Home Agent provides the information on all feasible nodes with 1915 which it is possible to establish Route Optimization. If 1916 representing a whole Mobile Network is not necessary, in effect the 1917 typical Mobile Node <-> Correspondent Node situation, the mechanisms 1918 in this document work just as well - only problem is discovering if 1919 the target Correspondent Node can provide Route Optimization 1920 capability. This can be performed by not including any prefixes in 1921 the information extension, just the HoA address of Mobile Router. 1923 In addition, with Route Optimization for single node, checks on 1924 whether a Mobile Router is allowed to represent specific networks are 1925 unnecessary since there are none. 1927 Correspondent node/router discovery protocols (whether they are based 1928 on probing or a centralized directory beyond the single Home Agent) 1929 are outside the scope of this document. 1931 6.7. Load Balancing 1933 The design simply provides possibility to create optimal paths 1934 between Mobile Routers; It doesn't dictate what should be the user 1935 traffic using these paths. One possible approach in helping 1936 facilitate load balancing and utilizing all available paths is 1937 presented in [I-D.ietf-mip4-multiple-tunnel-support], which 1938 effectively allows for multiple Care-of addresses for a single Home 1939 Address. In addition, per-tunnel load balancing is possible by using 1940 separate Care-of-Addresses for separate tunnels. 1942 7. Scalability 1944 Home Agent assisted Route Optimization scalability issues stem from 1945 the general Mobile IPv4 architecture which is based on tunnels. 1946 Creating, maintaining and destroying tunnel interfaces can cause load 1947 on the Mobile Routers. However, the MRs can always fall back to 1948 normal, reverse tunnelled routing if resource constraints are 1949 apparent. 1951 If there is a large number of optimization-capable prefixes, 1952 maintaining state for all of these may be an issue also, due to 1953 limits on routing table sizes. 1955 Registration responses from Home Agent to Mobile Router may provide 1956 information on large number of network prefixes. If thousands of 1957 networks are involved, the registration reply messages are bound to 1958 grow very large. The prefix- and realm compression mechanisms 1959 defined in Section 4 mitigates this problem to an extent. There 1960 will, however, be some practical upper limit after which point some 1961 other delivery mechanism for the prefix information will be needed. 1963 8. Example signaling scenarios 1965 8.1. Registration request 1967 The following example signaling assumes that there are three Mobile 1968 Routers, MR A, B, C, each managing network prefixes A, B, and C. At 1969 the beginning, no networks are registered to the Home Agent. Any AAA 1970 processing at the Home Agent is omitted from the diagram. 1972 +--------+ +--------+ +--------+ +--------------+ 1973 | [MR A] | | [MR B] | | [MR C] | | [Home Agent] | 1974 +--------+ +--------+ +--------+ +--------------+ 1975 | | | | 1976 x------------------------------->| Registration request, 1977 | | | | includes Mobile Router 1978 | | | | route optimization 1979 | | | | capability extension 1980 | | | | 1981 |<-------------------------------x Registration response, 1982 | | | | no known networks from HA 1983 | | | | in response 1984 | | | | 1985 | x-------------------->| Registration request, similar 1986 | | | | to the one sent by MR A 1987 | | | | 1988 | |<--------------------x Registration reply, includes 1989 | | | | network A in route optimization 1990 | | | | prefix advertisement extension 1991 | | | | 1992 | | x--------->| Registration request, similar 1993 | | | | the one sent by MR A 1994 | | | | 1995 | | |<---------x Registration reply, includes 1996 | | | | networks A and B in route 1997 | | | | optimization prefix 1998 | | | | advertisement extension. 1999 | | | | Network B is sent in 2000 | | | | compressed form. 2001 | | | | 2003 8.2. Route optimization with return routability 2005 The following example signaling has same network setup as in 2006 Section 8.1 - Three mobile routers, each corresponding to their 2007 respective network. Node A is in network A and Node C is in network 2008 C. 2010 At the beginning, no mobile routers know KRm's of each other. If the 2011 KRm's would be pre-shared or provisioned with some other method, the 2012 Return Routability messages can be omitted. Signaling in Section 8.1 2013 has occurred, thus MR A is not aware of the other networks, and MR C 2014 is aware of networks A and B. 2016 ======= Traffic inside Mobile IP tunnel to/from HA 2017 =-=-=-= Traffic inside Mobile IP tunnel between MRs 2018 ------- Traffic outside Mobile IP tunnel 2020 +----------+ +--------+ +------+ +--------+ +----------+ 2021 | [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] | 2022 +----------+ +--------+ +------+ +--------+ +----------+ 2023 | | | | | 2024 x------------O==========O=========O------>| Mobile Router A is 2025 | | | | | unaware of network C, 2026 | | | | | thus, nothing happens 2027 | | | | | 2028 |<-----------O==========O=========O-------x Mobile Router C 2029 | | | | | notices packet to 2030 | | | | | Net A - begins RO 2031 | | | | | 2032 | | | | | Return Routability 2033 | | | | | (If no preshared KRms) 2034 | | | | | 2035 | |<=========O---------x | CoTI 2036 | |<=========O=========x | HoTI 2037 | | | | | 2038 | x==========O-------->| | CoT 2039 | x==========O========>| | HoT 2040 | | | | | 2041 | | | | | KRm between MR A <-> C 2042 | | | | | established 2043 | | | | | 2044 | |<=========O---------x | Registration request 2045 | | | | | 2046 | x--------->| | | Registration request 2047 | | | | | to HA due to MR A 2048 | | | | | being unaware of 2049 | | | | | network C. 2050 | | | | | Solicit bit set. 2051 | | | | | 2052 | |<---------x | | Registration reply, 2053 | | | | | contains info on Net A 2054 | | | | | 2055 | x==========O-------->| | Registration reply, 2056 | | | | | includes MR A's CoA in 2057 | | | | | Care-of-Address 2058 | | | | | extension 2059 | | | | | 2060 | |<= = = = =O= = = ==>| | Optional mutual registration 2061 | | | | | from MR A to MR C (same 2062 | | | | | procedure as above, 2063 | | | | | multiple packets), 2064 | | | | | possible keepalive checks 2065 | | | | | 2066 |<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A 2067 | | | | | routed to direct tunnel 2068 | | | | | at MR C, based on 2069 | | | | | MR C now knowing MR A's 2070 | | | | | CoA and tunnel being up 2071 | | | | | 2072 x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C 2073 | | | | | routed to direct tunnel 2074 | | | | | at MR A, based on MR A 2075 | | | | | now knowing MR C's CoA 2076 | | | | | and tunnel being up 2078 8.3. Handovers 2080 In this example signaling, MR C changes care-of address while Route 2081 Optimization between MR A is operating and data is being transferred. 2082 Both cases where the handover is graceful ("make before break") and 2083 ungraceful ("break before make") occur in similar fashion, except in 2084 the graceful version no packets get lost. This diagram considers the 2085 case where MR C gets immediate notification of lost connectivity e.g. 2086 due to link status indication. MR A would eventually notice the 2087 breakdown due to keepalive messages failing. 2088 ======= Traffic inside Mobile IP tunnel to/from HA 2089 =-=-=-= Traffic inside Mobile IP tunnel between MRs 2090 ------- Traffic outside Mobile IP tunnel 2092 +----------+ +--------+ +------+ +--------+ +----------+ 2093 | [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] | 2094 +----------+ +--------+ +------+ +--------+ +----------+ 2095 | | | | | 2096 x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C 2097 |<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic 2098 | | | | | 2099 | | xxxxxxxxxxx | Break occurs: MR C 2100 | | | | | loses connectivity to 2101 | | | | | current attachment point 2102 | | | | | 2103 x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C 2104 | | | | | lost and 2105 | | | x<=-=-O-------x vice versa 2106 | | | | | 2107 | | |<--------x | MR C finds a new 2108 | | | | | point of attachment, 2109 | | | | | registers to HA, clears 2110 | | | | | routing tables 2111 | | | | | 2112 | | x-------->| | Registration reply 2113 | | | | | 2114 x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C 2115 | | | | | lost (reverts to routing 2116 | | | | | via HA if enough keepalives 2117 | | | | | fail) 2118 | | | | | 2119 |<-----------O==========O=========O-------| Traffic from C -> A 2120 | | | | | sent via HA 2121 | | | | | 2122 | O<=========O---------x | CoTI message 2123 | | | | | (partial RR check) 2124 | | | | | 2125 | x==========O-------->| | CoT message 2126 | | | | | 2127 | |<=========O---------x | Registration request, 2128 | | | | | reusing newly calculated KRm 2129 | | | | | 2130 | x==========O-------->| | Registration reply 2131 | | | | | 2132 | O<=-=-=-=-=-=-=-=-=-=x | First keepalive check if using 2133 | | | | | UDP encapsulation, also 2134 | x=-=-=-=-=-=-=-=-=-=>| | creates holes in firewalls 2135 | | | | | 2136 | | | | | 2137 x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C 2138 | | | | | forwarded directly again 2139 | | | | | 2140 |<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A 2141 | | | | | switches back to direct 2142 | | | | | tunnel 2143 | | | | | 2145 9. Protocol constants 2146 MAX_NONCE_LIFETIME 240 seconds 2147 MAX_TOKEN_LIFETIME 210 seconds 2148 MAX_UPDATE_RATE 5 times 2150 10. IANA Considerations 2152 IANA has assigned rules for the existing registries "Mobile IP 2153 Message Types" and "Extensions to Mobile IP Registration Messages", 2154 specified in RFC 5944 [RFC5944]. New Mobile IP message types and 2155 extension code allocations are needed for the messages and extensions 2156 listed in section 5. 2158 The Route Optimization authentication processing requires four new 2159 message type numbers. The new Mobile IP Message types are listed 2160 below, in Table 1. They should preferably be allocated from a 2161 contiguous range. 2163 +----------+---------------------------+ 2164 | Value | Name | 2165 +----------+---------------------------+ 2166 | TBA_MIP1 | Home-Test Init message | 2167 | TBA_MIP2 | Care-of-Test Init message | 2168 | TBA_MIP3 | Home Test message | 2169 | TBA_MIP4 | Care-of Test message | 2170 +----------+---------------------------+ 2172 Table 1: New Values for Mobile IP Message types 2174 Three new registration message extension types are required and 2175 listed in Table 2. The first type, TBA_T1 is skippable and should be 2176 allocated from range 128-255. The other two, TBA_T2 and TBA_T3 are 2177 non-skippable and should be allocated from range 0-127, TBA_T2 being 2178 of the "short" format and TBA_T3 being of the "long" format. None of 2179 the messages are permitted for notification messages. 2181 +-----------------+---------------------------------------------+ 2182 | Value | Name | 2183 +-----------------+---------------------------------------------+ 2184 | TBA_T1, 128-255 | Mobile router Route optimization indication | 2185 | TBA_T2, 0-127 | Route Optimization Extensions | 2186 | TBA_T3, 0-127 | Route Optimization data | 2187 +-----------------+---------------------------------------------+ 2189 Table 2: New Values and Names for Extensions in Mobile IP 2190 Registration messages 2192 In addition, the registry "Code Values for Mobile IP Registration 2193 Reply Messages" needs to be modified. A new success code, TBA_S1, 2194 should be allocated as follows: 2196 TBA_S1 Concurrent registration (pre-accept) 2198 In addition, a new allocation range needs to be created as "Error 2199 Codes from the Correspondent Node", subject to policy of Expert 2200 Review [RFC5226]. Suggested range is 201-210. Three new 2201 registration reply codes are to be allocated from this range. They 2202 are specified in Table 3, below: 2204 +--------+-----------------------------+ 2205 | Value | Name | 2206 +--------+-----------------------------+ 2207 | TBA_C1 | Expired Home nonce Index | 2208 | TBA_C2 | Expired Care-of nonce Index | 2209 | TBA_C3 | Expired nonces | 2210 +--------+-----------------------------+ 2212 Table 3: New Values for Code Values for Mobile IP Registration Reply 2213 Messages 2215 Three new number spaces are required for the subtypes of the 2216 extensions in Table 2. A new registry, named "Route Optimization 2217 Types and Subtypes" is created with an allocation policy of RFC 2218 Required [RFC5226]. The registration entries include Type, Subtype 2219 and Name. Type and Subtype have range of 0-255. Types are 2220 references to registration message extension types. Subtypes are 2221 allocated initially as in Table 4, below: 2223 +--------+---------+-----------------------------------------------+ 2224 | Type | Subtype | Name | 2225 +--------+---------+-----------------------------------------------+ 2226 | TBA_T1 | 0 | Reserved | 2227 | TBA_T1 | 1 | Mobile router Route optimization capability | 2228 | TBA_T2 | 0 | Reserved | 2229 | TBA_T2 | 1 | Route optimization reply | 2230 | TBA_T2 | 2 | Mobile-Correspondent authentication extension | 2231 | TBA_T2 | 3 | Care-of address extension | 2232 | TBA_T3 | 0 | Reserved | 2233 | TBA_T3 | 1 | Route optimization prefix advertisement | 2234 +--------+---------+-----------------------------------------------+ 2236 Table 4: Initial Values and Names for registry Route Optimization 2237 Types and Subtypes 2239 11. Security Considerations 2241 There are two primary security issues: Other relates to return 2242 routability check, which establishes that a specific Care-of address 2243 is, indeed, managed by a specific Home Address. Other issue is trust 2244 relationships and arbitrary router claiming to represent arbitrary 2245 network. 2247 The end-user traffic can be protected using normal IPSec mechanisms. 2249 11.1. Return Routability 2251 The Return Routability check's security has been vetted with Mobile 2252 IPv6. There are no large differences apart from requiring a separate 2253 ICMP message for connectivity check, and replay attack protection, 2254 which in this case uses Mobile IPv4 timestamps in registration 2255 request's identification field instead of sequence numbers. 2257 The Return Routability procedure does not establish any kind of state 2258 information on the Correspondent router, mitigating Denial of Service 2259 attacks. State information is only maintained after a Registration 2260 request has been accepted. 2262 11.2. Trust relationships 2264 The network of trust relationships in Home Agent assisted Route 2265 Optimization solve the issues where arbitrary Correspondent Router 2266 can trust an arbitrary Mobile Router that it is indeed the proper 2267 route to reach an arbitrary mobile network. 2269 It is assumed that all Mobile Routers have a trust relationship with 2270 the Home Agent. Thus, they trust information provided by Home Agent. 2272 The Home Agent provides information matching Home Addresses and 2273 network prefixes. Each Mobile Router trusts this information. 2275 Mobile Routers may perform Return Routability procedure between each 2276 other. This creates a trusted association between Mobile Router Home 2277 Address and Care-of Address. The Mobile Router also claims to 2278 represent a specific network. This information is not trustworthy as 2279 such. 2281 The claim can be verified by checking the Home Address <-> network 2282 prefix information received, either earlier, or due to on-demand 2283 request, from the Home Agent. If they match, the Mobile Router's 2284 claim is authentic. If the network is considered trusted, a policy 2285 decision can be made to skip this check. Exact definitions on 2286 situations where such decision can be made are out of scope of this 2287 document. The RECOMMENDED general practice is to perform the check. 2289 12. Acknowledgements 2291 Thanks to Alexandru Petrescu for constructive comments and support. 2292 Thanks to Jyrki Soini and Kari Laihonen for initial reviews.This work 2293 was supported by TEKES as part of the Future Internet program of 2294 TIVIT (Finnish Strategic Centre for Science, Technology and 2295 Innovation in the field of ICT). 2297 13. References 2299 13.1. Normative References 2301 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2302 October 1996. 2304 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2305 October 1996. 2307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2308 Requirement Levels", BCP 14, RFC 2119, March 1997. 2310 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2311 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2312 March 2000. 2314 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 2315 Network Address Translation (NAT) Devices", RFC 3519, 2316 April 2003. 2318 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 2319 "Network Mobility (NEMO) Extensions for Mobile IPv4", 2320 RFC 5177, April 2008. 2322 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2323 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2324 May 2008. 2326 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 2327 RFC 5944, November 2010. 2329 13.2. Informative References 2331 [I-D.ietf-mip4-multiple-tunnel-support] 2332 Gundavelli, S., Leung, K., Tsirtsis, G., Soliman, H., and 2333 A. Petrescu, "Flow Binding Support for Mobile IPv4", 2334 draft-ietf-mip4-multiple-tunnel-support-02 (work in 2335 progress), August 2011. 2337 [I-D.ietf-mobileip-optim] 2338 Perkins, C. and D. Johnson, "Route Optimization in Mobile 2339 IP", September 2001. 2341 [RFC1035] Mockapetris, P., "Domain names - implementation and 2342 specification", STD 13, RFC 1035, November 1987. 2344 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 2345 Mobile IPv4", RFC 3543, August 2003. 2347 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2348 in IPv6", RFC 3775, June 2004. 2350 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2351 Requirements for Security", BCP 106, RFC 4086, June 2005. 2353 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2354 Network Access Identifier", RFC 4282, December 2005. 2356 Authors' Addresses 2358 Antti Makela 2359 Aalto University, Department of Communications and Networking (Comnet) 2360 P.O. BOX 13000 2361 FIN-00076 Aalto 2362 FINLAND 2364 Email: antti.makela@aalto.fi 2366 Jouni Korhonen 2367 Nokia Siemens Networks 2368 Linnoitustie 6 2369 FI-02600 Espoo 2370 FINLAND 2372 Email: jouni.nospam@gmail.com