idnits 2.17.1 draft-yliteo-mobileip-paid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (18 January 1998) is 9594 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) == Unused Reference: '7' is defined on line 867, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1631 (ref. '6') (Obsoleted by RFC 3022) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '8') Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Li 3 INTERNET DRAFT Bay Networks, Inc. 4 W. T. Teo 5 National University 6 of Singapore 7 18 January 1998 9 IP Private Address Identification (PAID) 10 draft-yliteo-mobileip-paid-00.txt 12 Status of this Memo 14 This document is a submission to the Mobile-IP Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the mobile-ip@smallworks.com mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 This memo proposes a scheme to conserve the IPv4 address space by 39 allowing to allocate private instead of public IP addresses for its 40 internet hosts. These internet hosts can achieve complete internet 41 connectivity between any domains with each private host globally 42 identified as a address pair. To enable private 43 hosts to communicate using these address pairs efficiently, we 44 propose a PAID Encapsulation protocol. To acquire a 45 address pair, we specify a variant registration method derived from 46 Mobile IP, using a PAID Registration Request and PAID Registration 47 Reply. This approach requires modifications to network sockets and 48 enhancements to the domain name system. 50 1. Introduction 52 Many enterprises are employing network applications based on the IP 53 platform due to the widespread availability of such software. With 54 the current exponential growth of Internet hosts, the IPv4 address 55 space is rapidly being depleted. Enterprises can however utilize 56 private (in contrast to public) IP addresses to run their network 57 applications. But private addresses due to their nature restrict the 58 network spans to within the enterprises themselves. 60 The inaccessibility of private networks with foreign domains is 61 because the destination IP address of a datagram generally determines 62 the routing path taken. As a private address is not globally unique, 63 traffic destined to a private node from beyond the private network 64 will be undeliverable. 66 To allow a private node access to a foreign host, the IP network 67 address translator (NAT [6]) provides a means to convert between 68 private addresses and public addresses. However, there are a number 69 of limitations to this approach: it requires a sparse end-to-end 70 traffic matrix; it increases the probability of mis-addressing; it 71 breaks certain applications; it hides the identity of communicating 72 hosts. 74 Morever, it is not possible for foreign hosts to access a private 75 host without the use of application gateways. These methods generally 76 requires tunneling, both the routing domains to be known beforehand, 77 the private IP addresses between the communicating domains to be 78 unique or static configurations at the application gateways to 79 deliver the traffic to the private host. 81 This document proposes that a private node register its own address 82 with a public node. This latter will receive traffic from a public 83 IP tunnel over the Internet on behalf of the private node and then 84 forward the traffic to the node. Therefore, this 85 address pair is taken as the identification (PAID) of the private 86 node over the global Internet. The public node is called PAID agent. 88 To efficiently identify the PAID sources and PAID destination in 89 datagrams between private hosts, the document proposes a PAID 90 Encapsulation protocol. This encapsulation method also reduces the 91 overhead in multiple encapsulations. 93 To locate a PAID agent, we specify a PAID agent discovery protocol. 94 To acquire a address pair, we derive a new variant 95 registration method from Mobile IP [1], using a PAID Registration 96 Request and PAID Registration Reply. With the registration, a private 97 node is able to automatically acquire a global identification. 99 Private nodes that only require access to foreign servers but do not 100 provide service to foreign clients can continue to employ NAT [6] to 101 access domains that do not support PAID. Therefore, internet 102 connectivity of the private hosts can expand with PAID deployment 103 without sacrificing an organization's access to internet resources. 105 The primary advantage in the PAID approach is that all private hosts 106 in a domain can be accessed by public or private nodes in other 107 domains, and even hosts in different domains but with the same 108 private address can communicate with each other. Additionally, PAID 109 provides an easy migration path to enable internet connectivity for 110 private intranets or the formation of extranets, without the need to 111 renumber the network machines. 113 Many other benefits can be gained from using private addresses that 114 are not allocated by a central registration body. An organization has 115 more flexibilty during network deployment and expansion using the 116 large number of private addresses available. 118 The disadvantage with this approach is that, network applications 119 have to be modified, and the domain name system has to be enhanced. 121 2. Applicability 123 =============== WAN ============== Public Internet ======= WAN ======= 124 . | . . . . . . . . . . .|. . . . . . . . . .| . 125 Public . | ..........|...................|.......... 126 192.32.174.44 | :200.9.1.1| Public 200.9.2.1| . : 127 . . . . .+---------+ : +----+---+ +------+------+ : 128 .+-------| ISP Rtr |--+ : |Router A| | Router B | : 129 .| +-+-----+-+ | : +----+---+ +--+---+---+--+ : 130 .| | | | : | | | . | : 131 .| | | | : | | | . | : 132 ............. ............... : ............. ............... : 133 : . : : : : : : : . : : 134 : Private : : Private : : : Private : : Private : : 135 : Network : : Network : : : Network : : Network : : 136 :192.168.0.0: : 10.0.0.0 : : :192.168.0.0: : 10.0.0.0 : : 137 :255.255.0.0: : 255.0.0.0 : : :255.255.0.0: : 255.0.0.0 : : 138 : : : : : : : : : : 139 : 256x256 : : 256x256x256 : : : 256x256 : : 256x256x256 : : 140 : addresses : : addresses : : : addresses : : addresses : : 141 :...........: :.............: : :...........: :.............: : 142 : : 143 : Enterprise Virtual Private Network : 144 : (VPN) : 145 :.......................................: 147 Figure 1 Private Nodes Communicate with Each Other Using PAID 149 Private Address Identification (PAID) is intended to enable private 150 nodes to communicate globally. For example, a private host in an ISP 151 network is able to access a public or private HTTP server in an 152 enterprise network, and a public or private host outside an ISP 153 network can access a private HTTP server in the ISP network. 155 Figure 1 is a typical network deployment over the Internet. 157 For example, a private host 10.10.10.10 in the ISP network can talk 158 to a private host 10.20.20.20 in the enterprise VPN by using an ISP 159 address pair <192.32.174.44, 10.10.10.10> and an enterprise address 160 pair <200.9.2.1, 10.20.20.20>. To enable this functionality, these 161 two private hosts should use PAID encapsulation and decapsulation. 162 Also, the ISP router, router A and router B should support the PAID 163 encapsulation protocol. All other routers will remain with running 164 conventional routing protocols. 166 2. Terminology and Definitions 168 2.1 Private Node 170 A node where all its interface addresses are private as specified in 171 RFC 1918 [9]. 173 2.2 Public Node 175 A node which has at least one public interface address. The public 176 address is in contrast to the private address [9]. 178 2.3 Identification of Private Address (PAID) 180 A private node, when attempting to enable global communication, can 181 register its own address with a public node. The 182 address pair is called the identification of the private node, or 183 PAID for short, over the global Internet. 185 In Figure 1, <192.32.174.44, 10.10.10.10> is a PAID of the private 186 host 10.10.10.10 in the ISP network, and <200.9.2.1, 10.20.20.20> is 187 a PAID of the private host 10.20.20.20 in the enterprise VPN. 189 2.4 PAID Agent 191 A PAID agent is a node that provides private nodes with the public 192 portion of the identifications for the private nodes. It will tunnel 193 traffic between a private node in the same domain and a node in 194 another domain. 196 In Figure 1, the ISP router is a PAID agent for the private host 197 10.10.10.10 in the ISP network, and the router B is a PAID agent for 198 the private host 10.20.20.20 in the enterprise VPN. 200 From the standpoint of routing and security, the PAID agent should be 201 chosen from domain border routers or backbone routers. 203 2.5 PAID Agent Address 205 A PAID agent address is referred to as an interface address that is 206 public. 208 3. PAID Encapsulation Protocol 210 Encapsulation is suggested as a means to alter the normal IP routing 211 for datagrams, by delivering them to an intermediate destination that 212 would otherwise not be selected by the (network part of the) IP 213 Destination Address field in the original IP header. 215 The process of encapsulation and decapsulation of a datagram is 216 frequently referred to as "tunneling" the datagram, and the 217 encapsulator and decapsulator are then considered to be the 218 "endpoints" of the tunnel; the encapsulator node is referred to as 219 the "entry point" of the tunnel, and the decapsulator node is 220 referred to as the "exit point" of the tunnel. 222 The Minimal Encapsulation for IP [3] is an encapsulation mechanism 223 that eliminates unnecessary duplication required by other 224 encapsulation mechanisms, such as IP Encapsulation within IP [2] and 225 Generic Routing Encapsulation [8]. However, the minimal encapsulation 226 does not really save any space for PAID. Also, with the existing 227 encapsulation mechanisms, it is difficult to identify the private 228 source, public source, private destination and public destination 229 from a received packet. 231 3.1 PAID Encapsulation 233 A PAID forwarding header is defined for datagrams to be originated. 234 PAID encapsulation must not be used when an original datagram is 235 already fragmented, since there is no room in the PAID forwarding 236 header to store fragmentation information. To encapsulate an IP 237 datagram using PAID encapsulation, the PAID forwarding header is 238 inserted into the datagram, as follows: 240 +---------------------------+ +---------------------------+ 241 | | | | 242 | IP Header | | Modified IP Header | 243 | | | | 244 +---------------------------+ ====> +---------------------------+ 245 | | | PAID Forwarding Header | 246 | | +---------------------------+ 247 | IP Payload | | | 248 | | | | 249 | | | IP Payload | 250 +---------------------------+ | | 251 | | 252 +---------------------------+ 254 The IP header of the original datagram is modified, and the PAID 255 forwarding header is inserted into the datagram after the IP header, 256 followed by the unmodified IP payload of the original datagram (e.g., 257 transport header and transport data). No additional IP header is 258 added to the datagram. 260 In encapsulating the datagram, the original IP header [5] is modified 261 as follows: 263 - The Protocol field in the IP header is replaced by protocol 264 number 56 for the PAID encapsulation protocol. 266 - The Destination Address field in the IP header is replaced by the 267 IP address of the exit point of the tunnel. 269 - If the encapsulator is not the original source of the datagram, 270 the Source Address field in the IP header is replaced by the IP 271 address of the encapsulator. 273 - The Total Length field in the IP header is incremented by the 274 size of the PAID forwarding header added to the datagram. 276 - The Header Checksum field in the IP header is recomputed [5] or 277 updated to account for the changes in the IP header described 278 here for encapsulation. 280 Note that like minimal encapsulation, the Time to Live (TTL) field 281 in the IP header is not modified during encapsulation; since this 282 encapsulation is performed at the datagram origination, the 283 encapsulator will not decrement the TTL. 285 3.2 Format of PAID Forwarding Header 287 The format of the PAID forwarding header is as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Protocol |D|S| Reserved | Header Checksum | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Public Destination Address | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Public source Address | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 : (if present) Private Destination Address : 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 : (if present) Private Source Address : 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Protocol 304 Copied from the Protocol field in the original IP header. 306 D bit 308 If set, the private destination PAID is present. 310 S bit 312 If set, the private source PAID is present. 314 Reserved 316 Sent as zero; ignored on reception. 318 Header Checksum 320 The 16-bit one's complement of the one's complement sum of all 321 16-bit words in the PAID forwarding header. For purposes of 322 computing the checksum, the value of the checksum field is 0. 323 The IP header and IP payload (after the PAID forwarding header) 324 are not included in this checksum computation. 326 Public Destination Address 328 The address of a public destination node, or the PAID agent 329 address of a private destination node. In the case of public 330 destination node, this is the original destination address. 332 Public source Address 334 The address of a public source node, or the PAID agent address 335 of a private source node. In the case of public source node, 336 this is the original source address. 338 Private Destination Address 340 If present, the address of a private destination node. In the 341 case of private destination node, this is the original 342 destination address. 344 Private Source Address 346 If present, the address of a private source node. In the case 347 of private source node, this is the original source address. 349 3.3 PAID Decapsulation 351 A PAID agent should perform PAID decapsulation in the same way as in 352 IP encapsulation within IP [2]. The agent should perform PAID 353 encapsulation without changing the inner PAID forwarding header when 354 it forwards the decapsulated packet to the destination. 356 A private or public destination node should decapsulate a received 357 packet and save the source address pair for 358 subsequent datagram origination. 360 3.4 ICMP Messages from within the Tunnel 362 ICMP messages are to be handled as specified in [2], including the 363 maintenance of tunnel "soft state". 365 4. Datagram Routing with PAID Encapsulation 367 This section describes how the PAID encapsulation and decapsulation 368 are performed when no other encapsulation protocols are involved. In 369 this case, the following nodes should support the PAID encapsulation 370 protocol: 372 - private nodes who wish to enable global communication, 373 - all PAID agents, and 374 - public nodes who wish to communicate with a private node in 375 another routing domain. 377 4.1 An Example of Packet Processing 379 To better illustrate PAID, we take the same picture from NAT [1]: 381 \ | / 382 +---------------+ 383 |Regional Router| 384 +---------------+ 385 WAN | | WAN 386 | | 387 {s2=198.76.28.4,^ | | |{s2=198.76.28.4, 388 d2=198.76.28.7}| | | v d2=198.76.28.7} 389 {S=198.76.28.4,^ | | |{S=198.76.28.4, 390 D=198.76.29.7}| | | v D=198.76.29.7} 391 {s=10.33.96.5, ^ | | |{s=10.22.96.5, 392 d=10.81.13.22}| | | v d=10.81.13.22} 393 +-----------------+ +-----------------+ 394 | PAID Agent | | PAID Agent | 395 +-----------------+ +-----------------+ 396 | | 397 | LAN LAN | 398 ------------- ------------- 399 {s2=10.33.96.5, ^ | | |{s2=198.76.28.7, 400 d2=198.76.28.4}| | | v d2=10.81.13.22} 401 {S=198.76.28.4,^ | | |{S=198.76.28.4, 402 D=198.76.29.7}| | | v D=198.76.29.7} 403 {s=10.33.96.5, ^ | | |{s=10.22.96.5, 404 d=10.81.13.22}| +--+ +--+ v d=10.81.13.22} 405 |--| |--| 406 /____\ /____\ 407 10.33.96.5 10.81.13.22 409 Figure 2 Datagram Encapsulation and Decapsulation under PAID 411 4.2 Packets Originating from a Private Node To Another Domain 413 When receiving a packet from a private node, any intermediate 414 router should never change the PAID forwarding header. 416 4.2.1 Source Private Node 418 When a private node generates a packet, it should perform PAID 419 encapsulation for the packet. In the PAID forwarding header, private 420 source address field should be present (S bit set). The exit point of 421 the tunnel should be the PAID agent of the private source node. 423 4.2.2 Source PAID Agent 425 When the PAID agent for the source private node receives the packet, 426 it should replace the source and destination address in the outer IP 427 header, respectively with its own address and the public destination 428 address in the PAID forwarding header. This means the packet will be 429 tunneled to a public destination node or the PAID agent of a private 430 destination node. 432 4.2.3 Destination Node 434 When receiving the packet, the final destination node should save the 435 source address pair for subsequent datagram 436 origination. 438 4.3 Packets from a Domain to Private Node in Another Domain 440 When receiving a packet destined to a private node, any 441 intermediate router should never change the PAID forwarding header. 443 4.3.1 Source Node 445 When a source node originates a packet to a private node in another 446 routing domain, if it does not have the destination node's PAID, it 447 may consult relevant DNS servers in the other domain to obtain the 448 PAID of the private destination node. The method of obtaining PAIDs 449 this way is beyond the scope of this document. 451 The source node should perform PAID encapsulation for the packet. In 452 the PAID forwarding header, private destination address field should 453 be present (D bit set). The exit point of the tunnel should be the 454 PAID agent of the source node if the source is a private node, or 455 otherwise the public destination address in the PAID forwarding 456 header. 458 4.3.2 Destination PAID Agent 460 When the PAID agent of the destination private node receives the 461 packet, it should replace the source and destination address in the 462 outer IP header, respectively with its own address and the private 463 destination address in the PAID forwarding header. This means the 464 packet will be tunneled to the destination private node. 466 4.4 Packets within the Same Domain 468 When a packet is destined to a node in the same routing domain, PAID 469 encapsulation and decapsulation are not required. 471 4.5 Packets between Public-Public Pair 473 When a packet is originated from a public node and destined to 474 another public node, PAID encapsulation and decapsulation are not 475 required. 477 5. NAT and PAID Compatability 479 NAT [6] provides a means for private hosts to access the global 480 Internet. It is dominant in the virtual private networks (VPNs). 482 PAID is a complement to the NAT. A PAID agent can employ either the 483 PAID encapsulation protocol or NAT to forward packets from a private 484 node to a public node, provided the private node tunnels the packets 485 to the PAID agent by the PAID encapsulation. 487 As the PAID approach may not be deployed quicky, the use of PAID as 488 a complement to the NAT will probably help in the transition. 490 5.1 Source Private Node 492 The source private node should specify the "forward" field in the 493 PAID Registration Request message (see section 7.1). If it requests 494 the PAID agent to employ the PAID encapsulation in forwarding 495 packets to the destination, the "forward" field should be 0. If it 496 requests to employ NAT in the forwarding, the field should be 1. 498 The private should use the PAID encapsulation protocol to tunnel 499 packets to the PAID agent as specified in section 4.2.1. 501 5.2 PAID agent 503 The PAID agent should indicate its support for NAT using N bit in the 504 PAID Agent Advertisement message (see section 6.2). Supporting PAID 505 is the minimum requirement. 507 When the PAID agent receives a PAID Registration Request, it should 508 verify if it supports the requested forwarding method. If it does not 509 support, it should deny the request and respond with a PAID 510 Registration Reply with code set to 72. 512 If it supports the requested forwarding method, whenever it receives 513 a packet from the private node, the PAID agent should employ the 514 relevant method, take the source and destination addresses from the 515 PAID header, and forward packets to the destination. 517 6. PAID Agent Discovery Protocol 519 This section describes an optional means for a private node to 520 discover PAID agents available in the same domain. 522 A private node may multicast PAID Agent Solicitation messages to 523 learn the presence of any PAID agents. Each PAID agent, whenever 524 receiving a Solicitation message, must unicast a PAID Agent 525 Advertisement message back to the private node. 527 6.1 PAID Agent Solicitation 529 A private node may multicast a PAID Agent Solicitation message to 530 obtain one or more PAID agent addresses. This message should be sent 531 to the All-PAID-Agents multicast address. 533 UDP fields: 535 Source Port variable 537 Destination Port 434 539 The UDP header is followed by the fields shown below: 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type |C|P| Reserved | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Private Address (if present) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Extensions ... 549 +-+-+-+-+-+-+-+- 551 Type 16 553 C If set, the private node requests that all PAID agents 554 receiving the message release the PAIDs associated with 555 the private node. 557 P If set, the private address is present. 559 Reserved 0 561 Private Address 562 This field, 4 bytes long, is present only if C bit is set. 564 A private node may multicast PAID Agent Solicitation messages to 565 learn the presence of any PAID agents. It may retransmit the message 566 in a reasonable interval if it does not receive any PAID Agent 567 Advertisement message. 569 If a private node reboots and loses its PAIDs, it must set the 'C' 570 bit in the PAID Agent Solicitation message it sends when restarting. 571 By setting the 'C' bit in the solicitation, a private node requests 572 that all the PAID agents that receive the solicitation should clean 573 up their private PAIDs that match the private address. 575 6.2 PAID Agent Advertisement 577 A PAID agent may send a PAID Agent Advertisement message to inform a 578 prospective private node about the IP address of the PAID agent. 579 It may also multicast a PAID Advertisement message, at certain 580 interval, to all private nodes. 582 This message should be sent to a specific private address if it is 583 in response to a PAID Agent Solicitation message, or otherwise the 584 All-Private-Nodes multicast address. 586 UDP fields: 588 Source Port variable 590 Destination Port 434 if IP destination address is multicast, 591 or otherwise copied from the source port of 592 the corresponding PAID Solicitation. 594 The UDP header is followed by the fields shown below: 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type |B|H|F|N| Reserved| Lifetime | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Agent Address | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Extensions ... 603 +-+-+-+-+-+-+-+- 604 Type 17 606 B Busy. The PAID agent will not accept request from 607 additional private nodes. 609 H Home PAID agent. This agent offers service as a home 610 PAID agent. 612 F Foreign PAID agent. This agent offers service as a 613 foreign PAID agent. 615 N NAT support. This agent support NAT. See 5.2. 617 Reserved 0 619 Lifetime The longest lifetime (measured in seconds) that this 620 agent is willing to accept in any PAID Request. 621 A value of 0xffff indicates infinity. 623 Agent Address 624 A public address of the PAID agent. 626 7. PAID Registration Protocol 628 This section describes a means for a private node to register a PAID 629 with a PAID agent. It is a subset of the registration procedure 630 specified in the Mobile IP base protocol [1], where the private node 631 is taken as the mobile node, the PAID agent is taken as the foreign 632 agent, and no home agent is required. 634 A private node may intend to register a PAID with a PAID agent in 635 order to enable global communication. To register a PAID, the private 636 node should send a PAID Registration Request message to a PAID agent. 637 The PAID Agent should respond with a PAID Registration Reply message 638 where it indicates whether it agrees to bind the private node to 639 itself and to receive and forward traffic subsequently on behalf of 640 the private node. 642 The private node may keep retransmitting PAID Registration Request 643 messages to the PAID agent until it receives a reply or a maximum of 644 MAX_RETRANS Registration Request messages have been sent. In the 645 latter case, the private node may choose to seek a PAID from another 646 PAID agent. 648 A private node may have multiple PAIDs, each associated with a 649 different PAID agent. These PAIDs can be used for various sessions 650 of datagram origination. However, each private node can only receive 651 global datagrams at one PAID, which is the one it obtained in the 652 latest registration. 654 Below are the formats of the PAID Registration Request and Reply 655 messages. The use of these messages are similar to the Mobile IP base 656 protocol [1]. 658 7.1 PAID Registration Request Message 660 A private node may send a PAID Registration Request message to 661 register a PAID with a PAID agent. This message should be sent to the 662 specific PAID agent, which may be learned from previous PAID 663 Advertisement messages. 665 UDP fields: 667 Source Port variable 669 Destination Port 434 671 The UDP header is followed by the fields shown below: 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type |D|Rsvd |Forward| Lifetime | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Agent Address | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Private Address | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 + Identification + 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Extensions ... 686 +-+-+-+-+-+-+-+- 688 Type 18 690 D Domain name. If the 'D' bit is set, the private node 691 requests the PAID agent to update the DNS with the new 692 PAID. 694 Forward Forwarding method. See 5.1. 695 0: PAID Encapsulation 696 1: NAT 698 Reserved 0 700 Lifetime 701 The number of seconds remaining before the PAID is 702 considered expired. A value of zero indicates a 703 request for disassociation. A value of 0xffff indicates 704 infinity. 706 Agent Address 707 A public address of the PAID agent. 709 Private address 710 A private address of the originating node. 712 Identification 713 A 64-bit number, constructed by the private node, used 714 for matching PAID Registration Requests with PAID 715 Registration Replies, and for protecting against replay 716 attacks of these messages. 718 7.2 PAID Registration Reply Message 720 A PAID agent returns a PAID Registration Reply message to a private 721 node which has sent a PAID Registration Request message. The Reply 722 message contains the necessary codes to inform the private node about 723 the status of its Request, along with the lifetime granted by the 724 PAID agent, which may be smaller than the original Request. 726 UDP fields: 728 Source Port variable 730 Destination Port copied from the source port of the 731 corresponding Reply message. 733 The UDP header is followed by the fields shown below: 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Code | Lifetime | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Agent Address | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Private Address | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 + Identification + 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Extensions ... 748 +-+-+-+-+-+-+-+- 750 Type 19 752 Code A value indicating the result of the PAID Registration 753 Request. See below for a list of currently defined Code 754 values. 756 Lifetime 757 If the Code field indicates that the PAID Registration 758 request was accepted, the Lifetime field is set to the 759 number of seconds remaining before the registration is 760 considered expired. A value of zero indicates that the 761 private node has been disassociated. A value of 0xffff 762 indicates infinity. If the Code field indicates that the 763 request was denied, the contents of the Lifetime field 764 are unspecified and must be ignored on reception. 766 Agent Address 767 A public address of the PAID agent. 769 Private address 770 A private address of the originating node. 772 Identification 773 A 64-bit number used for matching PAID Registration 774 Requests with PAID Registration Replies, and for 775 protecting against replay attacks of these messages. The 776 value is based on the Identification field from the PAID 777 Registration Request message from the private node, and 778 on the style of replay protection used in the security 779 context between the private node and its PAID agent 780 (defined by the PAID security association between them, 781 and SPI value in the PAID Authentication Extension). 783 The following values are defined for use within the Code field. 784 PAID request successful: 786 0 registration accepted 788 PAID request denied by the foreign agent: 790 64 reason unspecified 791 65 administratively prohibited 792 66 insufficient resources 793 67 private node failed authentication 794 68 requested Lifetime too long 795 69 poorly formed Request 796 70 invalid public address 797 71 registration Identification mismatch 798 72 forwarding method is not supported 800 Up-to-date values of the Code field are specified in the most recent 801 "Assigned Numbers" [4]. 803 7.3 PAID Authentication Extension 805 Exactly one PAID Authentication Extension must be present in all PAID 806 Requests and PAID Replies. The location of the extension marks the 807 end of the authenticated data. This extension should be appended to 808 both the PAID Request and Reply messages. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type | Length | SPI .... 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 ... SPI (cont.) | Authenticator ... 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Type 32 820 Length 4 plus the number of bytes in the Authenticator. 822 SPI Security Parameter Index (4 bytes). An opaque 823 identifier. 825 Authenticator (variable length) 827 8. Various Aspects of PAID 829 8.1 Network Applications Consideration 831 To allow network applications (such as FTP) to control over the 832 encapsulation, some BSD APIs ought to be changed. This issue may be 833 discussed elsewhere. 835 8.2 Domain Name System Consideration 837 This issue may be discussed elsewhere. 839 9. Security 841 The security issue is beyond the scope of this document. 843 10. Acknowledgments 845 Many thanks to Dr. Y. C. Tay at the National University of Singapore 846 for supporting this joint work as well as for his valuable comments. 848 References 850 [1] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 851 1996. 853 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, May 1996. 855 [3] C. Perkins. Minimal Encapsulation within IP, RFC 2004, October 856 1996. 858 [4] J. K. Reynolds and J. Postel. Assigned Numbers. RFC 1700, 859 October 1994. 861 [5] J. Postel, Editor. "Internet Protocol", STD 5, RFC 791, September 862 1981. 864 [6] K. Egevang, and P. Francis. The IP Network Address Translator, 865 RFC 1631, May 1994. 867 [7] P. Calhoun and C. Perkins. Tunnel Establishment Protocol, Internet 868 Draft, November 1997. 870 [8] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 871 Encapsulation (GRE). RFC 1701, October 1994. 873 [9] Y. Rekhter, and et al. Address Allocation for Private Internets, 874 RFC 1918, February 1996. 876 Author's Address 878 Questions about this memo can also be directed to the author: 880 Y. Li 881 Bay Networks, Inc. 882 BL60-304 883 600 Technology Park Drive 884 Billerica, MA 01821 886 Phone: 1-978-916-1130 887 Fax: 1-978-670-8760 888 E-mail: yli@BayNetworks.COM 890 W. T. Teo 891 Department of ISCS 892 National University of Singapore 893 Lower Kent Ridge Crescent 894 SINGAPORE 119260 896 E-mail: teoweetu@iscs.nus.edu.sg