idnits 2.17.1 draft-soliman-mobileip-hmipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '...lternatively, the MN MAY choose to use...' RFC 2119 keyword, line 180: '...ntation of MIPv6 MAY choose to use the...' RFC 2119 keyword, line 240: '... MAP domain MUST advertise the MAP's...' RFC 2119 keyword, line 253: '..., if the MN is MAP-aware it MAY choose...' RFC 2119 keyword, line 259: '...the BU is the RCOA. The MAP MUST store...' (43 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A MN SHOULD register with the MAP having the lowest preference value. A MAP with a preference value of 255 SHOULD not be used in the MAP registration. A MN MAY however choose to register with one MAP rather than another depending on the value received in the Distance field, as long as the preference value is below 255. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If no MAP options are found in the router advertisement, the MN MUST use the MIPv6 protocol as specified in [1]. If the MN receives a duplicated MAP option ( having the same IP address or prefix) with different preference values or Distance values, the MAP IP address SHOULD not be used as an Alternate-COA in any BU's sent by the MN. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: After MAP discovery has taken place, a MN can register with one or more MAPs. The MN performs this regional registration by sending a BU to the MAP with the appropriate flags set. The contents of the BU will depend on the MAP's mode of operation. When registering with a MAP, the A flag SHOULD be set and the M flag MUST be set in the BU. The H flag MUST not be set when registering with a MAP. A MN SHOULD wait for a BAck (Binding Acknowledgement) from the MAP before using the MAP address or a RCOA from the MAP's subnet as an alternate COA in its BUs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As mentioned previously, the MAP discovery is done via router advertisements having the new MAP option added. A MAP will be configured to send its option or relay other MAPs' options on certain interfaces. The choice of interfaces is done by the network operator and depends on the network architecture. A default preference value should be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g. node overload or load sharing). A preference value of 255 means that the MAP SHOULD not be chosen by a MN. This value could be reached in cases of node overload or node failures. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 681, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 685, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 688, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-02 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-01) exists of draft-elmalki-handoffsv6-00 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Hesham Soliman, Ericsson 2 INTERNET-DRAFT Claude Castellucia, INRIA 3 Expires: February 2001 Karim El-Malki, Ericsson 4 Ludovic Bellier, INRIA 5 September, 2000 7 Hierarchical MIPv6 mobility management 8 10 Status of this memo 12 This document is a submission by the mobile-ip Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 Other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or cite them other than as "work in 28 progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This draft introduces some extensions for MIPv6 and neighbour 39 discovery to allow for the introduction of a hierarchical MIPv6 40 mobility management model. The proposed hierarchical mobility 41 management for MIPv6 will reduce the amount of signalling to CNs and 42 the HA and may also improve the performance of MIPv6 in terms of 43 handoff speed. Moreover, HMIPv6 is well-suited to implement access 44 control and handoffs between different access technologies. 46 TABLE OF CONTENTS 48 1. Introduction.............................................3 50 3. Hierarchical Mobility Management using MIPv6.............5 52 4. Overview of the MIPv6 Hierarchical Mobility Management...6 54 5. Neighbour Discovery extension - MAP discovery............9 56 6. MIPV6 extensions - Sending Binding Updates..............10 58 7. MN Operation............................................11 59 7.1 MAP Discovery...........................................11 60 7.2 Sending Binding Updates.................................12 61 7.3 Receiving packets in a foreign network..................12 62 7.4 Fast Handoff scenario...................................13 64 8. MAP Operation...........................................14 65 8.1 MAP Discovery..................................._.......14 66 8.2 Receiving and forwarding Packets for a MN...............14 67 8.3 Fast handoff scenario...................................15 69 9. HA Operation............................................15 71 10. AAA Considerations for IPv6.............................16 73 11. Acknowledgements........................................16 75 12. Notice Regarding Intellectual Property Rights...........16 77 13. References..............................................17 79 14. Authors' addresses......................................17 81 1. Introduction 83 This draft introduces the concept of a Hierarchical Mobile IPv6 84 network, utilizing a new node called the Mobility Anchor Point (MAP). 86 In Mobile IPv6 there are no Foreign Agents, but there is still the 87 need to provide a central point to assist with MIP handoffs. 88 Similarly to MIPv4, Mobile IPv6 can benefit from reduced mobility 89 signalling with external networks by employing a regional 90 hierarchical structure. For this reason a new Mobile IPv6 node, 91 called the Mobility Anchor Point (MAP), is used and can be located at 92 any level in a hierarchical Mobile IPv6 network including the Access 93 Router (AR). Unlike FAs in IPv4, a MAP is not required on each 94 subnet. Two different options are proposed in this memo for the use 95 of a MAP. A MN may use the MAP as an alternate-care-of address (COA) 96 or form a Regional COA (RCOA) on the MAP's subnet while roaming 97 within a hierarchical (MAP) domain, where such a domain involves all 98 access routers advertising that MAP. The two options are described in 99 detail in chapters 4.1 and 4.2. 101 The MAP will limit the amount of Mobile IPv6 signalling outside the 102 domain and will support Fast Handoffs to help Mobile Nodes in 103 achieving seamless mobility. Other advantages of the introduction of 104 the MAP functionality are covered in chapter 3. 106 This draft assumes the generic case of scaleable multi-level 107 Hierarchical Mobile IP (HMIP) networks and is therefore applicable to 108 HMIP networks in general. Hierarchical MIPv6 (HMIPv6)can assist with 109 speeding up MIP Handoffs, hence offering advantages which are 110 especially important for the support of real-time services. 112 3. Hierarchical Mobility Management using MIPv6 114 The aim of introducing the hierarchical mobility management model in 115 MIPv6 is to enhance the network performance while minimising the 116 impact on MIPv6 or other IPv6 protocols. This is achieved by using 117 the MIPv6 protocol combined with layer 2 features to manage both IP 118 micro and macro mobility, leading to rationalisation and less complex 119 implementations in the MN and other network nodes. This hierarchical 120 MIPv6 scheme introduces a new function, the Mobility Anchor Point 121 (MAP), and minor extensions to the MN and the Home Agent operations. 122 The CN operation will not be affected. 124 The introduction of the MAP concept minimises the latency due to 125 handoffs between access routers. Furthermore, the addition of 126 bicasting to a MAP allows for Fast Handoffs [5] which will minimise 127 the packet losses due to handoffs and consequently improve the 128 throughput of best effort services and performance of real time data 129 services over the radio interface. Just like MIPv6, this solution is 130 independent of the underlying access technology, allowing Fast 131 Handoffs within, or between, different types of access networks. 132 Furthermore, a smooth architectural migration can be achieved from 133 Hierarchical MIPv4 networks, since a dual operation of IPv4 and IPv6 134 Hierarchies will be possible making use of the similarity in 135 architecture. 137 The introduction of the MAP concept will further diminish signalling 138 generated by MIPv6 over the radio interface. This is due to the fact 139 that a MN only needs to perform one regional update (MAP) when 140 changing its layer 3 access point within the MAP domain.The 141 advantage can be easily seen when compared to other scenarios (no 142 MAP) where at least two BUs (Binding Updates) will be sent (to one 143 CN and HA). A MAP may also interact with the AAA protocol to perform 144 key distribution during handoffs and eliminate the need for re- 145 authentication as explained in ch 10. 147 4. Overview of the MIPv6 Hierarchical Mobility Management 149 In order to introduce hierarchical mobility management in MIPv6, the 150 protocol is extended with a new function. The proposed new 151 functionality is the Mobility Anchor Point (MAP). It simply provides 152 an optional mobility management function that can be located at any 153 level in the hierarchy starting from the access router upwards. 155 The MAP may be used by a MN as an alternate-COA [1] while roaming 156 within a certain MAP domain. Alternatively, the MN MAY choose to use 157 a Regional Care of Address (RCOA) on the MAP's subnet as its own COA 158 while roaming within a MAP's domain. In the latter case, a MAP acts 159 essentially as a local Home Agent (HA) for the MN. A MAP domain's 160 boundaries are defined by the Access Routers (ARs) advertising the 161 MAP information to the attached Mobile Nodes. The control of a MAP's 162 mode of operation (as an alternate-CoA or a local HA) is left to the 163 network administrator's discretion. 165 When the MAP is used as an alternate COA, the MAP will receive all 166 packets on behalf of the MN and will encapsulate and forward them 167 directly to the MN's current address. If the MN changes its current 168 address within a regional MAP domain, it needs to register the new 169 address with the MAP. This makes the MN's mobility transparent to the 170 CNs it is communicating with. The MAP can also be used to execute a 171 Fast Handoff between ARs as explained in [5]. 173 The detailed extensions to MIPv6 and operations of the different 174 nodes will be explained later in this document. 176 Although the proposed method is independent of the network topology, 177 it is best suited to a hierarchical network or one with multi-access 178 technologies. It should be noted that the MAP concept is simply an 179 extension to the MIPv6 protocol. Hence a MAP-aware MN with an 180 implementation of MIPv6 MAY choose to use the MAP or simply use the 181 standard MIPv6 implementation as it sees fit. Furthermore, a MN can 182 at any time stop using the MAP. This provides great flexibility, both 183 from a MN or a network operations point of view. 185 The network architecture shown below illustrates an example of the 186 use of the MAP in a foreign domain. 188 _______ 189 | HA | 190 |_______| _______ 191 \ | CN | 192 \ |_______| 193 \___ | 194 \ | 195 \ ____| 196 _\___|_ 197 | | 198 | MAP | 199 |_______| 200 / \ 201 / \ 202 / \ 203 / \ 204 ____/____ \_________ 205 | | | | 206 | AR1/MAP | | AR2/MAP | 207 |_________| |_________| 208 | | 209 | | 210 __\/____ \/ 211 | | 212 | MN | 213 |________| 214 __________________\ 215 Movement / 217 Figure 1: Hierarchical MIPv6 domain 219 In Figure 1, the MAP can help in providing seamless mobility for the 220 MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), 221 while communicating with the CN. It is possible to use multi-level 222 hierarchies of routers and implement MAP functionality in AR1 and AR2 223 if needed. It should be noted that AR1 and AR2 could be two points of 224 attachment in the same RAN (Radio Access Network) or in different 225 RANs. 227 Upon arrival in a foreign domain, the MN will discover the global 228 address of the MAP. This address is stored in the Access Routers 229 and communicated to the MN via Router Advertisements. The discovery 230 phase will also inform the MN of the distance of the MAP from the MN. 232 For example, the MAP could also be implemented in AR1 and AR2, in 233 which case the MN can choose the first hop MAP, second hop MAP, or 234 both. 236 A Router advertisement extension is proposed later in this document 237 for MAP discovery. Other service discovery methods may also be used 238 for the same purpose. If a router advertisement is used for MAP 239 discovery, as described in this document, all ARs belonging to the 240 MAP domain MUST advertise the MAP's IP address. The same concept 241 should be used if other methods of MAP discovery are introduced. 242 The MAP option in the router advertisement should inform the MN about 243 the chosen mode of operation for the MAP. 245 The process of MAP discovery continues as the MN moves from one 246 subnet to the next. As the MN roams within a MAP's domain, the same 247 information announcing the MAP should be received. If a change in the 248 advertised MAP's address is received, the MN should act on the change 249 by sending the necessary Binding Updates to its HA and CNs. 251 If the MN is not MAP-aware then the discovery phase will fail 252 resulting in the MN using the MIPv6 [1] protocol for its mobility 253 management. On the other hand, if the MN is MAP-aware it MAY choose 254 to use the MAP implementation. If so, the MN will first need to 255 register with a MAP by sending it a BU containing its Home Address 256 and current address. In the case where the MN uses the MAP as an 257 alternate-COA, the Home address used in the BU is the MNs Home 258 Address on its home subnet. On the other hand, if the MN is using a 259 RCOA, the Home address used in the BU is the RCOA. The MAP MUST store 260 this information in its Binding Cache to be able to forward packets 261 to their final destination when received from the different CNs or 262 HAs. 264 The MN will always need to know the original sender of any received 265 packets. Since all packets will be tunnelled by the MAP, the MN is 266 not always able to determine whether the packets were originally 267 tunnelled from the Home Agent or received directly from a CN. This 268 knowledge is needed by the MN to decide whether a BU needs to be sent 269 to a CN in order to initiate route optimisation. For this purpose a 270 check needs to be performed on the internal packet's routing header 271 to find out whether the packet was tunnelled by the HA or originated 272 from a CN using route optimisation instead. If a routing header 273 exists in the internal packet, containng its alternate-COA (MAP 274 address or RCOA) and the MN's Home Address as the final destination, 275 then route optimisation was used. Otherwise, triangular routing 276 through the HA was used. 278 To use the network bandwidth in a more efficient manner, a MN may 279 decide to register with more than one MAP simultaneously and use each 280 MAP address for a specific group of CNs. For example, in Fig 1, if 281 the CN happens to exist on the same link as the MN, it would be more 282 efficient to use the first hop MAP (in this case assume it is AR1) 283 for communication between them. This will avoid sending all packets 284 via the "highest" MAP in the hierarchy and hence result in a more 285 efficient usage of network bandwidth. The MN can use its current 286 address as a COA as well. 288 4.1 Using a MAP's address as a COA 290 Using a MAP as an alternate-COA may be a useful tool for some 291 mobility scenarios. In the case where a MN is also a router to which 292 several MN's may be connected (eg. a Personal Area Network), it would 293 not be possible for such router to obtain a new network prefix within 294 a visited network. Hence, MNs connected to such router will end up 295 with topologically incorrect addresses. By having the mobile router 296 act as a MAP within the visited network, MNs connected to it may use 297 it as an alternate-COA when registering with their HA and other CNs. 298 Hence, maintaining the IPv6 powerful aggregation of routes witihn the 299 backbone. 301 In this case the MAP option will be advertised by the AR that the MN 302 is connected to. The MN SHOULD send a BU to the HA and CNs including 303 the MAP's address as an alternate-COA. Hence all packets addressed to 304 the MN will be sent through the MAP's address as specified by the MN 305 in its BU. The MAP will (acting like a HA) tunnel the packets 306 addressed to the MN to its current address. The details of the MAP 307 operation will be given later in this document. 309 The Home Address contained in the MAP registration MUST be the same 310 Home Address sent in the Home Agent registration. If a MN sends 311 different BU's for different Home Addresses (in the case it has 312 multiple Home Addresses), the same process MUST be performed for the 313 MAP registrations. This is essential to allow a MAP to forward 314 packets to the right COA when they are tunnelled from the HA. The MN 315 SHOULD also have a prefix length of 128 in its BUs to the HA. This 316 would stop the HA from being proxy for other unregistered Home 317 addresses. 319 The MAP will need to know how the final destination in the packet 320 corresponds to the registered address of a MN. This should be obvious 321 when the packets are sent from a CN to the global Home Address of the 322 MN or to the COA with a routing header. However, if the HA tunnels 323 packets with addresses other than the MN's Home Address (eg. Site- 324 local), of which the MAP would have no knowledge, the HA MUST add a 325 routing header to the outer packet. This routing header must use one 326 of the MN's registered Home Addresses as the final destination. This 327 will enable the MAP to tunnel the packet to the correct destination 328 (i.e. the MN's current address). 330 4.2 Using a Regional COA (RCOA) on a MAP's subnet 331 In this scenario, the MN would have two addresses, a RCOA on the 332 MAP's subnet and an on-link COA (LCOA). This RCOA is formed in a 333 stateless manner by combining the MAP's subnet prefix received in the 334 MAP option with the MNs interface identifier. 336 After forming the RCOA, the MN sends a BU to the MAP. The BU will 337 bind the RCOA (similar to a Home Address) to its LCOA. The BU MUST 338 have both the A and D flags set. The MAP (acting as a HA) will then 339 perform DAD for the MN's RCOA on its subnet. If successful, the MAP 340 will return a Binding Acknowlegement (BAck) to the MN indicating a 341 successful registration. Otherwise, the MAP MUST return a BAck with 342 the appropriate fault code. No new error codes are needed for this 343 operation. 345 The MAP will receive packets addressed to the MN's RCOA (from the HA 346 or CNs). Packets will be tunnelled from the MAP to the MN's LCOA. The 347 MN will decapsulate the packets and process the packet in the normal 348 manner. 350 5. Neighbour Discovery extension - Dynamic MAP discovery 352 The process of MAP discovery can be performed in many different ways. 353 In this document, router advertisements are used for the discovery 354 phase by introducing a new option. The access router is required to 355 send the MAP option in all router advertisements. This option 356 includes the distance from the MN in terms of number of hops, the 357 preference for this particular MAP and the MAP's global IP address. 358 The ARs can be configured manually or automatically with this 359 information. In the case of automatic configuration, each MAP in the 360 network needs to be configured with a default preference, the right 361 interfaces to send this option on and, if necessary, the IP address 362 to be sent. The initial value of the "Distance" field MUST be set to 363 a value of one. Upon reception of a router advertisement with the MAP 364 option, given that a router is configured to resend this option on 365 certain interfaces, the router MUST copy the option and resend it 366 after incrementing the Distance field by one. If the router was also 367 a MAP, it SHOULD send its own option in the same advertisement. In 368 this manner information about a MAP at a certain level in a hierarchy 369 can be dynamically passed to a MN. Furthermore, by performing the 370 discovery phase in this way, different MAP nodes are able to change 371 their preferences dynamically based on the local policies, node 372 overload or other load sharing protocols being used. 374 The following figure illustrates the new MAP option. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Length | Distance | Pref | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Plen |R|M| Reserved | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Valid Lifetime | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 + + 387 | | 388 + Prefix / Global IP Address for MAP + 389 | | 390 + + 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 The alignment requirements for this option is 8n. 396 Fields: 398 Type Message type. To be assigned. 400 Length 8-bit unsigned integer. The length of the 401 option (including the type and length fields) 402 in units of 8 octets. The value 0 is invalid. 403 Nodes MUST silently discard an ND packet that 404 contains an option with length zero. 406 Distance An 8 bit unsigned integer showing the distance 407 from the receiver of the advertisement. It 408 MUST be set to one in the initial 409 Advertisement, if dynamic MAP discovery is 410 used. 412 Pref The preference of this MAP. An 8 bit unsigned 413 integer. A value of 255 means lowest 414 preference. 416 Plen The prefix length in this option. A prefix 417 length value of 128 indicates that the MAP 418 option contians the MAP's IP address. 420 R Indicates that the MN MUST form a RCOA 422 M Indicates that the MN MUST use the MAP's 423 Own IP address as an alternate-COA 425 Global Address One of the MAP's global addresses. 427 To ensure a secure communication between routers, router 428 advertisements containing the MAP option SHOULD be authenticated by 429 AH. In the case where this authentication is not possible, a network 430 operator may prefer to manually configure all the ARs to send the MAP 431 option. 433 6. MIPV6 extensions - Sending Binding Updates 435 This section outlines the extensions proposed to the BU option used 436 by the MN in MIPv6. A new flag is added: the M flag that indicates 437 MAP registration. When a MN registers with the MAP, the M flag MUST 438 be set to distinguish this registration from a Home Registration or a 439 BU being sent to a CN. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Option Type | Option Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |A|H|R|D|M| Res | Prefix Length | Sequence Number | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Lifetime | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Sub-Options... 451 +-+-+-+-+-+-+-+-+-+-+-+- 453 Description of extensions to the BU option: 455 M If set indicates a MAP registration. 457 Res 3 bit reserved field 459 7. MN OPERATION 461 This section is concerned with the extensions to the MN's operation 462 in a foreign network due to the introduction of the MAP. Unless 463 otherwise specified, the normal MN operation in [1] applies. 465 7.1 MAP discovery 467 When a MAP-aware MN receives a router advertisement, it should search 468 for the MAP option. One or more options may be found for different IP 469 addresses or subnet prefixes. 471 A MN SHOULD register with the MAP having the lowest preference value. 472 A MAP with a preference value of 255 SHOULD not be used in the MAP 473 registration. A MN MAY however choose to register with one MAP rather 474 than another depending on the value received in the Distance field, 475 as long as the preference value is below 255. 477 A MN SHOULD store the received option(s) and choose at least one MAP 478 to register with. Storing the options is essential as they will be 479 compared to other options received later for the purpose of the move 480 detection algorithm. 482 If no MAP options are found in the router advertisement, the MN MUST 483 use the MIPv6 protocol as specified in [1]. If the MN receives a 484 duplicated MAP option ( having the same IP address or prefix) with 485 different preference values or Distance values, the MAP IP address 486 SHOULD not be used as an Alternate-COA in any BU's sent by the MN. 488 Finally if the M flag is set in the MAP option, the MN MUST register 489 with the MAP and inform its HA. 491 A MN MAY choose to register with more than one MAP simultaneously or 492 use both MAP address and its own address as COAs simultaneously with 493 different CNs. 495 7.2 Registration with the MAP - Sending Binding Updates 497 After MAP discovery has taken place, a MN can register with one or 498 more MAPs. The MN performs this regional registration by sending a BU 499 to the MAP with the appropriate flags set. The contents of the BU 500 will depend on the MAP's mode of operation. 501 When registering with a MAP, the A flag SHOULD be set and the M flag 502 MUST be set in the BU. The H flag MUST not be set when registering 503 with a MAP. A MN SHOULD wait for a BAck (Binding Acknowledgement) 504 from the MAP before using the MAP address or a RCOA from the MAP's 505 subnet as an alternate COA in its BUs. 507 After successfully performing registration with a MAP, a MN can start 508 sending BUs, with it's Alternate-COA,to CNs and its HA. The MAP's IP 509 address or RCOA MUST be included in the Alternate-COA sub-option. 511 If the MN uses a MAP's address as an alternate-COA, then for each 512 home address registration sent to the HA with a MAP's address as the 513 COA, a BU MUST be sent to the same MAP using the same home address. 515 The MN SHOULD send a separate home registration BU for each home 516 address, with the prefix length value set to 128. This stops the HA 517 from forming home addresses for that MN on each link that the HA is 518 connected to, thus ensuring consistency in the Binding Caches of both 519 the MAP and HA for the MN. 521 7.3 Receiving packets in a foreign network 523 When in a foreign network, a MN needs to know which path a packet has 524 taken from the CN to the MN. That is, whether triangular routing was 525 used via the HA or route optimisation was used. When using HMIPv6, 526 all packets received from a CN will be tunnelled by the MAP to the 527 MN. 529 When using the MAP's address as a COA, packets tunnelled by the HA 530 to the MAP will be decapsulated and then encapsulated again with the 531 MAP's address as the source address. 533 Therefore a check on whether the packet was tunnelled by the HA will 534 not be sufficient to decide whether route optimisation is required. 536 Hence, a generic check for the existence of a routing header in the 537 encapsulated packet (i.e. with CN as source address), where the MN's 538 home address is the final address, will be sufficient to determine 539 whether the path was route optimised or not. 540 If the routing header does not exist, the MN SHOULD send a BU with 541 the appropriate information to initiate route optimisation. 542 It should be noted that such check is generic and would work for all 543 the various use cases of MIPv6 including the different MAP modes of 544 operation in this memo. 546 8. MAP Operation 548 8.1 MAP Discovery 550 As mentioned previously, the MAP discovery is done via router 551 advertisements having the new MAP option added. A MAP will be 552 configured to send its option or relay other MAPs' options on certain 553 interfaces. The choice of interfaces is done by the network operator 554 and depends on the network architecture. A default preference value 555 should be assigned to each MAP. It should be noted that a MAP can 556 change its preference value at any time due to various reasons (e.g. 557 node overload or load sharing). A preference value of 255 means 558 that the MAP SHOULD not be chosen by a MN. This value could be 559 reached in cases of node overload or node failures. 561 The MAP option is propagated down the hierarchy. Each router along 562 the path to the access router will increment the Distance field. If a 563 router that is also a MAP receives advertisements from other MAPs, it 564 SHOULD add its own MAP option and propagate both options to the next 565 level in the hierarchy. 567 8.2 Receiving and forwarding Packets for a MN 569 The MAP operation is in many ways similar to the HA operation 570 described in [1] with some modifications. Upon reception of a BU from 571 a MN with the M flag set, and provided it is allowed to accept this 572 message (i.e. no local policy restrictions) the MAP MUST process the 573 BU and if successful, add the information to its Binding Cache. 575 The MAP will need to determine how it should act based on the 576 information given in the BU. Two different modes of operation are 577 described below. 579 8.2.1 Using a MAP's address as a COA 580 In this scenario, the BU from the MN will contain its LCOA as a 581 source address and its Home address. A MAP MUST first check if the MN 582 is authorised to use the MAP in this mode. If so, the MAP SHOULD 583 process the BU in the normal manner. 585 If the A flag was set, the MAP MUST send a BAck to the MN. 587 All packets directed to the MN will be received by the MAP and 588 tunnelled to the MN. Upon reception of an encapsulated packet with no 589 routing header in the outer packet, the packet is decapsulated in the 590 normal way. If the inside packet contains a destination address that 591 doesn't belong to the MAP, the MAP should check its Binding Cache to 592 see if the address belongs to any of its registered MN's. If it does, 593 the packet MUST be tunnelled to the MN's current address. Otherwise, 594 the packet is processed in the normal way. 596 If the encapsulated packet contains a routing header in the outer 597 packet containing the MN's home address as the next destination, the 598 MAP MUST process the routing header in the normal way, then tunnel 599 the packet to the MN's current address. 601 8.2.2 Using a RCOA on the MAP's subnet 603 In this scenario, a MAP would have no knowledge of the MN's Home 604 address. The MN will send a BU to the MAP with the M, A and D flags 605 set. The aim of this BU is to inform the MAP that the MN has formed a 606 RCOA (contained in the BU as a Home address) and request that a MAP 607 performs DAD on its behalf. This is identical to the HA operation in 608 [1]. If the operation was successful, the MAP MUST respond with a 609 BAck to the MN indicating a successful operation. Otherwise a BAck is 610 sent with the appropriate error code. No new error codes are 611 introduced for HMIPv6. 613 8.3 The MAP as a Mobile Router (MR) 615 In the case where a Mobile Router (MR) is located in a foreign 616 network, the MR will not be able to obtain a new network prefix for 617 the MNs attached to it. Hence, the MR MUST act as a MAP and advertise 618 the MAP option to the MNs attached to it. The MAP option MUST have 619 the M flag set to ensure that the MNs register with it. This will 620 allow the MNs to be reachable without advertising host specific 621 routes to other routers within the network. This approach maintains 622 IPv6 route aggregation and ensures that no additional routing table 623 entries are required due to the MR's network mobility. 625 9. HA Operation 627 The Home Agent operations are affected in a minor way by the 628 introduction of the MAP. The only impact due to HMIPv6 on the HA 629 implementation is that when tunnelling packets to the MN with 630 destination addresses other than the addresses registered by the MN 631 in its Home Registration, the HA MUST include a routing header in 632 the outer packet with the MN's registered home address as the final 633 destination. This is done to enable the MAP to find the right 634 routing entry for the MN, since it has no knowledge of a non-unicast 635 global home address for the MN. 637 10. AAA Considerations for IPv6 639 The MAP can be utilised to perform access control on MNs and may 640 interact with the protocol which will be defined for AAA in IPv6. The 641 MAP can speed up a handoff by having the MN's security credentials 642 which will allow it to verify whether a certain node is allowed 643 access to the network. This allows greater efficiency in distributing 644 keys only to certain nodes in the network. 646 One example of the interaction between a MAP and the AAA 647 infrastructure can be seen when considering the handoff scenario. A 648 MAP can store the MN's security credentials after the MN is allowed 649 network access by the AAA infrastructure. During an intra-domain 650 handoff, the MAP could pass the MN's secrity credentials to the "new" 651 AR to avoid performing the AAA process. These credentials depend on 652 the access enforcement policies in AAAv6 and will not be covered by 653 this draft. 655 11. Acknowledgements 657 The authors would like to thank Conny Larsson (Ericsson) and Mattias 658 Pettersson (Ericsson) for their valuable input to this draft. 659 In addition, the authors would like to thank the following members of 660 the working group in alphabetical order: Eva Gustaffson (Ericsson), 661 Dave Johnson (Rice University), Annika Jonsson (Ericsson), Fergal 662 Ladley (Ericsson) and Erik Nordmark (Sun) for their comments on the 663 draft. 665 12. Notice Regarding Intellectual Property Rights 667 Ericsson may seek patent or other intellectual property protection 668 for some or all of the technologies disclosed in this document. If 669 any standards arising from this disclosure are or become protected by 670 one or more patents assigned to Ericsson, Ericsson intends to 671 disclose those patents and license them on reasonable and non- 672 discriminatory terms. Future revisions of this draft may contain 673 additional information regarding specific intellectual property 674 protection sought or received. 676 13. References 678 [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", 679 draft-ietf-mobileip-ipv6-12.txt, February 2000. 681 [2] E. Gustafsson, A. Jonsson and C. Perkins, " Mobile IP Regional 682 Tunnel Management ", draft-ietf-mobileip-reg-tunnel-02.txt 683 (work in progress), March 2000. 685 [3] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 686 1996. 688 [4] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4". 689 (work in progress) 691 [5] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv6". 692 draft-elmalki-handoffsv6-00.txt (work in progress) 694 14. Appendix A: Planned additions to future revisions 696 In addition to the existing proposal, the following sections are 697 planned for future revisions: 699 - MAP discovery. Other ways for dynamic MAP discovery are being 700 investigated. The reuse of Router renumbering has been suggested and 701 if suited, it may be included in the next revision. 703 - quick discovery of MAP failures will be essential for the 704 reliability of this mechanism. Some suggestions for handling these 705 scenarios will be included in future revisions. 707 - Detailed notes for implementors will also be added. 709 15. Authors' Addresses 711 The working group can be contacted via the current chairs: 713 Basavaraj Patil Phil Roberts 714 Nokia Corporation Motorola M/S M8-540 715 6000 Connection Drive 1501 West Shure Drive 716 Irving, TX 75039 Arlington Heights, IL 60004 717 USA USA 719 Phone: +1 972-894-6709 Phone: +1 847-632-3148 720 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 721 Fax : +1 972-894-5349 723 Questions about this memo can also be directed to: 725 Hesham Soliman 726 Ericsson Australia 727 61 Rigall St., Broadmeadows 728 Melbourne, Victoria 3047 729 AUSTRALIA 730 Phone: +61 3 93012049 731 Fax: +61 3 93014280 732 E-mail: Hesham.Soliman@ericsson.com.au 734 Claude Castelluccia 735 INRIA Rhone-Alpes 736 655 avenue de l'Europe 737 38330 Montbonnot Saint-Martin 738 France 740 email: claude.castelluccia@inria.fr 741 phone: +33 4 76 61 52 15 742 fax: +33 4 76 61 52 52 744 Karim El Malki 745 Ericsson Radio Systems AB 746 Access Networks Research 747 SE-164 80 Stockholm 748 SWEDEN 750 Phone: +46 8 7573561 751 Fax: +46 8 7575720 752 E-mail: Karim.El-Malki@era.ericsson.se 754 Ludovic Bellier 755 INRIA Rhone-Alpes 756 655 avenue de l'Europe 757 38330 Montbonnot Saint-Martin 758 France 760 email: ludovic.bellier@inria.fr 761 phone: +33 4 76 61 52 15 762 fax: +33 4 76 61 52 52