idnits 2.17.1 draft-oneill-mip-proxyccoa-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 10 longer pages, the longest (page 4) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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 26 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (8 May 2002) is 8023 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: '1' on line 379 -- Looks like a reference, but probably isn't: '2' on line 398 -- Looks like a reference, but probably isn't: '13' on line 486 == Missing Reference: 'RoutOpt' is mentioned on line 506, but not defined == Unused Reference: 'RFC2026' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'NestMIP' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'ConcatMIP' is defined on line 546, 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 (-24) exists of draft-ietf-mobileip-ipv6-16 -- No information found for draft-ietf-oneill-mip-nested - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NestMIP' -- No information found for draft-ietf-oneill-mip-nested - is the name correct? -- Duplicate reference: draft-ietf-oneill-mip-nested, mentioned in 'ConcatMIP', was also mentioned in 'NestMIP'. -- Possible downref: Normative reference to a draft: ref. 'ConcatMIP' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 Internet Draft Flarion Technologies 3 Document: draft-oneill-mip-proxyccoa-00.txt 8 May 2002 4 Expires: Oct 2002 6 Proxy CCoA Tunneling for Mobile IP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 In MIPv4, when a Mobile Node (MN) registers with the 'D' bit, in the 35 MIP Registration to a Home Agent (HA), then the MN wishes to use a 36 Co-located Care-of address (CCoA) with a specific Home Address (HoA). 37 Packets sent to the MN Home Address (HoA) will then be encapsulated in 38 the CCoA by the HA and forwarded directly to the MN. Alternatively, a 39 MN can obtain from the local Foreign Agent(FA) a shared FA CoA for 40 inclusion in its MIP Registration to the FA/HA. In this case, the HA 41 encapsulates to the FA CoA, and the Foreign Agent then decapsulates and 42 delivers the HoA addressed packet unencapsulated to the MN. This draft 43 adds to MIPv4 the ability for the MN to acquire a MN specific FA CoA 44 that provides the MN with a topologically correct local address and 45 whose tunnel encaps/decaps is provided by the FA. This address is 46 called a proxy CCoA (PCCoA) and the associated processing in the MN and 47 FA is called Proxy CCoA tunneling. This capability is applicable to any 48 access technology but is especially useful for wir 49 INDEX 51 Abstract 53 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 55 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 57 4. MIPv4 Proxy CCoA Tunneling. . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Proxy CCoA Negotiation . . . . . . . . . . . . . . . . . . . . 3 59 4.2. Downlink forwarding. . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Uplink forwarding and reverse tunneling . . . . . . . . . . . 5 61 4.4. PCCoAs and smooth hand-off . . . . . . . . . . . . . . . . . . 5 62 4.5. PCCoA Advantages . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. New Packet Formats 65 5.1. Mobility Agent Advertisement Extension . . . . . . . . . . . . 7 66 5.2. Proxy CCoA Extension . . . . . . . . . . . . . . . . . . . . . 7 67 5.3. New Registration Reply Codes . . . . . . . . . . . . . . . . . 8 68 5.4. Binding Update Message . . . . . . . . . . . . . . . . . . . . 8 69 5.5. Binding Acknowledgement Message. . . . . . . . . . . . . . . . 9 71 6. MIPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 9 74 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 In MIPv4, when a MN registers with the 'D' bit, in the MIP Registration 79 to a 80 Home Agent through a Foreign Agent, then the MN wishes to use a 81 Co-located Care-of address (CCoA) with a specific Home Address 82 (HoA). Packets sent to the MN Home Address (HoA) will then be 83 encapsulated in the CCoA by the HA and forwarded direct to the MN 84 via the best route from any FA advertising the subnet of that 85 address. In addition, the MN can use that CCoA as a topologically 86 correct source/destination address for local access on the visited 87 subnet. In CCoA based reverse tunneling, the MN can encapsulate the 88 HoA itself into its Co-located Care of Address (CCoA) to cause the 89 packet to be reverse tunneled to the HA. The MN can in addition 90 leave the HoA unencapsulated so that the FA delivers the packet 91 natively and unencapsulated to the destination address. This is 92 known as selective reverse tunneling and is possible whether or not 93 the MN registers via the local FA. 95 Alternatively, a MN can use a shared FA CoA advertised to it by the 96 FA in an Agent Advertisement. In this case, the HA encapsulates to 97 the FA CoA who then decapsulates and delivers the HoA addressed 98 packet natively unencapsulated to the MN. When reverse tunneling, 99 the MN can select during MIP registration between the default Direct 100 Delivery Style and the optional Encapsulating Delivery Style. In 101 Direct Delivery Style, the MN sends packets unencapsulated via the 102 FA using the HoA as a source address, and the FA undertakes the 103 encapsulation of those packets towards the HA using the FA CoA as 104 the source address of the tunnel. 106 In Encapsulating Delivery Style, the MN instead encapsulates packets 107 with the 108 HoA as a source address towards the FA, which after decapsulating, 109 inspects the visitor list and then re-encapsulates into a tunnel 110 with the FA CoA as the source address. In addition, once 111 Encapsulating Delivery Style has been negotiated with the FA, then 112 the MN can selectively bypass reverse tunneling by sending packets 113 unencapsulated from the HoA. 115 The MN and the FA in existing MIP specs are therefore able to 116 selectively send and receive packets, either unencapsulated, or 117 encapsulated using the HoA as an inner source/destination address 118 and a CoA as the outer address. When sending unencapsulated between 119 each other, the MN and the FA avoid the additional bandwidth 120 incurred by a tunnel header. By using a FA CoA, the MN is however 121 deprived of a local topologically correct address (so preserving 122 address space) but is able to selectively avoid tunneling over the 123 access link, which is beneficial in cellular and other access 124 systems. By using a CCoA, the MN gets a topologically correct 125 address (where addresses are available) but then incurs the overhead 126 of the additional tunnel header for incoming traffic and during any 127 reverse tunneling operations. The use of a MN specific MIP tunnel 128 address can also be useful for QoS support. 130 What is missing in MIPv4 is the ability for the MN to acquire a MN 131 specific FA CoA as a CCoA, that provides the MN with a topologically 132 correct local address and whose tunnel encaps/decaps is provided by 133 the FA. This address is here called a proxy CCoA (PCCoA) and the 134 associated processing in the MN and FA is called Proxy CCoA 135 tunneling. This draft also describes reverse tunneling and smooth 136 hand-off extensions based on the PCCoA. 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 142 this document are to be interpreted as described in RFC-2119 143 [RFC2119]. 145 3. Terminology used in this document 147 Much of the terminology used in this document borrows from Mobile 148 IPv4/v6. The following introduces additional terminology. 150 PCCoA - Proxy Co-located Care of Address PCCoA tunnelling - tunnel 151 processing carried out by the FA 153 4. MIPv4 Proxy CCoA Capability 155 4.1 Proxy CCoA Negotiation 157 The negotiation of a PCCoA is a local matter between the MN and the FA 158 and 159 there is no known reason why the HA should in any way be informed of 160 the optional configuration of the PCCoA capability by the MN on the 161 local FA. The HA simply detects a MIP request, via the FA, for CCoA 162 tunneling. According to Mobile IPv4 [MIPv4] and Reverse tunneling 163 [RevTun], the HA will expect the following tunneling to occur. 165 INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 166 2002 168 The HA will encapsulate all permitted unicast, multicast and 169 broadcast packets, intended for the MN HoA, in the CCoA included 170 within the associated MIP Registrations. The HA then sends the 171 packets to this CCoA from the source address of the HA. If reverse 172 tunneling is enabled then the HA will decapsulate all permitted 173 unicast, multicast and broadcast packets that are tunneled from the 174 CCoA to the HA address, with the inner source address matching the 175 HoA of the MN. 177 From the perspective of the HA, the CCoA is located at the MN and so 178 requires 179 the MIP signaling to have the 'D' bit set. However, as far as the FA 180 is concerned the CoA is actually a PCCoA, which as far as Internet 181 routing is concerned can be considered to be a MN specific FA CoA. 182 The MN allocated this address is on a link-layer directly attached 183 to the FA and so the FA can also enable the MN to make use of this 184 MN specific FA CoA as a source/destination address for local 185 communications. Therefore, the HA sees the PCCoA as a CCoA, the FA 186 sees the PCCoA as a special MN specific FA CoA and the MN treats the 187 PCCoA as an ordinary interface address. A specific implementation of 188 the PCCoA process would be to simply move the tunnel/detunneling 189 process for a CCoA to the other end of the link (from the MN to the 190 FA) but in all other ways treat the address as a CCoA. This is then 191 a link specific change in much the same way that header compression 192 is a link specific function. 194 Proxy CCoA tunneling is therefore possible in MIP if the MN obtains 195 a CCoA from the FA subnet, the MN then registers for PCCoA service 196 via the FA, and that FA is able to support PCCoA processing for that 197 CCoA. The HA forwarding and tunnel processing is unaffected by the 198 changes in this draft. The availability of the PCCoA capability is 199 advertised by the FA in a FAA, by setting the new 'P' bit, or could 200 be triggered via an MIP extension, configuration, PPP, DHCP or other 201 signalling. To request PCCoA service, the MN MUST register via the 202 FA, whether or not this is mandated by the FAA 'R' bit, so that the 203 FA can undertake correct PCCoA processing. The MN can be allocated a 204 PCCoA either by a unicasted MIP FAA that includes a MN specific FA 205 CoA, through a DHCP server with a FA specific prefix, or by any 206 other means that can ensure the address is uniquely bound to a MN on 207 that FA. 209 Proxy CCoA tunneling is negotiated by the MN by including the Proxy 210 CCoA extension in the MIP Registration as well as setting the 'D' 211 flag used to signal the use of a CCoA. This structure is required so 212 that the FA can remove the PCCoA extension whilst leaving the 'D' 213 bit so that the HA will continue to treat the MN as if it had a 214 CCoA. In the future, if HAs require knowledge of the PCCoA 215 mechanism, and sufficient deployment has / will occur, then the 216 extension mechanism could be replaced by instead assigning and 217 setting a new 'P' flag bit (proxy CCoA) in the MIP Registration, as 218 well as setting the 'D' bit (CCoA). 220 The MIP CCoA Registration, when acknowledged by both the HA and the 221 FA in the MIP Reply, causes the FA to store both the HoA and the 222 PCCoA in the visitor list for that MN. Both the HoA and the PCCoA 223 can be used as source / destination addresses to/from the MN. The 224 HoA is used for remote access to/from the HA whilst the PCCoA can be 225 used for topologically correct local access whilst the MN remains at 226 that FA. 228 4.2 Downlink Forwarding 230 Downlink packets addressed to the HoA, arrive at the FA via the HA, 231 encapsulated in the PCCoA of the MN. Downlink packets (local traffic 232 using the PCCoA as a source/dest address) otherwise arrive directly, 233 and unencapsulated, at the FA. The FA inspects the PCCoA and 234 searches for it in the visitor list. If the packet is unencapsulated 235 then it is simply forwarded to the owning MN. If the packet is 236 encapsulated then it is first decapsulated and the inner unicast 237 destination header inspected to ensure it matches the HoA state for 238 that MN. If the decapsulated packet is broadcast/multicast, and the 239 MIP flags for that MN have requested broadcast traffic and/or the MN 240 is a member of that multicast group, then the packet is forwarded 241 unencapsulated to the MN over a point-to-point access medium but 242 must be sent in its encapsulated form over a broadcast medium. 244 4.3 Uplink forwarding and reverse tunneling 246 Uplink unicast packets from the HoA are sent unencapsulated via the FA 247 and 248 injected into the routing fabric unencapsulated. In the case of 249 reverse tunneling, the FA encapsulates the permitted unicast, 250 broadcast and multicast packets with the PCCoA of the MN as the 251 tunnel source address, and HA as the tunnel destination address. 252 This is so that the packets will match the registered binding in the 253 HA. Broadcast/multicast packets sent over a broadcast access medium 254 must be encapsulated in the HoA and sent to the shared FA CoA where 255 they are decapsulated, the visitor list and group membership for 256 that MN inspected, and permitted packets re-encapsulated to the HA, 257 as before, within the PCCoA. Note that with proxy CCoA tunneling the 258 option for selective reverse tunneling from the MN is lost. However, 259 this ability can be re-instated if the MN provides the FA with a 260 classifier that specifically defines which of the MNs uplink traffic 261 SHOULD NOT be reverse tunneled. This is achieved by first selecting 262 Reverse tunneling for a specific HoA by setting the 'T' bit as 263 normal in the MIP Registration, and then including a set of excluded 264 classifiers in the form of quintuples describing the uplink unicast 265 header. 267 4.4 PCCoAs and smooth Hand-offs 269 Smooth hand-offs [RoutOp] enable a MN that was previously registered 270 at the 271 old Foreign Agent (oFA) with an oFA CoA, to request the forwarding 272 of packets, sent to the MN HoA and decapsulated from the oFA HoA, to 273 the MNs new CoA. This means however, that smooth hand-offs are not 274 supported for a MN with a CCoA that is either registered or 275 unregistered at the oFA. This is because a FA is not allowed to 276 decapsulate from the oCCoA and forward to the new CoA at the new 277 point of attachment. Smooth forwarding could be supported by instead 278 having the oFA additionally encapsulate the oCCoA to the nCoA but 279 this clearly adds overhead and requires the nFA to have knowledge of 280 the oCCoA to correctly forward in the case of the MN acquiring a nFA 281 CoA. 283 The PCCoA capability in contrast brings the required functionality to 284 the FA 285 to support the smooth forwarding of CCoAs, if the MN registered via 286 the oFA, irrespective of whether or not the MN is using a CCoA or a 287 PCCoA. In the case of a normal CCoA, the FA can still transiently 288 support the PCCoA capability and automatically transition the CCoA 289 to a PCCoA when the BU is received from the nFA or directly from the 290 MN. This is only possible if the CCoA is uniquely advertised by that 291 FA. The incoming BU that includes the nCoA will then create a 292 binding between the HoA (and indirectly the oCCoA) and the nCCoA, 293 such that the oFA can decapsulate everything from the oCCoA and re- 294 encapsulate into the nCoA before forwarding. Broadcast / multicast 295 traffic is handled by checking the MIP flags and the HoA group 296 membership and re- encapsulating all permitted packets. The oFA will 297 also encapsulate into the nCoA all packets that are received 298 unencapsulated with a destination address equal to the oCCoA (local 299 traffic using the oCCoA as a network address) during the shorter of 300 the lifetime of the smooth hand-off or the delay until the oCCoA is 301 re-allocated. The request to trigger transient PCCoA support is 302 implicit at the oFA on the reception of a BU. In the case of a MN 303 that was using a PCCoA at the oFA, the meaning of the BU is again 304 implicit and the oFA simply proceeds as for the oCCoA after the 305 PCCoA transition. 307 If the BU is from the MN then it is for a CCoA at a MN that is not 308 registering via the nFA. This however does not affect this hand-off 309 but will affect subsequent hand-offs because the PCCoA transient 310 forwarding is only possible if a MN registers via a FA. If the BU is 311 originated by the nFA then the nCoA in the BU is either a nFA CoA or 312 a nPCCoA, which affects the processing at the oFA. This is because 313 the sending of a nFA CoA implies that the nFA does not support 314 PCCoAs and therefore the oFA (which does support PCCoAs) should 315 undertake all processing required to convert the oCCoA or the oPCCoA 316 received traffic into a format that will be correctly received and 317 forwarded by the nFA. This means that any broadcast/multicast 318 traffic must be first encapsulated into the HoA of the MN before 319 encapsulating into the nFA CoA. It also means that the BU must 320 specifically indicate whether it is for a FA CoA or a CCoA/PCCoA by 321 setting the new 'D' bit. The 'D' bit is set in the BU if the MIP 322 Registration via the nFA had either the 'D' or the 'P' bit set, or 323 is set by the MN that is using a CCoA. The difference at the nFA 324 between a CCoA and a PCCoA is kept within the nFA, and between the 325 nFA and the MN that requested a PCCoA by including the PCCoA 326 extension in its registration. 328 The BU is otherwise unchanged. In addition, the mandatory BUack and 329 its status codes do not need to be extended because the failure of 330 the BU for technical reasons at the oFA, for a CCoA, directly 331 implies a PCCoA processing failure. 333 When considering reverse smooth tunneling, as described in 334 , the mechanisms are unchanged for PCCoAs other 336 than that the reverse smooth tunneling is now between MN specific 337 and shared FA CoAs, rather than just between shared FA CoAs. The 338 smooth BU will contain both 'T' and 'D' bits set and the reverse 339 tunneling will be from the nCCoA to the oFA CoA and then from the 340 oCCoA/PCCoA to the GFA/HA. Broadcast/multicast must be reverse 341 tunneled according to the required processing at the receiver for 342 the CoA type. 344 Clearly however, the PCCoA capability is only available when the FA 345 is both able (eg IPSEC) and trusted to perform the tunnel management 346 for the MN. 348 INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 349 2002 351 4.5 PCCoA Advantages 353 These procedures avoid the CCoA encapsulation for remote access traffic 354 over 355 the access link. In addition, the FA is now in a position to police 356 traffic addressed to a specific HoA from a specific gateway, via the 357 PCCoA, before it is sent to the MN, and can also effectively support 358 smooth hand-offs for all CCoAs. In the case of broadcast/multicast 359 the FA is now in a position to avoid the additional encapsulation 360 over the air in both directions when the access medium supports 361 point to point link layer connectivity to/from the MN. Finally, the 362 MN specific (PCCoA) MIP encapsulation simplifies address-based QoS 363 support in the network between the HA and the MN. 365 5. New Packet Formats 367 5.1. Mobility Agent Advertisement Extension 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Length | Sequence Number | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Lifetime |R|B|H|F|M|G|r|T|S|I|P| reserved| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | zero or more Care-of Addresses | 377 | ... | 379 The only change to the Mobility Agent Advertisement Extension [1] is 380 the additional 'P' bit: 382 P Agent offers proxy CCoA tunneling. 384 A foreign agent that sets the 'P' bit MUST support the proxy CCoA 385 tunneling for any CCoAs that are uniquely advertised into the 386 routing system by that FA. Using this information, a mobile node is 387 able to choose a foreign agent that supports proxy CCoA tunneling. 388 Notice that if a mobile node does not understand this bit, it simply 389 ignores it as per [MIPv4] and reverts to normal CCoA behaviour. The 390 ordering of addresses in FAAs is according to the relevant MIP specs 391 and is not altered by this draft. 393 5.2. Proxy CCoA Extension 395 The Proxy CCoA Extension MAY ONLY be included if the 'D' bit is set 396 and the MN is registering via the FA . If this extension is absent, 397 and the 'D' bit is set, then normal CCoA behaviour from Mobile IP 398 [MIPv4] and RevTun[2] is undertaken. The Encapsulating Delivery 399 Style extension and the Proxy CCoA extension MUST NOT be in the same 400 registration. Mobile Nodes and Foreign agents SHOULD support the 401 Proxy CCoA Extension. 403 0 1 404 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | Type: TBA, Length 0. 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 5.3. New Registration Reply Codes 410 Foreign agent registration replies MUST convey if the 411 PCCoA request failed. These new reply codes are defined: 413 Service denied by the foreign agent: 415 X1 PCCoA capability is mandatory 416 X2 PCCoA capability is administratively barred 417 X3 submitted PCCoA is not routable at the FA 418 X4 submitted PCCoA unavailable 420 In response to a Registration Request with the 'D' bit set, and 421 accompanied 422 by the PCCoA extension, mobile nodes may receive (and MUST accept) 423 code 70 (poorly formed request) from foreign agents. However, 424 foreign agents that support PCCoA capability MUST use the 425 appropriate new code. 427 If the MN registers via the FA with the 'D' bit set, and does not 428 include the PCCoA extension, then code X1 should be returned to the 429 MN to cause the MN to include the extension in any new request. If 430 the MN does include the PCCoA extension and it is either 431 administratively barred from using this capability (through either 432 foreign or home AAA policy state), then code X2 should be returned 433 to cause the MN to modify the Registration. Code X3 should be used 434 if the MN attempts to use as a CCoA an address that is not routable 435 at the FA, and code X4 should be used if the included address is 436 already being used by another MN. In either case, the MN should 437 attempt to get a new PCCoA for the local FA, either from the FA or 438 via some other method. 440 5.4. Binding Update Message 442 The binding Update message is modified as described below. A new BU 443 flag, the 444 'D' flag, is added to indicate a request for smooth forwarding of 445 the oCoA to the nCCoA/nPCCoA. The BU 'D' flag is only set if the MIP 446 Registration to the nFA, that generated the BU also has the 'D' bit 447 set. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type |A|I|M|G|D| Rsv | Lifetime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Mobile Node Home Address | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Care-of Address | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 + Identification + 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Extensions ... 463 +-+-+-+-+-+-+-+- 464 It is mandatory that a BU with the 'D' bit set must also have the 'A' 465 bit set so that the BU sender has confirmation that the forwarding 466 will occur. The absence of this flag indicates that the CoA in the 467 BU is a nFA CoA. If the oCoA is either a CCoA or a PCCoA, then the 468 absence of this flag causes the oFA to try to convert any arriving 469 flows so that they are compatible with the destination nFA CoA. This 470 specifically means that any permitted broadcast/multicast traffic, 471 and any packets with the oCCoA/PCCoA as an unencapsulated 472 destination address (local traffic), must first be encapsulated into 473 the HoA before being additionally encapsulated into the nFA CoA in 474 the BU. 476 5.5. Binding Acknowledge Message 478 The format of the Binding Acknowledge message is unchanged, apart from 479 extending the allowed values of the status field to cover the same 480 cases as identified for the MIP Reg. The processing is such that if 481 a BU is sent with the 'D' bit set that does not also have the 'A' 482 bit set, then the oFA should still accept the request, if in all 483 other ways correct, and return an acknowledgement. 485 Up-to-date values of the Code field are specified in the most recent 486 "Assigned Numbers" [13]. 488 6. IPv6 Considerations 490 IPv6 has the use of a CCoA by the MN as the normal method of tunneling 491 due to 492 the better address availability and allocation mechanisms compared 493 to IPv4. IPv6 does not have the notion of a Foreign Agent though, 494 but an access router or a Local Mobility Agent could instead be 495 modified to undertake the PCCoA functionality defined in this draft, 496 with the obvious required changes. In the case of hand-off, the 497 option of receiving a BU containing a nFA CoA is not possible and so 498 the 'D' bit is not required to distinguish between the two CoA types 499 (nFA CoA or a CCoA/PCCoA). 501 7. Security Considerations 503 No new security issues are raised by this draft than are already 504 considered 505 in the design of Mobile IPv4 [MIPv4], MIPv4 reverse tunneling 506 [RevTun], MIP Route Optimization [RoutOpt] and Mobile IPv6 [MIPv6]. 508 8. Notice Regarding Intellectual Property Rights 510 Flarion's submissions will conform with RFC 2026. Flarion may seek 511 patent protection on some or all of the technical information 512 submitted by its employees in connection with the IETF's standards 513 process. If part(s) of a submission by Flarion is (are) included in 514 a standard and Flarion owns patent(s) and/or pending patent 515 application(s) that are essential to implementation of such included 516 part(s) in said standard, Flarion is prepared to grant a license on 517 fair, reasonable, reciprocal (license back) and non- discriminatory 518 terms on such included part(s). 520 9. References 522 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 523 BCP 9, 524 RFC 2026, October 1996. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997 529 [MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4," 530 RFC3220, January 2002 532 [RevTun] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, 533 revised," Internet RFC 3024, January 2001. 535 [RoutOp] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 536 Internet- Draft, draft-ietf-mobileip-optim-11.txt (work in 537 progress), 6 September 2001. 539 [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", 540 Internet-Draft, draft-ietf-mobileip-ipv6-16.txt (work in progress), 541 22 March 2002. 543 [NestMIP] A.W. O'Neill, ``Nested MIP for mobility management," 544 Internet- draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. 546 [ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility 547 management," Internet-draft, draft-ietf-oneill-mip-nested-00.txt, 548 May 2002. 550 Author's Addresses 552 Alan O'Neill 553 Flarion Technologies 554 Phone: +1 908 947 7033 555 Email: oneill@flarion.com