idnits 2.17.1 draft-oneill-mip-revtun-ho-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 127 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RoutOp], [MIPv4], [RevTun]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '... can be achie...' == Line 257 has weird spacing: '...reverse tunn...' == Line 283 has weird spacing: '...rrectly inst...' == Line 292 has weird spacing: '...dog-leg inter...' == Line 368 has weird spacing: '... nFA to buff...' -- 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 (22 Feb 2002) is 8096 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) == Missing Reference: 'RouteOpt' is mentioned on line 248, but not defined == Missing Reference: 'RoutOpt' is mentioned on line 544, but not defined -- Looks like a reference, but probably isn't: '13' on line 440 -- Looks like a reference, but probably isn't: '1' on line 463 == Unused Reference: 'RFC2026' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'LowLat' is defined on line 582, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3220 (ref. 'MIPv4') (Obsoleted by RFC 3344) -- Possible downref: Normative reference to a draft: ref. 'RoutOp' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. 'LowLat') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 Flarion Technologies 3 Internet Draft 22 Feb 2002 4 Document: draft-oneill-mip-revtun-ho-00.txt 5 Expires: 22 Aug 2002 7 Hand-off Extensions for Reverse Tunneling 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 Reverse tunneling in RFC3024 [RevTun] introduces new packet loss 38 scenarios at the HA and also incurs similar packet routing issues as 39 RFC3220 [MIPv4] between Foreign Agents, during a handoff. Whether a Co- 40 located Care-of-Address or a Foreign Agent Care-of-Address is used 41 during Mobile IP registration, any packets from the new Foreign that 42 are received at the Home Agent before the visitor list has been updated 43 will be dropped. In addition, any in-flight packets from the old 44 Foreign agent will be dropped once the visitor list has been updated. 45 This is because in either case the packet source address no longer 46 matches the current Care of Address binding. In addition, whilst smooth 47 handoff for MIPv4 can be achieved by using the PFANE extension 48 [RoutOp], a corresponding solution does not exist for reverse tunneled 49 during handoffs. Therefore, the base processing in [RevTun] (RFC 3024) 50 needs to be amended to better support reverse tunneling through FA 51 hand-offs. Specifically, this entails the support of multiple (fan-in) 52 reverse bindings at an MIP agent. This enables the agent to receive 53 reverse packets from both the oCoA and the nCoA during the hand-off. 54 The draft also adds support, in the case of a FA CoA, for a reverse 55 smooth hand-off via the old FA and the existing oCoA reverse forwarding 56 state. This is used whilst the nFA waits for the MIP Reply that 57 confirms the installation of the nFA CoA in the upstream MIP agent. 59 INDEX 61 Abstract 63 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 67 3. Terminology used in this document . . . . . . . . . . . . . . . . . 4 69 4. Reverse Tunneling Hand-off Extensions . . . . . . . . . . . . . . . 4 71 4.1. Fan-in Bindings. . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.2. Reverse smooth hand-off. . . . . . . . . . . . . . . . . . . . 5 73 4.3. Packet ordering. . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.4. Signaling Requirements . . . . . . . . . . . . . . . . . . . . 7 75 4.5. Low Latency Hand-off . . . . . . . . . . . . . . . . . . . . . 8 77 5. New Packet Formats 79 5.1. Binding Update . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.2. Binding Acknowledge Message. . . . . . . . . . . . . . . . . . 8 81 5.3. Mobility Agent Advertisement Extension . . . . . . . . . . . . 9 82 5.4. Fan-in Lifetime Extension. . . . . . . . . . . . . . . . . . . 10 83 5.5. New Registration Reply Codes . . . . . . . . . . . . . . . . . 10 85 6. MIPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 11 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 11 89 8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 11 91 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 When reverse tunneling with a FA CoA [RevTun], the MN can select during 96 MIP registration between the default Direct Delivery Style and the 97 optional Encapsulating Delivery Style. In Direct Delivery Style, the MN 98 sends packets unencapsulated via the FA using the HoA as a source 99 address, and the FA undertakes the encapsulation of those packets 100 towards the HA using the FA CoA as the source address of the tunnel. In 101 Encapsulating Delivery Style, the MN instead encapsulates packets with 102 the HoA as a source address towards the FA, which after decapsulating, 103 inspects the visitor list and then re-encapsulates into a tunnel with 104 the FA CoA as the source address. In addition, once Encapsulating 105 Delivery Style has been negotiated with the FA, then the MN can 106 selectively bypass reverse tunneling by sending packets unencapsulated 107 from the HoA. In either case, according to [RevTun] the HA and any 108 intermediate GFA, is only willing to receive packets from the FA CoA 109 currently registered for that Home Address (HoA). This simple 110 requirement does however cause significant problems for the support of 111 Reverse tunneled flows during a MIP hand-off. In subsequent text 112 references to the GFA will be dropped but all references to a HA imply 113 HA and/or GFA/RFA. 115 When the MN moves from an old Foreign Agent (oFA) to a new Foreign 116 Agent (nFA), the MN sends a MIP Registration via the nFA destined for 117 the HA. The new Registration binds the new CoA (nCoA) instead of the 118 old CoA (oCoA) to the HoA, where oCoA and nCoAs can be CCoAs or FA 119 CoAs. In either the CCoA or FA CoA case, the installation of the new 120 binding for the HoA will cause in-flight packets from the oFA to be 121 dropped at the HA, as they no longer match the current binding because 122 the source address is the oCoA. The packets will be dropped as soon as 123 the HA successfully processes the MIP Reply for the nCoA. Therefore the 124 MN needs to delay sending the MIP Reg via the nFA until all in-flight 125 packets have been received at the HA. However, the MN does not know 126 when this event happens and so must be cautious and wait a worse case 127 length of time. The MN can then send the MIP Reg for the nCoA but 128 still cannot reverse tunnel packets using this nCoA until the 129 successful MIP Reply is actually received back at the MN. This is 130 because the MN has no idea of when the HA actually installs the new 131 binding nor whether the MIP Registration succeeded or failed. Once 132 again, the MN must wait an unknown length of time to ensure that 133 reverse tunneled packets will not be dropped in the network due to a 134 binding mismatch. Therefore, the base processing in [RevTun] (RFC 3024) 135 needs to be amended to better support reverse tunneling through FA 136 hand-offs. Specifically, this draft adds support for reverse smooth 137 hand-offs to enable reverse tunneling via the oFA and the existing 138 mobility bindings as well as the support of fan-in bindings so that 139 reverse packets from both the oCoA and the nCoA are accepted. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC-2119 [RFC2119]. 147 3. Terminology used in this document 149 Much of the terminology used in this document borrows from Mobile IPv4 150 [MIPv4], Mobile IPv6 [MIPv6], MIP Reverse Tunneling [RevTun] and MIP 151 Route Optimization [RoutOp]. The following introduces additional 152 terminology. 154 Reverse smooth - inter-FA forwarding from the nFA to the oFA for a 155 smooth hand-off 156 Fan-in binding - supporting reverse tunneled packets from multiple 157 source CoAs 159 4. Reverse Tunneling Hand-off Extensions 161 4.1. Fan-in Bindings 163 The nFA cannot presently reverse tunnel directly to the HA until the 164 MIP Reply is received because this confirms that all MIP elements have 165 reverse forwarding state for the nCoA. Sending in advance of this MIP 166 Reply runs the risk of the reverse packets being dropped in the network 167 due to a missing reverse forwarding binding between the HoA and the 168 nCoA. Reception of the MIP Reply also means however that the state for 169 the oCoA must have been eliminated in the HA because the nCoA will have 170 replaced the oCoA in the HoA binding. This oCoA state will have 171 potentially been overwritten whilst packets were in-flight from the 172 oCoA. This can occur due to a Make Before Break hand-off, reverse 173 smooth hand-off tunneling (section 4.2), or relatively slow links 174 between the oFA and the HA compared to the MIP Reg/Reply delays via the 175 nFA. In the present MIP reverse tunneling spec [RevTun], the result 176 will be that packets arriving with the wrong (stale/late) source 177 address of the oCoA or wrong (new/early) source address of the nCoA 178 will then be dropped according to RFC3024. This is clearly unfortunate 179 and can be avoided by supporting fan-in bindings in the HA. 181 A fan-in binding is similar to simultaneous bindings but for the 182 reverse direction (ie from the CoA to the HA). The simultaneous 183 bindings flag is unsuitable for extending to cover reverse tunneling 184 though because this comes with it the cost of bi-casting of data to 185 both FAs. The zero cost of the fan-in binding in the HA, and its 186 universal benefit, makes it appropriate that it should be a mandatory 187 feature of all reverse tunnel hand-offs. An MIP Registration with the 188 'T' flag set (indicating reverse tunneling) should therefore not cause 189 the existing binding to be overwritten for reverse traffic only, but 190 instead should cause both oFA and nFA CoA bindings to be valid during 191 the reverse hand-off. The lifetime of this fan-in binding (effectively 192 the remaining lifetime of the stale oCoA entry) can be determined in a 193 number of ways. 195 Firstly, it can be set through configuration in the HA for all hand- 196 offs with that HA. This clearly leads to non-optimal fan-in binding 197 lifetimes because the configuration needs to be as short as possible 198 from a HA state maintenance perspective but needs to be long enough to 199 avoid packet loss. If it is configured to high then an opportunity 200 exists for a third party node to illegally inject reverse tunneled 201 packets via that fan-in binding. The configuration therefore needs to 202 take account of a wide range of hand-off topologies and provide some 203 happy medium that will clearly often be non-optimal. 205 A second alternative is to set fan-in lifetime to the remaining 206 lifetime of the oCoA entry from the previous MIP Reg. This requires no 207 additional configuration but does require the HA to maintain two 208 Registration entries. This increases the state load but does so with 209 little gain compared to the configuration option. This is because the 210 remaining lifetime is clearly uncontrolled and could range from a huge 211 value (increasing the risk of injection) through to zero (hand-off 212 occurred at previous lifetime timeout). This is therefore the least 213 preferred option. 215 Thirdly, the lifetime could optionally be dictated by a fan-in lifetime 216 extension that is added by the MN or nFA, which in the latter case is 217 derived from the smooth lifetime in the PFANE, and policed (and 218 potentially reduced) by the HA when compared to the configured value 219 described previously. In effect, we are creating the equivalent of a 220 reverse smooth hand-off within the HA where the nFA CoA would otherwise 221 overwrite the oCoA immediately. This does not however require a PFANE 222 like extension (and a subsequent BU) because the HA is by definition 223 unchanged, and the nCoA is already fully described by the MIP 224 Registration state. 226 Therefore this draft recommends that the fan-in lifetime be controlled 227 based on a short configured default lifetime that can be extended by 228 the HA if so requested by a lifetime in the MIP Reg. The nFA likely has 229 sufficient information from configuration, the PFANE and historical 230 experience about its RTTs to the oFA and the HA, to be able to select 231 an appropriate fan-in lifetime to send to the HA in the MIP Reg. 233 4.2. Reverse smooth hand-off 235 The second optional modification required is to enable a MN to 236 immediately be able to reverse tunnel packets back to the HA when 237 arriving at the nFA. This is to avoid the MN or the nFA having to wait 238 for the MIP Reply from a very distant HA before reverse tunneling 239 traffic to that HA. The HA already has a binding for the MN pointing to 240 the oFA. Therefore to reuse this existing binding the nFA can first 241 reverse tunnel packets to the oFA, using the nFA CoA as the source 242 address and the oFA CoA as the destination address of the 243 encapsulation. The oFA can then change the source address to its own 244 address and set the destination address to that of the HA. The reverse 245 tunneled packets will then arrive correctly at the HA with the correct 246 source CoA in the existing installed bindings. 248 The forward smooth hand-off in [RouteOpt] uses the PFANE extension to 249 cause a BU to be forwarded to the oFA, by the nFA (or the HA), to set 250 up inter-FA forwarding between the oCoA to the nCoA. The oFA is 251 meanwhile required to buffer packets destined to the HoA of the MN 252 until the BU is received, and then forwarding to the nCoA learnt from 253 the BU. Similarly, the BU needs to also trigger reverse smooth 254 forwarding if the MN MIP Registration at the nFA has the 'T' bit set, 255 and reverse tunneling was also previously installed at the oFA. This is 256 appropriate because the reverse smooth forwarding is only required / 257 useful if existing reverse tunneling state is already installed in 258 the oFA and HA. Essentially, the existing 'T' bit in the MIP 259 Registration (for reverse tunneling in [RoutOpt]) also needs to be 260 added as a flag bit into the BU. Note that smooth forwarding in either 261 direction only works if the MN was previously registered at the oFA and 262 was using an oFA CoA. However, reverse smooth forwarding makes sense if 263 the MN is registering via the nFA with either a nFA CoA or a CCoA. 265 The oFA sends the BU with the 'T' bit to the oFA to trigger both 266 forward and reverse inter-FA forwarding. If the nFA is buffering the 267 reverse tunneled packets then it should only start reverse tunneling to 268 the oFA once the mandatory BUack is received. If the MN is buffering 269 the reverse packets then the MN will use the BUack as a trigger to 270 start forwarding. Note that the BUack in [RoutOpt] is addressed to the 271 MN and not the FA and so nFA must snoop the BUack. It would be 272 preferable if the BUack was instead routed via the nFA and any such 273 change in [RoutOpt] will be exploited by this draft. 275 The BUack is mandatory for reverse smooth hand-off because the nFA 276 needs to be sure that the oFA has the necessary state for onward 277 forwarding of the reverse tunneled packets. Whilst waiting for the 278 BUack, the nFA/MN will in addition be waiting for the MIP Reply. The 279 nFA/MN should forward to the oFA only if the BUack is received in 280 advance of a successful MIP Reply, and only whilst that MIP Reply is 281 outstanding. If the MIP Reply is received before the BUack then the nFA 282 should send directly to the HA where reverse tunneling state will have 283 been correctly installed based on the nCoA. In this case the reverse 284 smooth forwarding state in the oFA will not be used and will naturally 285 time out with the forward smooth state. Finally, the buffering element 286 (MN or nFA) needs to have a timer to ensure that it does not wait an 287 excessive amount of time for the reception of either the BUack or the 288 MIP Reply. This is required to ensure that the lossless objective does 289 not affect the competing timeliness objectives. These reverse 290 forwarding rules ensure that the fastest available yet reliable route 291 is always used by the reverse tunneled packets. If the HA are closer 292 than the oFA then the dog-leg inter-FA reverse forwarding will be 293 naturally avoided. If the oFA is significantly closer than the HA then 294 the buffering in the nFA/MN can be minimized by exploiting the existing 295 reverse state. If the MN does not wish to buffer and hence to balance 296 the lossless v timeliness objectives itself then the nFA will naturally 297 undertake this function itself. 299 In the case of the reverse smooth hand-off, and also during a make 300 before break hand-off, the fan-in binding is needed in the oFA to 301 enable packets to be reverse tunneled both from the HoA source address 302 (via the visitor list) as well as from the nCoA source address in the 303 binding cache. This is necessary because the oFA may not have reverse 304 tunneled all packets to the HA before the reception of the BU from the 305 nFA. The oFA fan-in binding is set-up by the BU, has the maximum 306 lifetime of the forward smooth tunneling and is automatically 307 terminated when all outstanding packets from the old link have been 308 encapsulated in the oCoA and sent towards the HA. The associated state 309 is lost when the old link is lost or the MIP Reg lifetime for the oCoA 310 at the oFA times-out. 312 4.3. Packet ordering 314 The reverse smooth hand-off and the fan-in binding can combine to cause 315 re-ordering of packets. This can be minimized by using the following 316 logic but the optimal solution for any deployment will depend on the 317 L2/L3 control model. 319 Firstly, the reverse smooth tunneled packets from the nFA to the oFA 320 should not be forwarded by the oFA towards the HA until the reverse 321 tunneled packets from the old link have all been sent. The MN is in 322 control of which link it uses to send reverse tunneled packets, and 323 knows when it has finished with the old link. The MN can then either 324 act to bring the link down, or it can send an explicit L2 signal so 325 that in either case the oFA can start forwarding the packets that have 326 come from the nFA. An even safer and more universal solution is that 327 the MN only sends reverse tunnel packets over one link at any time 328 during MBB hand-off but this may be unnecessarily overcautious. 330 Secondly, the fan-in binding in conjunction with in-flight packets from 331 both the oFA and the nFA direct to the HA can again cause packet re- 332 ordering. This can be avoided by the nFA delaying using the direct path 333 for a small interval, with one potential value being equal to the BU / 334 BUack RTT. This is a useful measure because the path lengths to the HA 335 from the two neighbouring FAs is likely to be similar and the BU/BUack 336 RTT is representative of the extra path length undertaken by the 337 reverse smooth tunneled packets plus a safety margin. Whilst not 338 deterministic, this measure should be reasonable in general as the aim 339 is simply to minimize rather than absolutely avoid re-ordering. 341 4.4. Signalling Requirements 343 The MN needs to be able to request a smooth hand-off for both forward 344 and reverse traffic. The existing PFANE and the MIP Reg 'T' flag is 345 sufficient for this such that reverse tunneling is never requested 346 independently of forward smooth tunneling. Reverse smooth forwarding is 347 subsequently enabled if the oFA has reverse tunneling state for the MN 348 and the BU has the new 'T' bit set, indicating that the new MIP Reg via 349 the nFA also requested reverse tunneling. 351 The MN does not need to separately signal reverse smooth forwarding 352 because it is only relevant when forward smooth forwarding is 353 requested, and incurs no cost in being signaled with all smooth hand- 354 offs because the nFA is still in control of subsequent reverse packet 355 routing independent of the oFA. The MN and nFA do not need to know in 356 advance if reverse smooth tunneling or fan-in bindings are supported in 357 the oFA because the BU/BUack will enable the nFA discover this, and if 358 the oFA does not support them then the nFA simply forwards to the HA. 360 The MN and nFA do not need to know in advance if fan-in bindings are 361 supported in the HA because the MIP Reg/Rep will enable the nFA to 362 discover this. If the oFA does not support them then the nFA should 363 still forward directly to the HA, after receiving the MIP Reply. 364 Unfortunately, this will potentially cause packets in flight from the 365 oFA to the HA to be lost when the nFA CoA replaces the oFA CoA. The 366 only benefit therefore of advanced knowledge about the HA features is 367 that if they do not support fan-in bindings then it would be better for 368 the nFA to buffer reverse tunnel packets until the MIP Reply is 369 received, and then forward direct to the HA, rather than forward them 370 via the oFA. The FA should therefore cache knowledge of HA fan-in 371 binding support as it learns this from MIP Replies. 373 4.5 Low Latency Hand-off 375 To this point this draft has focused on the smooth hand-off from 376 [RoutOp] and the associated PFANE extension. The MIP wg has in addition 377 defined an alternative hand-off model that is described in [lowLat]. 378 This has alternative signaling models but ultimately still supports 379 inter-FA forwarding and hence can benefit from the reverse inter-FA 380 tunneling defined in this draft. 382 5. New Packet Formats 384 5.1. Binding Update 386 The binding Update message is modified as described below. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type |A|I|M|G|T| Rsv | Lifetime | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Mobile Node Home Address | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Care-of Address | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 + Identification + 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Extensions ... 402 +-+-+-+-+-+-+-+- 404 A new BU flag, the 'T' flag, is added to indicate a request for reverse 405 smooth forwarding of reverse tunneled packets from the nFA via the oFA 406 CoA to the HA. The BU 'T' flag is only set if the MIP Registration to 407 the nFA, that generated the BU also has the 'T' bit set. It is 408 mandatory that a BU with the 'T' bit set must also have the 'A' bit set 409 so that the BU sender has confirmation that the oFA will forward the 410 reverse packets and therefore avoid the nFA forwarding into a dead end. 412 5.2. Binding Acknowledge Message 414 A Binding Acknowledge message is used to acknowledge receipt of a 415 Binding Update message. It SHOULD be sent by a node receiving a 416 Binding Update message in which the acknowledge (A) bit is set; if in 417 addition that message also contains a valid authentication extension 418 and Identification, the Binding Acknowledge MUST be sent. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Reserved | Status | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Mobile Node Home Address | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 + Identification + 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 The format of the Binding Acknowledge message is illustrated above, and 433 is unchanged, apart from extending the allowed values of the status 434 field. The processing is such that if a BU is sent with the 'T' bit set 435 that does not also have the 'A' bit set, then the oFA should still 436 accept the request, if in all other ways correct, and return an 437 acknowledgement. 439 Up-to-date values of the Code field are specified in the most recent 440 "Assigned Numbers" [13]. 442 Proposed new status values are: 444 1x1 reverse smooth not supported 445 1x2 reverse smooth tunnel requested but oFA has no state 447 This raises a problem though because to acknowledge the failure of the 448 reverse smooth tunnel requires the oFA to also fail the forward smooth 449 tunnel to then trigger the nFA to resend a simpler BU just for the 450 forward smooth tunnel. This is because all non-zero status codes 451 represent a failure. It would therefore be better to re-use the design 452 from the Registration Req/Reply, whereby non-zero status codes can 453 indicate a success but carry partial failure information. 455 In this case: 457 0 BU was successful 458 1 Forward BU was successful but reverse failed 459 2 Reverse BU was successful but forward failed 461 5.3 Mobility Agent Advertisement Extension 463 There is no change to the Mobility Agent Advertisement Extension [1]. 464 It simply needs to advertise the 'T' for reverse tunneling as in 465 [RevTun] and the 'S' for smooth hand-off as in [RoutOp]. 467 5.4. Fan-in Lifetime Extension 469 The Fan-in Lifetime Extension MAY optionally be included in a MIP 470 Registration if the 'T' bit is set and the MN is registering via a FA. 471 The Fan-in Lifetime may be built in the FA by copying the PFANE 472 lifetime. In this case, the HA should only accept the Fan-in Lifetime 473 if the nFA and HA share an SA. If the MN does not include the PFANE 474 then the nFA may add the Fan-in Lifetime extension itself. 476 If this extension is absent, and the 'T' bit is set, then the HA should 477 still apply fan-in bindings for a short configured time sufficient to 478 minimize reverse tunnel packet loss during hand-off in the local 479 topology. A suggested default is 1 second. 481 Mobile Nodes, Foreign agents and Home Agents SHOULD support the Fan-in 482 lifetime extension. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type | Length | Lifetime ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Type 491 TBA 493 Length 494 2 496 Lifetime 497 The period of time during which both the existing and the new FA 498 CoA should be valid for incoming reverse tunneled traffic at the 499 HA. This is the number of seconds remaining before the fan-in 500 binding cache entry for the oFA CoA must be considered expired. A 501 value of all ones indicates infinity. A value of zero indicates 502 that the existing binding should be removed and replaced by the 503 new binding in the MIP Registration, effectively preventing a fan- 504 in binding. 506 5.5. New Registration Reply Codes 508 Registration replies from the HA MUST convey if the request for fan-in 509 bindings failed. This is so that the FA can stop forwarding via the 510 oFA and immediately start sending directly to the HA. The new reply 511 codes are defined as follows: 513 Partially successful registration: 515 2 Registration accepted but fan-in bindings unsupported 516 3 Registration accepted but simultaneous and fan-in bindings 517 unsupported 519 Service denied by the foreign agent: 521 None. If reverse smooth BU fails then the oFA should retry 522 without setting the 'T' bit and instead reverse tunnel packets to 523 the HA. 525 Service denied by the Home Agent: 527 None. If fan-in bindings are not supported then the Registration 528 should still succeed. 530 6. IPv6 Considerations 532 Mobile IPv6 [MIPv6] has the use of a CCoA by the MN as the normal 533 method of tunneling due to the better address availability and 534 allocation mechanisms compared to IPv4. IPv6 does not have the notion 535 of a Foreign Agent though, and a Local Mobility Agent and/or a 536 hierarchical mobility agent might instead need to be modified to 537 undertake the reverse smooth functionality defined in this draft. The 538 IPv6 HA should support the automatic invocation of a fan-in binding if 539 reverse tunneling is requested. 541 7. Security Considerations 543 No new security issues are raised by this draft than are already 544 considered in the design of MIPv4 and MIPv6 smooth hand-offs [RoutOpt] 545 and reverse tunneling. The fan-in binding does open up the small chance 546 of a rogue host injecting packets via the stale oCoA entry but this can 547 only be achieved via either a compromised oFA or via any edge node that 548 does not undertake source address checking. There is however no way for 549 such a rogue host to detect when the opportunity to inject such packets 550 exists unless it is able to snoop MIP signaling traffic at the oFA 551 and/or HA. 553 8. Notice Regarding Intellectual Property Rights 555 Flarion's submissions will conform with RFC 2026. Flarion may seek 556 patent protection on some or all of the technical information submitted 557 by its employees in connection with the IETF's standards process. If 558 part(s) of a submission by Flarion is (are) included in a standard and 559 Flarion owns patent(s) and/or pending patent application(s) that are 560 essential to implementation of such included part(s) in said standard, 561 Flarion is prepared to grant a license on fair, reasonable, reciprocal 562 (license back) and non-discriminatory terms on such included part(s). 564 9. References 566 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 567 BCP 9, RFC 2026, October 1996. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997 572 [MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4," RFC3220, 573 January 2002 575 [RevTun] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, 576 revised," Internet RFC 3024, January 2001. 578 [RoutOp] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 579 Internet-Draft, draft-ietf-mobileip-optim-11.txt (work in progress), 6 580 September 2001. 582 [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", 583 Internet-Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, 584 November 2001. 586 [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet- 587 Draft, draft-ietf-mobileip-ipv6-15.txt (work in progress), 2 July 2001. 589 Author's Addresses 591 Alan O'Neill 592 Flarion Technologies 593 Phone: +1 908 947 7033 594 Email: oneill@flarion.com