idnits 2.17.1 draft-petri-mobileip-pipe-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 13 longer pages, the longest (page 12) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 67 has weird spacing: '...3], and to tr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Bernhard Petri 2 INTERNET-DRAFT Siemens AG 3 4 Date: Jan. 20, 2000 6 Expires: July 2000 8 Private IP Encapsulation within IP (PIPE) 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 RFC 2026. 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 Abstract 33 RFC 2003 specifies a method by which an IP datagram may be 34 encapsulated (carried as payload) within an IP datagram. This is a 35 means to alter the normal IP routing for datagrams, by delivering 36 them to an intermediate destination that would otherwise not be 37 selected by the (network part of the) IP Destination Address field in 38 the original IP header. 40 This draft allows to extend this encapsulation mechanism also for 41 private IP addresses. 43 1. Introduction 45 [RFC 2003] specifies a method by which an IP datagram may be 46 encapsulated (carried as payload) within an IP datagram. 47 Encapsulation is suggested as a means to alter the normal IP routing 48 for datagrams, by delivering them to an intermediate destination that 49 would otherwise not be selected based on the (network part of the) IP 50 Destination Address field in the original IP header. 52 Once the encapsulated datagram arrives at this intermediate 53 destination node, it is decapsulated, yielding the original IP 54 datagram, which is then delivered to the destination indicated by the 55 original Destination Address field. 57 [RFC 2003] only allows to encapsulate public IP addresses within IP. 58 However, current IP solutions often use non-unique private IP 59 addresses, e.g. taken from the address space reserved for this 60 purpose in [RFC 1918]. These private IP addresses typically are 61 unique within a private Intranet, e.g. behind a firewall / Network 62 Address Translator (NAT), but are not globally unique and not 63 globally routable in the Internet. 65 This draft therefore outlines an extension of [RFC 2003] which allows 66 to encapsulate and decapsulate such private IP addresses in the same 67 way as described in [RFC 2003], and to transfer them across the 68 public Internet (also referred to as "tunneling" in RFC 2003). 69 Behaviour not explicitly mentioned in this draft applies as specified 70 in [RFC 2003]. 72 2. Motivation and Solution Overview 74 2.1 Motivation: Mobility Applications Using Private IP Addresses 76 It is expected that there may be various applications which will be 77 able to benefit from the PIPE encapsulation mechanism outlined in 78 this draft. An important initial application will be the support of 79 mobile nodes having obtained private IP addresses within a foreign 80 network and/or using private IP addresses in their home network (see 81 also section 2 of [RFC 2003]). 83 Figure 1 shows an example of a basic tunneling/encapsulation case 84 where a private IP address is translated and encapsulated through a 85 public IP tunnel; within the framework of mobility applications, the 86 source might e.g. be a foreign agent registering at the home agent 87 as the destination, or the source might e.g. be the home agent 88 forwarding data packets to the foreign agent as the destination. 90 The terms "encapsulator" and "decapsulator" are used as defined in 91 [RFC 2003]. It should be noted that the encapsulator - as the entry 92 point of the tunnel - also performs an address resolution function, 93 in this case between private und public IP addressing. The particular 94 resolution functions used by the encapsulator are outside the scope 95 of this draft. 97 private IP private IP in IP private IP 98 | | | 99 source ---> encapsulator --------> decapsulator ---> destination 101 Figure 1: Example for encapsulation of private IP in IP 103 In Figure 1, the "private IP" address realm between source and 104 encapsulator may or may not be the same "private IP" address realm as 105 the one between decapsulator and destination. 107 2.2 Identification of Private Addressing Realms 109 A major problem of the use of private IP addresses is that they are 110 not globally unique, and that a decapsulator receiving an 111 encapsulated private IP address would usually not know, to which 112 address space a private IP address belongs to. In Figure 1 above, the 113 decapsulator will usually not be able to derive the particular 114 private addressing realm from its knowledge about the begin of the 115 tunnel. 117 Similar problems had already emerged within the Internetwork over 118 NBMA (ION) area of the IETF, and a solution had been developed using 119 a global identification scheme for IP-VPNs which is outlined in [RFC 120 2685]. This scheme uses an identifier ("VPN-ID") to identify a 121 private network, typically with the objective to provide a related 122 VPN service. The scheme is based on a well-known OUI/index mechanism 123 as e.g. also used for MAC addresses, or for the Interface ID of IPv6 124 addresses. The VPN-ID consists of a 7-octet format which is split 125 into a 3-octet OUI of a "VPN authority", followed by a 4-octet index 126 allocated by that authority. 128 This draft proposes to also use this identification scheme for the 129 indication of the particular address realm a private IP address 130 belongs to, when being encapsulated and being transferred across the 131 internet. Since private IP addresses are assumed to be unique within 132 that particular private network, it is easy to attach a VPN-ID to 133 them, e.g. by using the VPN-related OUI of the owner of that network. 135 2.3. Example: Private IP Interconnection 137 This example is intended to illustrate and motivate the generic 138 solution specified in sections 3 ff below. In this particular 139 example, the configuration shown in Figure 1 is taken, and it is 140 assumed that both the source and destination belong to the same 141 private address realm "PR1". 143 Two different cases for the IP-IP tunnels can be distinguished: 145 a) The decapsulator may be configured in a way that all inner IP 146 header addresses received via IP-IP tunnels, are assumed to belong 147 to one particular IP address space (either a private IP address 148 space or the public IP addressing). In this case, the encapsulator 149 will only insert IP datagrams from that particular address space 150 into the IP-IP tunnel. 152 b) No particular IP address space is pre-associated with the IP-IP 153 tunnel. This configuration option applies in cases where the 154 encapsulator might send IP datagrams for different address spaces 155 (e.g. public and private) via the IP-IP tunnel to a decapsulator. 157 In case a), IP-IP encapsulation is applied in a similar way as 158 specified in section 3 of [RFC 2003], with the difference that in 159 this example, the IP addresses within the inner IP header are 160 configured to belong to the private IP address space "PR1" rather 161 than to public IP addressing. 163 In order to encapsulate a private IP datagram into an IP-IP tunnel in 164 case b), an outer IP header is inserted by the encapsulator before 165 the datagram's existing private IP header, as follows: 167 Public IP Network 169 Private IP Network "PR1" +---------------------------+ 170 | | 171 | Outer IP Header | 172 | | 173 +--------+------------------+ 174 | Sel. | VPN-OUI | 175 +--------+------------------+ 176 | VPN index | 177 +---------------------------+ +---------------------------+ 178 | | | | 179 | private IP Header (PR1) | | private IP Header (PR1) | 180 | | | | 181 +---------------------------+ ====> +---------------------------+ 182 | | | | 183 | | | | 184 | IP Payload | | IP Payload | 185 | | | | 186 | | | | 187 +---------------------------+ +---------------------------+ 189 Figure 2: Example for Private IP-IP Encapsulation 191 The detailed formats for the fields shown in Figure 2 are specified 192 in section 3 below. The Selector field ("Sel.") serves as 193 discriminator / selector indicating which types of addresses are used 194 in the inner IP header. The VPN-Identifier (VPN-ID), consisting of 195 VPN-OUI and VPN index, in this example shows a value identifying PR1. 197 3. Private IP-IP Encapsulation (PIPE) 199 3.1 Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in [RFC 2119]. 205 In this document, the following definitions and acronyms are used: 207 Default Addressing Realm -- this is the configured addressing realm a 208 particular (sent or received) source / destination IP address is 209 assumed to belong to, unless another addressing realm is explicitly 210 indicated by a VPN-ID with the mechanisms specified below. In case of 211 [RFC 2003], the default addressing realm is the public IP addressing. 213 Explicitly Indicated Addressing Realm -- this is the addressing realm 214 specified by a VPN-ID related to a particular sent or received source 215 / destination IP address. 217 VPN-Identifier (VPN-ID) -- this term is specified in [RFC 2685], and 218 is used in this document for the identification of a particular 219 Explicitly Indicated Addressing Realm. 221 Other terms, like e.g. "encapsulator", "decapsulator", "inner IP 222 header" and "outer IP header" are used as specified in section 3 of 223 [RFC 2003]. 225 3.2 Configuration Options and Backward Compatibility 227 This draft outlines a backward compatible extension of [RFC 2003] for 228 the use of private IP addresses. Behaviour not explicitly mentioned 229 in this draft applies as specified in [RFC 2003]. 231 As indicated in [RFC 2003], IP-IP tunnels require knowledge about the 232 decapsulation capabilities at the endpoint of the tunnel. For this 233 document, 3 different configuration options are distinguished which 234 determine how source and destination IP addresses, indicated in the 235 inner IP header, are interpreted. 237 (1)All source and destination addresses, both in the inner and 238 outer IP headers, are interpreted as being public IP addresses. 239 Support of this configuration option IS REQUIRED for the case of 240 communication with legacy [RFC 2003] devices. 242 (2)All indicated source and destination IP addresses, indicated in 243 the inner or outer header of IP-IP tunnels, are assumed to belong 244 to one particular Default Addressing Realm. This configuration 245 option MUST e.g. be selected if either the encapsulator or the 246 decapsulator is not able to process VPN-IDs. The Default 247 Addressing Realm may be the public Internet addressing (as in RFC 248 2003) or any other private IP addressing realm. The Default 249 Addressing Realm for the outer IP header is that of the network 250 between Encapsulator and Decapsulator. 252 (3) Indicated source IP addresses may belong to an Explicitly 253 Indicated Addressing Realm or to the Default Addressing Realm; 254 indicated destination IP addresses may also belong to an Explicitly 255 Indicated Addressing Realm or to the Default Addressing Realm. This 256 is the most general case. 258 For equipment complying to this specification, it IS REQUIRED to 259 support configuration options (1) and (2), and it is RECOMMENDED to 260 also support option (3). Support of option (3) IS REQUIRED if more 261 than one addressing realm is to be supported by IP-IP tunnels. 263 The main purpose of configuration option (1) is to ensure 264 interoperability with legacy [RFC 2003] devices. For configuration 265 option (1), the IP in IP encapsulation formats specified in [RFC 266 2003] MUST be used. 268 The formats for configuration options (2) and (3) are outlined in 269 section 3.3 below. For configuration options (2) and (3), Default 270 Addressing Realms for the inner source and destination IP addresses 271 MUST be preallocated. Note that the Default Addressing Realms for 272 source and destination MAY be different. 274 For all 3 options, the format of the inner "IP header" and "IP 275 payload" fields MUST be coded as specified in section 3 of [RFC 276 2003]. 278 3.3 PIPE Encapsulation Formats 280 For the formats used in configuration options (2) and (3), 5 281 different cases can be distinguished (see subsections 3.3.1 - 3.3.5 282 below). For all 5 cases, the "Protocol" field of the outer IP header 283 (identifying the next level protocol) MUST be set to the value: .. 284 . 286 The Selector Byte ("Sel."), specified below, is used to distinguish 287 between these cases: 289 3.3.1 Default Source and Destination Address 291 If for both source and destination address the Default Addressing 292 Realm is used, the encapsulation format of [RFC 2003] applies. Note 293 that unlike in [RFC 2003], the inner header IP addresses in this case 294 are not automatically assumed to be public IP addresses, but are 295 interpreted according to the Default Address Realm(s). It is not 296 precluded that the Default Address Realms for the source and 297 destination addresses are different. 299 For configuration option (2), this is the only possible format. 301 3.3.2 Explicitly Indicated Source and Destination Adress 302 (Same Realm) 304 If both the source and destination IP address are to be indicated 305 explicitly, and belong to the same addressing realm, the following 306 encapsulation format SHOULD be used: 308 +---------------------------+ 309 | | 310 | Outer IP Header | 311 | | 312 +------+--------------------+ 313 | Sel. | VPN-OUI | 314 +------+--------------------+ 315 | VPN index | 316 +---------------------------+ 317 | | 318 | Inner IP Header | 319 | | 320 +---------------------------+ 321 | | 322 | | 323 | IP Payload | 324 | | 325 | | 326 +---------------------------+ 328 Figure 3: Private IP-IP Encapsulation Format (Case 2) 330 Outer IP Header: as in [RFC 2003] 331 Sel.: Selector, value to be allocated by IANA: 332 tentatively: 0xE0 333 (= explicitly indicated source / destination address, 334 same addressing realm) 335 VPN-OUI, VPN index: as in [RFC 2685] 336 (refers to both source and destination IP address) 338 In addition to the format specified above, the format specified in 339 section 3.3.5 below MAY instead by used in certain cases. 341 3.3.3 Default Source Adress, Explicit Destination Address 343 If only the destination address is to be indicated explicitly, the 344 following encapsulation format MUST be used: 346 +---------------------------+ 347 | | 348 | Outer IP Header | 349 | | 350 +------+--------------------+ 351 | Sel. | VPN-OUI | 352 +------+--------------------+ 353 | VPN index | 354 +---------------------------+ 355 | | 356 | Inner IP Header | 357 | | 358 +---------------------------+ 359 | | 360 | | 361 | IP Payload | 362 | | 363 | | 364 +---------------------------+ 366 Figure 4: Private IP-IP Encapsulation Format (Case 3) 368 Outer IP Header: as in [RFC 2003] 369 Sel.: Selector, value to be allocated by IANA: 370 tentatively: 0xE1 371 (=default source, explicitly indicated destination) 372 VPN-OUI, VPN index: as in [RFC 2685], refers to destination only 374 3.3.4 Explicit Source Adress, Default Destination Address 376 If only the source address is to be indicated explicitly, the 377 following encapsulation format MUST be used: 379 +---------------------------+ 380 | | 381 | Outer IP Header | 382 | | 383 +------+--------------------+ 384 | Sel. | VPN-OUI | 385 +------+--------------------+ 386 | VPN index | 387 +---------------------------+ 388 | | 389 | Inner IP Header | 390 | | 391 +---------------------------+ 392 | | 393 | | 394 | IP Payload | 395 | | 396 | | 397 +---------------------------+ 399 Figure 5: Private IP-IP Encapsulation Format (Case 4) 401 Outer IP Header: as in [RFC 2003] 402 Sel.: Selector, value to be allocated by IANA: 403 tentatively: 0xE2 404 (=explicitly indicated source, default destination) 405 VPN-OUI, VPN index: as in [RFC 2685], refers to source only 407 3.3.5 Explicitly Indicated Source and Destination Address 408 (Different Realms) 410 If both the source and the destination address are to be indicated 411 explicitly, and belong to different addressing realms, the following 412 encapsulation format MUST be used: 414 +---------------------------+ 415 | | 416 | Outer IP Header | 417 | | 418 +------+--------------------+ 419 | Sel. | VPN-OUI (S) | 420 +------+--------------------+ 421 | VPN index (S) | 422 +---------------------------+ 423 | Pad | VPN-OUI (D) | 424 +------+--------------------+ 425 | VPN index (D) | 426 +---------------------------+ 427 | | 428 | Inner IP Header | 429 | | 430 +---------------------------+ 431 | | 432 | | 433 | IP Payload | 434 | | 435 | | 436 +---------------------------+ 438 Figure 6: Private IP-IP Encapsulation Format (Case 5) 440 Outer IP Header: as in [RFC 2003] 441 Sel.: Selector, value to be allocated by IANA: 442 tentatively: 0xE3 443 (=explicitly indicated source and destination, 444 different addressing realm) 445 VPN-OUI (S), VPN index (S): as in [RFC 2685], refers to source 446 Pad: Pad field (inserted for 32-bit alignment), this field 447 MUST be coded as 0x00, and is ignored on receipt) 448 VPN-OUI (D), VPN index (D): as in [RFC 2685], refers to 449 destination 451 4. Example: A Mobile Node Registers at its Home Agent 453 This section provides an example illustrating how the formats 454 specified in section 3 above can be applied. In this example, a 455 mobile node MN has obtained a temporary private IP address within a 456 private IP address realm PR2, where it is currently located. It now 457 wants to register this address with its home agent HA which owns a 458 private IP address within realm PR3. 460 priv. realm PR2 public IP (or PR4) private realm PR3 461 | | | 462 MN ---> border gateway A ------> border gateway B ---> HA 463 (BG A) (BG B) 465 Figure 7: Example for encapsulation of private IP in IP 467 Since PR3 is different from PR2, the following Private IP in IP 468 Encapsulation (PIPE) formats are used on the way from MN to HA: 470 Step 1: From MN to BG A: 471 Outer Header: Source Address: MN(PR2) 472 Destination Address: BG A(PR2) 473 Inner Header: Source Address: MN(PR2) = default 474 Destination Address: HA (PR3) 475 Selector: 0xE1 (explicitly indicated destination) 477 Step 2: From BG A to BG B: 478 Outer Header: Source Address: BG A(public IP or PR4) 479 Destination Address: BG B(public IP or PR4) 480 Inner Header: Source Address: MN (PR2) 481 Destination Address: HA (PR3) 482 Selector: 0xE3 (explicit source and destination, 483 different address realms) 485 Step 3: From BG B to HA: 486 Outer Header: Source Address: BG B(PR3) 487 Destination Address: HA(PR3) 488 Inner Header: Source Address: MN(PR2) 489 Destination Address: HA(PR3) = default 490 Selector: 0xE2 (explicitly indicated source) 492 It should be noted that in addition to the formats illustrated above, 493 a real transfer of a packet from MN to HA also involves a number of 494 routing decisions, and address resolution functions which are outside 495 the scope of this specification, and may perhaps be specified in 496 separate drafts. 498 In the example above, the use of the public Internet as a backbone to 499 interconnect the address realms PR2 and PR3 seems to be a natural 500 choice, but another private realm (PR4) might also be suitable for 501 that purpose. The selection of a transit backbone or a particular 502 address resolution may be subject to different criteria, and/or may 503 be dependent on particular applications. 505 5. Security Considerations 507 IP encapsulation potentially reduces the security of the Internet, 508 and care needs to be taken in the implementation and deployment of IP 509 encapsulation. More detailed considerations of security implications 510 of IP-IP tunnels can be found in section 6 of [RFC 2003]. 512 Since private addresses are typically administered to prevent access 513 to networks inside an enterprise, the transfer of private addresses 514 across networks outside this enterprise must be handled with great 515 care. It may be required to use authentication and possibly 516 encryption to maintain the existing security policy which originally 517 dictated the choice of using a private address space within the 518 enterprise. 520 6. IANA Considerations 522 It is proposed that IANA establishes and maintains a list of protocol 523 values for the selector byte following the outer IP header. The 524 following values are an example for this possible list: 526 0x00 through 0xDF as for corresponding IP version number and 527 header field 528 0xE0 - 0xE3 as defined in this specification 529 0xE4 - 0xFF reserved 531 In addition, the formats for private IP-IP encapsulation specified in 532 this document require the allocation of a new value in the "Protocol" 533 field (identifying the next header) within the IPv4 header, (e.g.: 534 129 PIPE Private IP-IP Encapsulation .... ). 536 7. IPR Considerations 538 Siemens may own intellectual property on some of the technologies 539 described in this document. 541 References 543 [RFC 1918] Rekhter, Y. et al., "Address Allocation for Private 544 Internets", RFC 1918, Febr. 1996 546 [RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 547 October 1996 549 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", RFC 2119, March 1997 552 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks 553 Identifier", RFC 2685, September 1999. 555 Author Information 557 Bernhard Petri 558 Siemens AG 559 Hofmannstr. 51 560 Munich, Germany, D-81359 561 phone: +49 89 722-34578 562 email: bernhard.petri@icn.siemens.de