idnits 2.17.1 draft-yousaf-ietf-mipshop-pbfmipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1149. 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 6 instances of too long lines in the document, the longest one being 32 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1036 has weird spacing: '... was rece...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'AP-ID' on line 400 -- Looks like a reference, but probably isn't: 'AR-Info' on line 400 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Experimental RFC: RFC 4065 (ref. '5') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mipshop Working Group F. Z. Yousaf 2 Internet Draft C. Wietfeld 3 Intended status: Standards Track Communication Networks Institute, 4 Expires: January 14, 2009 Dortmund University of Technology, 5 Germany. 6 July 14, 2008 8 Proactive Bindings for FMIPv6 9 draft-yousaf-ietf-mipshop-pbfmipv6-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 14, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Usually in FMIPv6, the MN will start the binding process with its 43 home agent and the correspondent nodes after it has attached to NAR. 44 Till the binding is completed, the mobile node continues to receive 45 packets via a reverse tunnel established between PAR and NAR. The 46 duration of this tunnel will depend on the time it takes for the 47 mobile node to complete its binding, till which time the tunnel will 48 continue to consume buffer and processing resources related to 49 maintaining the tunnel and forwarding packets through this tunnel in 50 both PAR and NAR. 52 This document specifies an extension to FMIPv6 to enhance its 53 performance, in terms of resource management, by reducing the 54 duration of the tunnel existence. This is achieved by enabling the 55 NAR to act as a proxy for the MN for FMIPv6 handover. Additional 56 message(s) and message options along with modifications to existing 57 FMIPv6 messages and message options and definitions of new messages 58 and message options to achieve the desired functionality is also 59 described in this document. 61 Table of Contents 63 1. Requirement notations .........................................3 64 2. Introduction...................................................3 65 3. Terminology....................................................4 66 4. Protocol Overview..............................................6 67 4.1. Handover Latency in Fast Mobile IPv6......................6 68 4.2. Open Issues in FMIPv6.....................................7 69 4.3. Proactive Bindings for FMIPv6 Operation Summary...........8 70 4.4. Advantages................................................8 71 5. Proactive Bindings for FMIPv6 Protocol Details.................9 72 5.1. Processing of Proxy Binding Acknowledgement (PrBAck) 73 Message.......................................................11 74 6. Message Formats...............................................13 75 6.1. New Proactive Binding Acknowledgement (PrBAck) Message...13 76 6.2. Modified Inter-Access Router Messages ...................15 77 6.2.1. modified Handover Initiate (HI) Message Format .....15 78 6.2.2. Modified Handover Acknowledgement (HAck)............16 79 6.3. Modified Mobility Header Messages........................17 80 6.3.1. Fast Binding Update (FBU)...........................17 81 6.3.2. Fast Binding Acknowledgement........................18 82 6.4. Modified Option..........................................20 83 6.4.1. IP Address 84 Option.........................................20 85 6.5. New Options..............................................21 86 6.5.1. Binding Destination Option..........................21 87 6.5.2. Anchor Home Address Option..........................22 88 6.5.3. Binding Update Information Option...................23 89 7. Security Considerations ......................................25 90 8. IANA Considerations...........................................25 91 9. Acknowledgments...............................................26 92 10. Normative References.........................................27 93 Intellectual Property Statement..................................27 94 Disclaimer of Validity...........................................28 96 1. Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [1]. 102 2. Introduction 104 In MIPv6 [2] a Mobile Node (MN) is said to have undergone handover 105 when the Home Agent (HA) and Correspondent Node(s) (CN(s)), upon 106 receiving respective Binding Update (BU) from the MN, successfully 107 create bindings between the MN's Home Address (HoA) and the Care-of 108 Address (CoA) pertaining to the MN new point of attachment and the MN 109 receives Binding Acknowledgements (BAs) from the HA and CN(s) in 110 response to the corresponding BUs. 112 MIPv6 is composed of several delay incurring sub-processes such as 113 Movement Detection, CoA auto-configuration, performing Duplicate 114 Address Detection (DAD) [4] on the newly configured CoA, CoA 115 registration (both with the HA and the CN(s)) and Route Optimization, 116 contributing to the overall handover latency, making MIPv6 unsuitable 117 for real-time communication sessions/streams and for fast moving 118 users undergoing frequent handovers, resulting in packet losses and 119 in worst cases, connection/session timeouts. 121 FMIPv6 is proposed in [3] which aims at reducing the "handover 122 latency" and related "packet losses" by performing operations such as 123 movement detection and new CoA configuration (including DAD for the 124 newly formed Address) in advance, i.e., while the MN is connected to 125 Previous/Present Access Router (PAR) and before it connected to the 126 New/Next Access Router (NAR)(as in predictive handover mode), by 127 creating a reverse tunnel between NAR and PAR to reduce packet 128 losses, but it does not address the latency that occurs due to 129 process of CoA registration with both the HA and the CN(s). 131 The FMIPv6 protocol also does not specify as to when, how and under 132 what conditions should this bi-directional PAR-NAR tunnel be torn 133 down and how to reduce its duration for resource preservation in both 134 PAR and NAR related to tunneling overhead. 136 This specification addresses these issues by proposing a mechanism of 137 "proactively" carrying out in advance the MN's CoA registration 138 process (home registration and correspondent registration) to further 139 optimize the base FMIPv6 protocol. 141 3. Terminology 143 This document refers to [2] and [3] for terminology. The following 144 terms and abbreviations are additionally used in this document. 146 The reference network is illustrated in Figure 1. 148 Proxy New Access Router (PrNAR): 150 The NAR which will act as a proxy on behalf of the MN by 151 proactively carrying out Home and Correspondent Registration on 152 behalf of the MN. 154 Proxy Binding Update List (PrBUL): 156 The PrNAR will create and maintain a Proxy Binding Update List on 157 behalf of the MN when carrying out proactive bindings with the HA 158 and CN(s). 160 Proxy Binding Acknowledgement (PrBAck): 162 The PrNAR will transmit this message after it successfully 163 creates bindings with the HA and the CN(s). 165 Anchor Home Network (AHN): 167 The network domain where the address assigned/configured to/by 168 the MN is considered to be the home address (HoA) and not a care- 169 of address (CoA). The access router of the AHN to which the 170 mobile node is connected to is the HA of the MN. 172 Surrogate Home Network (SHN): 174 The network domain where the MN is currently attached and the 175 address assigned/configured to/by the mobile node is considered 176 to be the care-of address and not a home address (or Anchor Home 177 Address). 179 Anchor Home Address (AHoA): 181 The address of the MN configured/assigned at the AHN. 183 Surrogate Home Address (SHoA): 185 The address of the MN configured/assigned at the SHN. Same as the 186 PCoA (or current CoA). 188 Anchor Home Network Information (AHNI): 190 Constitutes the IPv6 address of the MN's home agent in the AHN 191 and the Anchor Home Address (AHoA) of the MN in that domain. 193 Surrogate Home Network Information (SHNI): 195 Constitutes the IPv6 address of the access router to which the MN 196 is attached and the CoA assigned/configured to/by the MN in the 197 SHN, also termed as the Surrogate Home Address (SHoA). 199 Prospective Care-of Address (PCoA): 201 The NAR compatible address auto-configured by the MN while it is 202 connected to PAR but before it is assigned. 204 New Care-of Address (NCoA): 206 The address assigned to the MN after successful DAD operation by 207 NAR. 209 V +--------------+ 210 +-+ | Previous | < 211 | | ------------ | Access | ------- >-----\ 212 +-+ | Router | < \ 213 MN | (PAR) | \ 214 | +--------------+ +---------------+ 215 | ^ IP | Correspondent | 216 | | Network | Node | 217 V | +---------------+ 218 v / 219 v +--------------+ / 220 +-+ | Proxy New | < / 221 | | ------------ | Access | ------- >-----/ 222 +-+ | Router | < 223 MN | (PrNAR) | 224 +--------------+ 226 Figure 1 : Reference Scenario for Handover 228 4. Protocol Overview 230 4.1. Handover Latency in Fast MIPv6 232 When a MN moves to a new subnet, it has to establish connection to 233 the NAR of the new subnet and successfully register its NCoA by 234 creating bindings with the CN(s) and the HA before it can start 235 receiving regular traffic from its CN(s) via a direct route, i.e., 236 through a process called route optimization [2]. 238 When the MN moves into a new subnet it has to perform the 239 following tasks before it can resume connection with the CN(s). 241 1. Movement detection 243 2. Neighbor (router/AR) prefix discovery 245 3. NCoA configuration 247 4. DAD performed by the NAR and confirming the validity of the NCoA. 249 5. CoA registry 250 6. Home registration and correspondent registration of this NCoA 251 using BU and BA including the regular Return Routability 252 procedure. 254 After the successful completion of the above six tasks, the MN 255 becomes IP-capable on the new link and the MN is said to have 256 undergone handover, whereas the total "handover latency" is the sum 257 of the latencies incurred by each of the above six processes. 259 During this period of handover, the MN is practically disconnected 260 from the HA and the CN(s), this period of disconnection can also be 261 termed as a "blackout" period, and all the packets communicated 262 between the MN and CN(s) are expected to be delayed, lost or in worst 263 cases (in case of TCP timeouts) service disconnection. 265 The degree of packet loss or packet delay is a function of the 266 overall handover latency, and hence is not suitable for fast moving 267 users and /or using real time applications, such as video 268 conferencing. 270 FMIPv6 [3] aims at reducing the handover latency by performing the 271 above five steps in advance while the MN is still connected to PAR, 272 i.e., before the MN travel towards and establishes a L2 connection to 273 the NAR (termed as predictive handover mode), or after it has 274 established a L2 connection with the NAR (termed as reactive handover 275 mode). 277 FMIPv6 also reduces/eliminates the packet loss during the connection 278 blackout time, by establishing a bi-directional tunnel between PAR 279 and NAR. During this blackout period, the traffic from the CN(s) gets 280 delivered to NAR via the PAR through the tunnel where the packets get 281 buffered. When the MN connects to the NAR, all the buffered packets 282 at the NAR and subsequent packets arriving from the CN(s) will get 283 delivered to the MN via the PAR through the PAR-NAR tunnel. The MN 284 after connecting to the NAR will start the MIPv6 binding process [2] 285 with the HA and the CN(s), after the successful completion of which 286 the PAR-NAR tunnel gets torn down and all subsequent communication 287 between the MN and the CN(s) will take place via the NAR. 289 4.2. Open Issues in FMIPv6 291 The current FMIPv6 specification [3] does not provide any signaling 292 exchange to inform the PAR that it can stop forwarding packets and/or 293 the tunnel can be released. 295 Also the duration of the tunnel existence between PAR and NAR is 296 critical in terms of resource management and routing efficiency and 297 this can potentially contribute towards the following: 299 o Buffer space/resource commitment in both NAR and PAR, which may 300 not scale well in case of an increase in the number of prospective 301 MNs (or when a large number of MNs belonging to the same PAR 302 migrate to the same NAR), a situation typical on a congested 303 highway. 305 o Duration of tunnel existence will potentially contribute towards 306 packet jitter and delay, which may not favor real time 307 communication sessions and applications. 309 o Increased processing due to tunneling and de-tunneling of packets 310 at both PAR and NAR and then reverse tunneling of packets during 311 the time when the MN is establishing bindings with its HA and 312 CN(s). 314 o Possibility of in-efficient routing between MN and respective 315 CN(s) till the tunnel is released and new efficient/shortest path 316 routes between the CN(s) and NAR is calculated by the network. 318 o In case of high probability of error on the MN-PAR wireless link, 319 the tunnel between PAR and NAR may exist of a longer duration. 321 Thus controlling and minimizing the duration of the tunnel between 322 PAR and NAR holds the key to a better performance of FMIPv6 protocol 323 both in terms of handover latency and efficient management of 324 resources. 326 4.3. Proactive Binding for FMIPv6 (PB-FMIPv6) Operation Summary 328 In FMIPv6 [3], the tunnel between PAR and NAR exists till the 329 handover is complete. The handover is said to be complete only when 330 the MN successfully registers its New Care of Address (NCoA) with its 331 corresponding HA and CN(s). 333 The idea behind PB-FMIPv6 is that the registration of the NCoA with 334 its CN(s) and HA is done in advance and in parallel to when the MN is 335 in the process of disconnecting from PAR, connecting to NAR and 336 announcing its presence to NAR by sending Unsolicited Neighbor 337 Advertisement (UNA) message to NAR. 339 The motivation behind this approach is based on the fact that the NAR 340 becomes aware of the NCoA of the MN as early as it receives a 341 Handover Initiate (HI) message from PAR, after which it has every 342 possibility of proxying for MN and hence proactively perform the 343 requisite bindings on its behalf, while the MN is in the process of 344 moving away from PAR and entering the new subnet and establishing 345 connection with the NAR. 347 It is expected, depending on the speed of the MN, that by the time 348 the MN sends the UNA message to NAR, the NCoA will already be or in 349 the process of getting registered with the HA and the CN(s), 350 afterwards which the tunnel gets released immediately. In essence, 351 PB-FMIPv6 performs the MIPv6 registration process in parallel to the 352 MN's process of moving away from PAR and entering the new subnet and 353 establishing connection with the NAR thereby achieving timing 354 efficiency, which in turn will contribute towards the reduction in 355 PAR - NAR tunnel existence duration and offsetting all the issues 356 related to the extended duration of the PAR-NAR tunnel as outlined in 357 section 4.2. 359 4.4. Advantages 361 The reduction in tunnel duration by the proposed mechanism of 362 PB-FMIPv6 is expected to account for the following advantages: 364 o Resource preservation in case of early release of tunnel 366 o Resource available for other potential fast moving MNs into the 367 domain 369 o Early registration of MN's NCoA with the HA and the CN(s) 370 before/shortly after the MN arrives in the new domain. 372 o Reduction in processing due to tunneling, de-tunneling and reverse 373 tunneling of packets. 375 o Considerable load reduction on ARs due to reduction in buffer and 376 tunnel maintenance. 378 o Fully integrated into the present scheme of MIPv6 networks. 380 o Zero probability of binding messages to be lost over error prone 381 wireless links. 383 o No added complexity to existing network infrastructure and/or 384 topology. 386 o Reduction in handover latency. 388 5. Proactive Binding for FMIPv6 (PB-FMIPv6) Protocol Details 390 In PB-FMIPv6, the NAR is replaced by Proxy-NAR (PrNAR), which is NAR 391 acting as a proxy and performing proactive bindings on behalf of the 392 MN. The protocol operation is shown in figure 2. 394 The protocol operation of the PB-FMIPv6 is similar to that of the 395 base FMIPv6 protocol in which the MN, upon detecting one or more L2 396 ID during its scan operations or upon receiving some link level 397 trigger, will send a RtSolPr message to its access router in order to 398 resolve one or more AP identifiers to subnet-specific information. In 399 response, the PAR will send a PrRtrAdv towards the MN containing one 400 or more [AP-ID, AR-Info] tuples [3]. 402 The MN, based on some network selection criteria, auto-configures a 403 prospective-CoA (PCoA) pertaining to a specific new subnet that it 404 wishes to handover its connection to, and sends a FBU to PAR 405 instructing the PAR to request the PrNAR to proxy on behalf of the 406 MN. The MN will send the FBU with the P-flag set, indicating the MN's 407 request to perform PB-FMIPv6 operation. The FBU will carry the 408 address of the MN's HA in the AHN and the address(es) of the CN(s)in 409 the new Binding Destination Option (see section 6.5.1) and carry the 410 AHoA of the MN in the new Anchor Home Address Option (see section 411 6.5.2). The information carried by these two new options will also 412 convey the complete AHNI profile. 414 The PAR, upon receiving FBU with the P-flag set will send the HI 415 message towards the PrNAR with the P-flag set. The HI message, with 416 the P-flag set, besides carrying the prescribed FMIPv6 options [3] 417 MUST also be appended with an array of IP Address Option carrying the 418 following addresses: 420 1. The AHoA of the MN MUST be included with the Code-Option 421 value set to 4. This address will be subsequently used in the 422 Home Address Destination Option of the BU messages [2] sent 423 by the PrNAR on behalf of the MN. This address is obtained 424 from the Anchor Home Address Option carried by the received 425 FBU message. 427 2. The IP address of the MN's HA at the AHN MUST be included 428 with the Option-Code value set to 5. This address will be 429 subsequently used as the destination address of the IP header 430 of the BU message sent by the PrNAR for Home Registration of 431 the MN. This address is obtained from the Binding Destination 432 Option carried by the received FBU message. 434 3. The IP address of the CN MAY be included (if the MN is in 435 communication with) with the Option-Code value set to 6. This 436 address will be subsequently used as the destination address 437 of the IP header of the BU message sent by the PrNAR for 438 Correspondent Registration of the MN. The HI message MAY 439 carry none or multiple of such options depending on the 440 number of CN the MN is in communication with. This address is 441 obtained from the Binding Destination Option carried by the 442 received FBU message. 444 The PrNAR upon receiving the HI message with the P-flag set will 445 decide, based on some decision mechanism (such as available 446 resources) but beyond the scope of this document, whether or not to 447 perform proactive bindings on behalf of the MN, and this decision 448 will be conveyed with the P-flag in the HAck message set or unset. In 449 case of the HAck's P-flag unset; normal FMIPv6 process will ensue as 450 specified in [3]. 452 In case the PrNAR has decided to perform proactive bindings for the 453 MN, it will perform DAD on the PCoA and will inform of the NCoA and 454 its ability to proxy for the MN by sending a HAck message back to PAR 455 with its P-flag set. 457 As soon as the PAR receives a HAck, regardless of the status of the 458 P-Flag, a binding between the PCoA and NCoA will be formed inside PAR 459 and also a tunnel will be established between PAR and PrNAR. At the 460 same time, when NCoA has been confirmed by PrNAR, the PrNAR will 461 proactively initiate MIPv6 home registration and correspondent 462 registration process with the MN's HA located in the AHN and the 463 CN(s). The PrNAR will create and maintain a Proxy-Binding Update List 464 (PrBUL) on behalf of the MN. 466 In the meantime, the PAR will send an FBAck informing the MN of its 467 NCoA and the decision of the PrNAR, regarding proxying for the MN, 468 embedded in the status field of the FBAck message. 470 The PrNAR upon receiving BA(s) from the respective HA and the CN(s) 471 will update its PrBUL and will send Proxy Binding Acknowledgement 472 (PrBAck) to the PAR, which will also relay it to the MN (if the MN is 473 still on PAR's link). The PrBAck message besides indicating to the MN 474 about the successful binding on it's behalf is also used as an 475 implicit signal for the release of PAR-PrNAR tunnel. 477 All subsequent packets intended for the MN will now reach PrNAR 478 directly and get buffered. As soon as the MN establishes a L2 479 connection with the PrNAR, it will send an UNA and the PrNAR will 480 start forwarding all the buffered packets and subsequent packets 481 towards the MN. 483 The MN upon receiving a PrBAck will know that bindings with the HA 484 and CN(s) has been carried out proactively and will send messages 485 with the NCoA as the source address in all subsequent IP 486 transmissions. 488 If the MN has not yet established a L2 connection with the PrNAR when 489 it receives PrBAck, it MUST do so immediately as all transmissions 490 from the CN(s) will now be getting buffered at the PrNAR and any 491 delays on behalf of the MN in establishing connections with the PrNAR 492 can lead to possible delays, buffer overflow and hence packet losses. 494 5.1. Processing of Proxy Binding Acknowledgment (PrBAck) Message 496 Since the main motivation behind PB-FMIPv6 is the reduction in the 497 NAR-PrNAR tunnel duration, therefore the timing of the PrNAR's 498 signaling for the release of the tunnel is very important. 500 In principle the tunnel should be released soon after the PrNAR 501 completes the bindings on behalf of the MN and receives the relevant 502 BA(s) from the HA and CN(s). The PrNAR uses the PrBAck message as a 503 tunnel release signal and in addition informs the MN about the 504 successful completion of proactive bindings. 506 The PrNAR will send a PrBAck message for every BA it receives, and 507 eve3ry PrBAck will be appended with the Binding Update Information 508 Option (see section 6.5.3), which will enable a MN to update the 509 corresponding entries in its local Binding Update List cache. The 510 PrBAck corresponding to the last BA will have the tunnel release flag 511 set. 513 Since the BAs from different target nodes may arrive at PrNAR at 514 different times, therefore a separate PrBAck is sent for each BA 515 received and the last PrBAck message will contain the tunnel release 516 signal. Hence the tunnel should not be released until the reception 517 of the last BA. 519 For each BA received, the PrNAR will transmit a PrBAck with the NCoA 520 as the destination IP address on both the local wireless link and on 521 the PAR link via the tunnel. This is done to ensure the reception of 522 the PrBAck message by the MN in situation where the MN may have moved 523 to the PrNAR link before receiving the PrBAck on the PAR's link. The 524 destination address of the outer tunnel packet should be the IP 525 address of the PAR, which upon receiving the PrBAck will release the 526 tunnel, depending on the status of the tunnel release flag and 527 forward the inner packet (with NCoA as the destination address) on 528 the wireless link. The PAR should create a temporary forwarding state 529 for the NCoA only on the wireless interface till the time it receives 530 a tunnel release signal. The MN will continue to update its local BUL 531 entries with the information carried by the PrBAck message and upon 532 receiving the PrBAck with the tunnel release signal will know that 533 bindings has been completed and it will disconnect from the PAR (if 534 PAR already has not initiated the disconnection of the MN) and will 535 update its local BUL with the information available in the PrBAck 537 If the PrNAR receives UNA from the MN before it has transmitted the 538 last PrBACK (i.e., during the scenario in which the MN attaches to 539 PrNAR before the binding process has completed) then the subsequent 540 PrBAcks should be sent only on the local wireless link with NCoA as 541 the destination IP address and only the last PrBAck, carrying the 542 tunnel release signal should be sent towards PAR as well. This MAY be 543 true for both the predictive and reactive handover modes, but the 544 actual mode of handover depends on the reception of the FBAck message 545 as specified in [3]. For reactive handover modes, i.e. when the MN 546 doesn't receive FBAck on the PAR's link, the handover may be carried 547 out as per the reactive handover mode specified in [3] and the choice 548 of carrying out PB-FMIPv6 handovers may be optional depending on the 549 error probability on the PrNAR's wireless link. 551 MN PAR PrNAR HA CN 552 | | | | | 553 |------RtSolPr------->| | | | 554 |<-----PrRtAdv--------| | | | 555 | | | | | 556 |------FBU----------->|----------HI--------->|----BU---->| | 557 | |<--------HAck---------|<---BA-----| | 558 | <--FBack---|--FBack---> |---HoTI--->| | 559 | | |---CoTI--->|---HoTI->| 560 disconnect forward | |---CoTI->| 561 | packets ===============>| |<---HoT--| 562 | | |<---HoT--- | | 563 | | |<---CoT--------------| 564 connect | |------------BU------>| 565 | | |<-----------BAck-----| 566 |------------UNA --------------------------->| | | 567 |<=================================== deliver packets | | 568 |<------PrBAck--------|<--------PrBAck-------| | | 569 |<-----------------PrBAck--------------------| | | 570 | | | | | 572 Figure 2 : PB-FMIPv6 Protocol Operation. 574 6. Message Formats 576 The PB-FMIPv6 introduces an additional new message called the 577 Proactive Binding Acknowledgement (PrBAck) and two new message 578 options namely Binding Destination Option and Anchor Home Address 579 Option besides necessary modifications to the existing FMIPv6 580 messages and message options. 582 6.1. New Proactive Binding Acknowledgement (PrBAck) Message 584 The PrNAR will send a PrBAck message towards the MN for each BA it 585 receives from the HA and the CN(s). The PrBAck not only informs the 586 MN of the successful home and/or correspondent registration but also 587 carries information that is used by the MN to update its local 588 binding update list (BUL). This message is also used as a signal to 589 tear down the PAR-PrNAR tunnel. 591 The format of the message is shown in figure 3. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type | Code | Checksum | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Subtype |T| Reserved | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Options ... 601 +-+-+-+-+-+-+-+-+-+-+-+- 602 Figure 3 : Proactive Binding Acknowledgement (PrBAck) Message 604 IP Fields: 606 Source Address 607 IP address of the PrNAR 608 Destination Address 609 The NCoA of the MN. 611 ICMP Fields: 613 Type The Experimental Mobility Protocol Type. See [5]. 615 Code 0: Home Registration 616 1: Correspondent Registration. 618 Checksum The ICMPv6 checksum. 620 Subtype 6 (This value is yet to be determined by IANA. See 621 section 8) 623 'T' Flag Tunnel Release Flag. When set indicates to PAR to 624 release the tunnel. 626 Reserved MUST be set to zero by the sender and ignored by the 627 receiver. 629 Valid Options: 631 Binding Update Information Option 632 This option MUST be included in the PrBAck message. 633 The information carried by this option field is used 634 by the MN to update its corresponding BUL cache 635 entries. For more information see section 6.5.3 637 6.2. Modified Inter-Access Router Messages 639 6.2.1. Modified Handover Initiate (HI) Message Format 641 PB-FMIPv6 modifies the format of the Handover Initiate [3] by the 642 addition of a single flag bit to indicate that the PAR sending the HI 643 message is requesting a NAR to accept the proxy request for the MN. 645 The format of the Handover Initiate message is shown in figure 4. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Type | Code | Checksum | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Subtype |S|U|P| Reserved| Identifier | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Options ... 655 +-+-+-+-+-+-+-+-+-+-+-+- 657 Figure 4 : Handover Initiate (HI) Message 659 This format represents the following changes over that originally 660 specified for FMIPv6 [3]: 662 Proxy Flag (P) 663 When set indicates to the NAR to proxy on behalf of 664 the MN and carry out binding with the HA and the 665 CN(s). When not set indicates normal FMIPv6 operation. 667 Reserved 668 Reduced from a 6-bit field to a 5-bit field to account 669 for the addition of the above bit. 671 Valid Options: 673 Home Address of the MN at the AHN 674 The IP address of the MN configured at the Anchor Home 675 Network (AHN) (also termed as AHoA). This option MUST 676 be included, when the P-flag is set, by appending the 677 IP Address option with the Option-code value of 4. 679 MN's Home Agent Address at the AHN 680 The IP address of the MN's HA at the Anchor Home 681 Network (AHN). This option MUST be included, when the 682 P-flag is set, by appending the IP Address option with 683 the Option-code value of 5. 685 CN Address Option 686 The IP address of the CN with which, the MN wishes to 687 establish bindings with. This option MAY be included, 688 when the P-flag is set, by appending the IP address 689 option with the Option-code value set to 6. The HI 690 message MAY carry multiple such options. 692 6.2.2. Modified Handover Acknowledge (HAck) 694 The format of the Handover Acknowledge (HAck), which is sent as a 695 reply to HI, is modified by the addition of a single flag bit to 696 indicate that the PrNAR has accepted the request and will complete 697 bindings on behalf of the MN. 699 The format of the Handover Acknowledge message is shown in figure 5. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Code | Checksum | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Subtype |P| Reserved | Identifier | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Options... 709 +-+-+-+-+-+-+-+-+-+-+-+- 711 Figure 5 : Handover Acknowledge (HAck) Message 713 This format represents the following changes over that originally 714 specified for FMIPv6 [3]: 716 Proxy Acknowledge Flag (P) 717 When set indicates that the PrNAR has accepted the 718 proxying request of the MN and PrNAR has started the 719 NCoA registration process, and is maintaining a Proxy 720 Binding Update List (PrBUL) cache. When not set 721 indicates that the request can not be fulfilled. The P 722 flag should only be set when the code value is 0, 1, 723 2,3 or 4 (for details see [3]). For all other code 724 values, it should be 0. 726 Reserved 727 Reduced from a 8-bit field to a 7-bit field to account 728 for the addition of the above bit. 730 Upon receiving a HI message, the PrNAR MUST respond with a Handover 731 Acknowledge message, with the appropriate value for the code and P- 732 flag. Upon receiving a HI and accepting the MN's proxy request, the 733 PrNAR will create a Proxy Binding Update List (PrBUL), the 734 constitution of which is the same as that of the BUL defined in [2], 735 but with the MN's PAR and/or NAR address as a key to associate the 736 PrBUL contents with the relevant MN(s). This is necessary to handle 737 multiple MN(s) undergoing PB-FMIPv6. The PrNAR will maintain the 738 PrBUL till the MN attaches to it. 740 6.3. Modified Mobility Header Messages 742 Mobile IPv6 uses a new IPv6 header type called Mobility Header [2]. 743 The Fast Binding Update, Fast Binding Acknowledgment messages use the 744 Mobility Header. However, PB-FMIPv6 modifies these header messages 745 the relevant details of which are given below. 747 6.3.1. Fast Binding Update (FBU) 749 The format of the Fast Binding Update message is modified from the 750 original (see [2]) by the addition of a single flag bit to indicate 751 the MN's request to perform PB-FMIPv6 based handover. 753 The format of the message is shown in figure 6. 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Sequence # | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 |A|H|L|K|P| Reserved | Lifetime | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | | 761 . . 762 . Mobility options . 763 . . 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Figure 6 : Fast Binding Update (FBU) Message 769 This format represents the following changes over that originally 770 specified for FMIPv6 [3]: 772 Proxy Request Flag (P) 773 When set indicates that the MN desires to perform PB- 774 FMIPv6 based handover and is a request to the 775 candidate access router (PrNAR in our case) to perform 776 bindings on its behalf. When not set indicates normal 777 FMIPv6 operation. 779 Reserved 780 Reduced from a 12-bit field to a 11-bit field to 781 account for the addition of the above bit. 783 Valid Options 785 Binding Destination Option 787 When the P-flag is set, the FBU must contain one or 788 more binding destination option, which will convey the 789 address(es) to which BUs will be sent. The details 790 about this new option are given in 6.5.1. 792 Anchor Home Address Option 794 The FBU MUST contain the Anchor Home Address Option 795 when the P-flag is set. This option will carry the 796 AHoA of the MN which will be used in the Home Address 797 Option of the BU message sent by the NAR on behalf of 798 the MN. The details about this new option are given in 799 6.5.2. 801 The combination of the Binding Destination Option and the Anchor Home 802 Address Option provides the complete AHNI profile as well as the 803 destination addresses required by the BU message. The 805 The other valid options to be used are the same as specified in [3]. 807 6.3.2. Fast Binding Acknowledgment (FBack) 809 The format of the Fast Binding Acknowledgement message is the same 810 but it modifies the interpretation of the existing status values by 811 defining two new status values indicating the NAR's 812 acceptance/rejection to carry out proactive bindings on behalf of the 813 MN's request. The rules for the Mobility Option is also modified. 815 The format of the message is shown in figure 7. 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Status |K| Reserved | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Sequence # | Lifetime | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 . . 824 . Mobility options . 825 . . 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Figure 7 : Fast Binding Acknowledgment (FBack) Message 831 Status 833 8-bit unsigned integer indicating the disposition of 834 the Fast Binding Update. Values of the Status field 835 less than 128 indicate that the Binding Update was 836 accepted by the receiving node. The following such 837 Status values are currently defined: 839 0 Fast Binding Update accepted for normal FMIPv6 840 operation. PB-FMIPv6 operation not supported 842 1 Fast Binding Update accepted but NCoA is invalid. 843 Use NCoA supplied in ``alternate'' CoA and PB-FMIPv6 844 operation not supported 846 2 Fast Binding Update accepted and PB-FMIPv6 operation 847 enabled 849 3 Fast Binding Update accepted but NCoA is invalid. 850 Use NCoA supplied in ``alternate'' CoA and PB-FMIPv6 851 operation enabled 853 Values of the Status field greater than or equal to 854 128 indicate that the Binding Update was rejected by 855 the receiving node. The following such Status values 856 are currently defined: 858 128 Reason unspecified 860 129 Administratively prohibited 861 130 Insufficient resources 863 131 Incorrect interface identifier length 865 Mobility Options 867 MUST contain Alternate CoA option (see [2]) if Status 868 is 1 or 3. MUST contain the Binding Authorization Data 869 for FMIP (BADF) option as specified in [3]. 871 6.4. Modified Option 873 PB-FMIPv6 extends the IPv6 Address option by defining additional 874 Option-Codes. 876 6.4.1. IP Address Option 878 This option defines new option codes 4, 5 and 6, which is sent in the 879 Handover Initiate message. Option-Codes 4 and 5 convey the Anchor 880 Home Network Information (AHNI) while the Option-Code 6 conveys the 881 address(es) of the CN(s). 883 The format of the message is shown in figure 8. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | Option-Code | Prefix Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Reserved | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | 893 + + 894 | | 895 + IPv6 Address + 896 | | 897 + + 898 | | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Figure 8 : IPv6 Address Option 903 Option-Code 904 1 Old Care-of Address 905 2 New Care-of Address 906 3 NAR's IP address 907 4 MN's IP address at the AHN (AHoA). 908 5 IP address of the MN's home agent at the AHN 909 6 IP address of the CN 911 Option codes 4, 5 and 6 MUST be included together when the P-Flag in 912 the FBU and HI is set. 914 6.5. New Options 916 PB-FMIPv6 defines three new options, two of which namely the Binding 917 Destination Option and Anchor Home Address Option, is carried by the 918 FBU and encoded within the remaining space of the Message Data field 919 of the FBU, using a type-length-value (TLV) format as specified in 920 [2]. 922 The third new option namely, Binding Update Information Option is 923 carried by the PrBAck message (see section 6.1). 925 6.5.1. Binding Destination Option 927 At least one instance of this option MUST be present in the FBU when 928 the P-Flag is set. This option contains the array of address(es), 929 which will be copied into the appropriate options of the HI message, 930 to which the PrNAR will send the bindings to on behalf of the MN. 931 According to normal MIPv6 operations, the MN sends binding updates to 932 the HA and the CN(s) with which a communication session is 933 established. The option type identifies the address to be that of the 934 MN's HA in the AHN or of CN(s). The information contained in the 935 Binding destination option and the Anchor Home Address option (see 936 section 6.5.2) gives complete AHNI profile, which the PrNAR will use 937 for establishing bindings on behalf of the MN. 939 The format of the message is shown in figure 9. 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Option Type | Option Length | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | | 947 + + 948 | | 949 + IPv6 Address + 950 | | 951 + + 952 | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 9 : Binding Destination Option 957 Option Type 958 202 = 0xCA* Home Agent address of the MN at the AHN 959 203 = 0xCB* CN Address 961 (* The values for the Option Type field are to be determined by IANA. 962 The values shown here are for experimental purpose. See section 8). 964 6.5.2. Anchor Home Address Option 966 This option MUST be present in the FBU when the P-flag is set. The 967 Home Address option in the FBU carries the MN's PCoA, and adding the 968 Anchor Home Address option enables the information of the MN's AHoA 969 information to be also conveyed. 971 The format of the message is shown in figure 10. 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Option Type | Option Length | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | | 979 + + 980 | | 981 + Anchor Home Address + 982 | | 983 + + 984 | | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Figure 10 : Anchor Home Address Option 989 Option Type 990 204 = 0xCC* Anchor home address of the MN 992 (* The values for the Option Type field are to be determined by IANA. 993 The values shown here are for experimental purpose. See section 8). 995 6.5.3. Binding Update Information Option 997 This option MUST be present in the PrBAck message and its exact 998 format depends on the code value of the PrBAck message. 1000 The format of the message is shown in figure 11. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | IP Address | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Sequence Number | Reserved | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Lifetime | Remaining Lifetime | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | | 1012 + Home-Init Cookie + 1013 | | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | | 1016 + Home Key Gen Token + 1017 | | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | | 1020 + Care-of Init Cookie + 1021 | | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | | 1024 + Care-of Key Gen Token + 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Figure 11: Binding Update Information Option 1030 IP Address When the Code value in PrBAck message is 0, this 1031 IP address will be the IP address of the MN's HA 1032 in the AHN. When the code value is 1, this IP 1033 address will be the IP address of a CN. 1035 Sequence Number The sequence number of the BU for which the BA 1036 was received. 1038 Lifetime Lifetime of the binding in the destination node 1040 Remaining Lifetime Remaining lifetime of the binding in the 1041 destination node 1043 Home-Init Cookie It is zero when code value is 0 and should be 1044 ignored by the receiver. 1046 Home Key Gen Token It is zero when code value is 0 and should be 1047 ignored by the receiver. 1049 . 1051 Care-of Init Cookie It is zero when code value is 0 and should be 1052 ignored by the receiver. 1054 Care-of Key Gen Token It is zero when code value is 0 and should be 1055 ignored by the receiver. 1057 7. Security Considerations 1059 Security issues for this document follow those for MIPv6 [2] and 1060 FMIPv6 [3]. 1062 8. IANA Considerations 1064 This document defines a new experimental ICMPv6 messages which use 1065 the Experimental Mobility Protocol ICMPv6 format [5]. This requires 1066 for a new Subtype value assignments by IANA. 1068 Subtype Description Reference 1070 ------- ----------- --------- 1072 TBD PrBAck Section 6.1 1074 The document defines two new mobility options [2] which need Type 1075 assignment from the Mobility Options Type registry at 1076 http://www.iana.org/assignments/mobility-parameters. 1078 Option-Type Description Reference 1080 ----------- ----------- --------- 1082 TBD Binding Destination Option Section 6.5.1 1084 TBD Anchor Home Address Option Section 6.5.2 1086 9. Acknowledgments 1088 This document was prepared using 2-Word-v2.0.template.dot. 1090 10. Normative References 1092 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1093 Levels", BCP 14, RFC 2119, March 1997. 1095 [2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 1097 [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, 1098 July 2005. 1100 [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1101 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1103 [5] J. Kempf, ``Instructions for Seamoby and Experimental Mobility 1104 Protocol IANA Allocations," RFC 4065, Internet Engineering Task 1105 Force, June 2004. 1107 Author's Addresses 1109 Faqir Zarrar Yousaf 1110 Communication Networks Institute 1111 University of Dortmund 1112 Building Chemistry, 1113 Otto-Hahn-Str. 6, 1114 D-44227 Dortmund, Germany 1116 Email: faqir.yousaf@tu-dortmund.de 1118 Christian Wietfeld 1119 Communication Networks Institute 1120 University of Dortmund 1121 Building Chemistry, 1122 Otto-Hahn-Str. 6, 1123 D-44227 Dortmund, Germany 1125 Email: christian.wietfeld@tu-dortmund.de 1127 Intellectual Property Statement 1129 The IETF takes no position regarding the validity or scope of any 1130 Intellectual Property Rights or other rights that might be claimed to 1131 pertain to the implementation or use of the technology described in 1132 this document or the extent to which any license under such rights 1133 might or might not be available; nor does it represent that it has 1134 made any independent effort to identify any such rights. Information 1135 on the procedures with respect to rights in RFC documents can be 1136 found in BCP 78 and BCP 79. 1138 Copies of IPR disclosures made to the IETF Secretariat and any 1139 assurances of licenses to be made available, or the result of an 1140 attempt made to obtain a general license or permission for the use of 1141 such proprietary rights by implementers or users of this 1142 specification can be obtained from the IETF on-line IPR repository at 1143 http://www.ietf.org/ipr. 1145 The IETF invites any interested party to bring to its attention any 1146 copyrights, patents or patent applications, or other proprietary 1147 rights that may cover technology that may be required to implement 1148 this standard. Please address the information to the IETF at 1149 ietf-ipr@ietf.org. 1151 Disclaimer of Validity 1153 This document and the information contained herein are provided on an 1154 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1155 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1156 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1157 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1158 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1161 Copyright Statement 1163 Copyright (C) The IETF Trust (2008). 1165 This document is subject to the rights, licenses and restrictions 1166 contained in BCP 78, and except as set forth therein, the authors 1167 retain all their rights. 1169 Acknowledgment 1171 Funding for the RFC Editor function is currently provided by the 1172 Internet Society.