idnits 2.17.1 draft-ietf-udlr-vipre-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-26) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (November 1997) is 9659 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 258 -- Looks like a reference, but probably isn't: '2' on line 260 ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1705 (ref. 'RFC1075') ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Downref: Normative reference to an Informational RFC: RFC 1702 ** Downref: Normative reference to an Experimental RFC: RFC 1241 Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT James Stepanek 3 stepanek@aero.org 4 The Aerospace Corporation 5 Stephen Schwab 6 schwab@aero.org 7 Twin Sun Inc 9 VIPRE -- Virtual Internet Packet Relay 10 An Encapsulation Architecture for Unidirectional Links 11 13 November 1997 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This memo describes a method of incorporating unidirectional links 36 into an IP network in a bidirectional mode by relaying encapsulated 37 IP packets over a bidirectional network. 39 1. Introduction 41 Successful incorporation of asymmetric, unidirectional satellite 42 links into a internetwork requires special treatment of those links. 43 The design of many protocols commonly used in the Internet assume the 44 existence of symmetrical, bidirectional links between nodes. As a 45 result, many of these same protocols do not work as intended over 46 links which are asymmetric, unidirectional, or both. Asymmetric 47 network topologies, for example, those which incorporate satellite 48 links, primarily affect protocols which use link-dependent state for 49 their operation. This usually occurs whenever the network needs to 50 treat a link as a distinct resource. Examples of this include 51 protocols which handle routing and group management, as well as 52 link-bound heuristics of transport protocols and management software. 54 For example, consider a host with connectivity through two 55 interfaces, in other words, a "multi-homed" host. On this host, one 56 interface forms the receiving end of a connection to a 57 unidirectional, high-bandwidth satellite link. The second interface 58 connects the host to a low-bandwidth, bidirectional terrestrial 59 network. Ideally, an internetwork in this topology makes use of the 60 satellite link where appropriate while still behaving much like a 61 common symmetrical internet. 63 This document describes one approach to incorporating unidirectional 64 satellite links into an internet--the Virtual Internet Packet Relay 65 (VIPRe). This document describes an architecture for incorporating 66 unidirectional links into an internet--reducing the problem of 67 unidirectional links to the more general problem of asymmetric links. 69 Note that while this approach was developed for use in unidirectional 70 satellite links, it could quite possibly be used on other types of 71 unidirectional links. 73 Before describing the details of the architecture, a couple of 74 alternative existing approaches are summarized for the below for the 75 purposes of discussion. 77 1.1. Terminology 79 For the purposes of this discussion, consider two types of network 80 nodes with connections to a unidirectional satellite links. "Uplink" 81 nodes have the ability to send data over a unidirectional link, while 82 "downlink" nodes have the ability to receive data from a 83 unidirectional link. 85 1.2. Split Routing 87 A simple, straight-forward approach modifies routing tables on the 88 uplink and downlink nodes. By introducing a static "split" route on 89 both the downlink and uplink nodes, traffic originating from downlink 90 and destined for uplink nodes is always sent out a bidirectional 91 interface. Similarly, traffic originating from a uplink host and 92 destined for a down link node is always sent out the unidirectional 93 interface. This allows some IP traffic to flow between the uplink 94 and downlink nodes much as it does in a "normal" internet. However, 95 for large networks maintaining the static "split" routes requires 96 significant system management. Also, protocols with bidirectional 97 link assumptions remain broken under this routing configuration. 99 1.3. Routing Protocol Modification 101 Another method of dealing with unidirectional links involves 102 modifying routing protocols to account for one-way hops. The 103 modified routing processes share information with each other for the 104 purpose of directing traffic in a "split" fashion. Essentially, this 105 incorporates a mechanism for "discovery" of uplink nodes by downlink 106 nodes, as well as a mechanism for distributing routing information 107 from downlink nodes back to uplink nodes directly. By handling the 108 problem directly, this approach offers the most general of solutions. 110 In fact in addition to routing protocols, it's expected that many 111 protocols require modification or extensions to remove asymmetric 112 links assumptions. 114 1.4. Virtual Packet Relays 116 A third approach, uses a "relay", or one-way tunnel, to transmit 117 packets back to the uplink node. Virtual Packet Relays, described 118 here in detail, attempt to make a functionally bidirectional 119 interface out of a unidirectional interface. To achieve this, 120 traffic sent out the unidirectional interface of the downlink node is 121 captured somewhere beneath the network layer and relayed through a 122 bidirectional interface on the downlink node to a bidirectional 123 interface on the uplink node. Once the captured data arrives at the 124 uplink node, it's taken out of the relay and injected into the 125 unidirectional interface of the uplink node where it's received as a 126 "normal" network packet by the uplink node. 128 Using a Virtual Packet Relay to deal with unidirectional links 129 differs slightly from the other approaches described earlier. Unlike 130 the "split" route approach, using a Virtual Packet Relay does not 131 require modification of routing table entries for attached networks. 132 This means packets originating on downlink nodes which are destined 133 for uplink nodes can be sent out the unidirectional interface of the 134 downlink node, as if this interface were bidirectional. For this 135 reason, some protocols which include bidirectional link assumptions 136 will operate unmodified under this architecture. 138 A Virtual Packet Relay provides functionality similar to "split" IP 139 routing, but hides the details of the one-way network from IP route 140 tables and routing protocols. This holds the appealing property of 141 allowing some existing protocols to function in this environment 142 without modification. However, this approach assumes that uplink and 143 downlink nodes are connected on a bidirectional network. It also 144 fails to handle the asymmetric nature of the bidirectional link it 145 approximates. In other words, the routing protocols in use will have 146 to be configured to reflect the high cost of the virtual IP hop from 147 receiver to uplink site. 149 In effect, a Virtual Packet Relay creates a virtual network over 150 which IP packets can flow as if there is a reverse path on the 151 unidirectional link. Bandwidth of this path is limited by the 152 underlying bandwidth of the bidirectional internet, so bandwidth 153 management of the reverse link is important. 155 Implementing a Virtual Packet Relay requires two components. On the 156 uplink side, a relay "server" handles unencapsulating and injection 157 of PDUs. On the downlink side a relay "client" handles the capture 158 and encapsulation of PDUs. In practice, this is accomplished with a 159 pair of "Split" Virtual Interfaces (SVIFs). On the server side, a 160 special interface exists which transmits data normally, but receives 161 incoming traffic from a set of one or more relays. On the client 162 side, another special interface exists which receives traffic 163 normally, but transmits outgoing traffic through a set of one or more 164 relays. Together, these two components maintain one-way flows of 165 encapsulated IP traffic, including two SVIFs on either side. 167 In this architecture, relay clients keep a list of relay servers with 168 which they participate, each with a set of corresponding relay 169 endpoints. And when a single relay client communicates with multiple 170 relay servers, the client must use a separate SVIF for each. 172 #*# 173 \ 174 \ 175 \ 176 +----+ +---------------+ 177 | |======>|\ | 178 |SVIF| | downlink node | 179 | |<===1==|/ | 180 +----+ | | 181 | +--relay client-+ 182 | ^ | 183 +===2==>======>| +---3---> relay server 184 (via bidirectional network) 186 ===> link traffic (below network layer) 187 ---> IP traffic 189 Figure 1: Downlink Node Detail 191 #*# 192 / 193 / 194 / 195 +---------------+ +----+ 196 | /|======>| | 197 | uplink node | |SVIF| 198 | \|<==6===| | 199 | | +----+ 200 +--relay server-+ | 201 | | ^ 202 -----4---->--+ +=======>===5===>| 203 relay client 204 (via bidirectional network) 206 ===> link traffic (below network layer) 207 ---> IP traffic 209 Figure 2: Uplink Node Detail 211 2. ICMP Relay Discovery Protocol 213 Before a relay client can provide a fully-functioning SVIF, it must 214 know the IP address of at least one functioning "endpoint" of a relay 215 corresponding to that SVIF. In other words, it must know where to 216 send payload packets so they arrive at the relay server for this 217 SVIF. One method of acquiring this knowledge involves using 218 configuration files to inform the relay client of all the relay 219 servers it needs to know about. Another possible method involves 220 listening to exiting protocol traffic on the unidirectional link and 221 deducing--based on this traffic--the addresses of suitable relay 222 endpoints. Since, both of these methods have drawbacks, a third 223 method is described here, which relies heavily upon the concepts 224 presented in ICMP Router Discovery [RFC1256]. Like ICMP Router 225 Discovery, this method introduces a new ICMP message called a "Relay 226 Advertisement". 228 In fact, the ICMP Relay Discovery process works much like ICMP Router 229 Discovery. If a relay server wishes to advertise its willingness to 230 accept relayed packets, it periodically sends Relay Advertisements on 231 its unidirectional link. Relay clients discover the relay endpoints 232 by listening for Relay Advertisements on their unidirectional link. 234 Like Router Advertisements, Relay Advertisement contain a "lifetime" 235 field. This specifies the maximum time that relay endpoints are 236 considered valid in the absence of further Advertisements. Relay 237 clients use this value to maintain a timer for each relay. 239 Unlike Router Advertisements, Relay Advertisements include a vector 240 of "relay addresses" instead of a "router addresses". They also omit 241 the "preference" field found in Router Advertisements. And unlike 242 ICMP Router Discovery's "Router Addresses", the addresses advertised 243 in Relay Advertisements will likely reside in different subnets or 244 different networks than the address(s) of the interface which 245 receives them. 247 2.1. Message Formats 249 ICMP Relay Advertisement Message 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Code | Checksum | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Num Addrs |Addr Entry Size| Lifetime | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Relay Address[1] | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Relay Address[2] | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | . | 263 | . | 264 | . | 266 IP Fields: 268 Source Address An IP address belonging to the interface 269 from which this message is sent. 271 Destination Address The configured AdvertisementAddress or the 272 IP address of a neighboring host. 274 Time-to-Live 1 if the Destination Address is an IP 275 multicast address; at least 1 otherwise. 277 ICMP Fields: 279 Type TBD 281 Code 0 283 Checksum The 16-bit one's complement of the one's 284 complement sum of the ICMP message, starting 285 with the ICMP Type. For computing the 286 checksum, the Checksum field is set to 0. 288 Num The number of relay endpoint addresses 289 advertised in this message. 291 Addr Entry Size The number of 32-bit words of information 292 per each relay address (1, in the version of 293 the protocol described here). 295 Lifetime The maximum number of seconds that the relay 296 addresses may be considered valid. 298 Relay Address[i] The addresses of the relay endpoints 299 advertised in this message, where i = 1..Num 300 Addrs. 302 2.2. Relay Server Specification 304 2.2.1. Relay Server Configuration Variables 306 Relay Server Configuration Variables for ICMP Relay Discovery are 307 analogous to the Router Configuration Variable in ICMP Router 308 Discovery. A relay server implementing ICMP Relay Discovery must 309 allow configuration of the following variables by system management. 311 The term "advertisement space" refers to a set of relays associated 312 with a single SVIF for which a relay server sends Relay Advertisement 313 messages. For each advertisement space, the relay server maintains 314 the following variables: 316 AdvertisementAddress 317 The IP destination address to be used for Relay 318 Advertisements sent for relays in the advertisement 319 space. 321 Default: 224.0.0.1 if the relay server supports IP 322 multicast on the SVIF interface, else 255.255.255.255 324 MaxAdvertisementInterval 325 The maximum time allowed between sending Relay 326 Advertisements for relays in this advertisement space, 327 in seconds. As in ICMP Router Discovery, this must be 328 no less than 4 seconds and no greater than 1800 seconds. 330 Default: 600 seconds 332 MinAdvertisementInterval 333 The minimum time allowed between sending multicast Relay 334 Advertisements from relays in the advertisement space, 335 in seconds. As in ICMP Router Discovery, this must be 336 no less than 3 seconds and no greater than 337 MaxAdvertisementInterval. 339 Default: 0.75 * MaxAdvertisementInterval 341 For each of its relays, the relay server's maintains the following 342 information: 344 Advertise 345 A flag indicating whether or not the relay is to be 346 advertised. 348 Default: TRUE 350 2.2.2. Relay Server Behavior 352 For each advertisement space with at least one relay whose Advertise 353 flag is TRUE, the relay server transmits periodic Relay 354 Advertisements, with the following values. 356 - In the destination address field of the IP header: the configured 357 AdvertisementAddress for the advertisement space. 359 - In the Lifetime field: the configured AdvertisementLifetime for 360 the advertisement space. 362 - In the Relay Address[i] fields: all the addresses of the relay 363 endpoints in the advertisement space with Advertise flags marked 364 TRUE. 366 To avoid unwanted synchronization, the interval between sending Relay 367 Advertisements varies randomly. Many other protocols which transmit 368 "periodic" messages describe why and how to achieve this, including 369 ICMP Router Discovery. 371 2.3. Relay Client Specification 373 2.3.1. Relay Client Configuration Variables 375 Relay Client Configuration Variables for ICMP Relay Discovery are 376 analogous to the Host Configuration Variable in ICMP Router 377 Discovery. A relay client implementing ICMP Relay Discovery must 378 allow configuration of the following variables by system management. 380 For each SVIF, a relay client maintains the following variables: 382 PerformRelayDiscovery 383 A flag indicating whether or not the relay client 384 performs ICMP Relay Discovery for the SVIF. 386 Default: TRUE 388 For SVIFs which will not perform ICMP Relay Discovery, the relay 389 client must support a configurable list of relay endpoints. The 390 following variables exist for each SVIF not performing ICMP Relay 391 Discovery. 393 RelayAddress 394 The IP address of the endpoint of the desired relay for 395 this SVIF. 397 Default: (none) 399 2.3.2. Message Validation by Relay Clients 401 Relay Advertisements are validated by relay clients in the same way 402 that Router Advertisements are validated by hosts--as described in 403 Section 5.2 of RFC 1256--except when validating Relay Advertisements, 404 the ICMP Addr Entry Size must be greater than or equal to 1, instead 405 of greater that or equal to 2. 407 2.3.3. Relay Client Behavior 409 Upon receiving and validating a Relay Advertisement, the relay client 410 executes the following process for each Relay Address in the 411 Advertisement. 413 - If the address does not already exist in the relay client's list 414 of relay addresses, it may create a new entry in the list for the 415 new address. The new entry contains the address along with a 416 timer initialized with the Lifetime value of the advertisement. 418 - If the address already exists in the relay client's list as a 419 result of a previously-received advertisement, the client resets 420 the timer using the Lifetime value of the advertisement. 422 If no Relay Advertisement are received such that the timer expires 423 for a entry created as a result of a previously received 424 advertisement, the client removes this entry from its list 426 3. Encapsulating Traffic 428 Once a relay client knows of one or more relay endpoints, it may 429 begin encapsulating captured traffic, and sending it through the 430 relay. 432 Currently, many protocols exist for the purpose of transporting 433 encapsulated packets. Some of these are discussed in the context of 434 IP mobility [RFC2002][RFC2003], point-to-point link transport 435 [RFC1661], security [RFC1827], and multicast routing [RFC1075]. If a 436 relay server does not support a protocol with "advertisements", it 437 must support IP in IP encapsulation using an intervening GRE 438 [RFC1701] header, that is, using GRE with IP as both the delivery and 439 payload protocol as discussed in [RFC1702] (see Figure 3). 440 Otherwise, the relay server must advertise the tunneling protocols it 441 supports. If a desired tunneling protocol supports a suitable notion 442 of advertisement, then these messages provide one method of uplink 443 discovery for Relay Clients. Alternatively, extensions to the Relay 444 Discovery protocol--by adding additional information the the Address 445 Entries of advertisements--would support use of other encapsulation 446 methods. 448 +---------------------------+ 449 | | 450 | Outer IP Header | 451 | | 452 +---------------------------+ 453 | | 454 | GRE Header | 455 | | 456 +---------------------------+ 457 | | 458 | IP Header | 459 | | 460 +---------------------------+ 461 | | 462 | | 463 | IP Payload | 464 | | 465 | | 466 +---------------------------+ 468 Figure 3: Baseline Encapsulation Protocol 470 The correct choice of encapsulation protocol depends upon the nature 471 of network. Important considerations include security and bandwidth 472 management of bidirectional links, as well as the expected number of 473 participating downlink nodes. In addition to these considerations, 474 the encapsulation process itself affects several IP mechanisms. 475 Appendix B of [RFC1241] contains a discussion of some of the 476 implications of encapsulating IP traffic. 478 4. Security Considerations 480 RFC 1256 points out that systems can use ICMP Router Discovery to 481 masquerade as a default router. In a similar manner, systems can use 482 ICMP Relay Discovery to masquerade as a relay server. As described 483 in Section 7 of RFC 1256, one possible method of addressing this 484 problem involves adding authentication information to advertisements. 486 On the relay server side, the simple encapsulation method described 487 in this memo fails to provide relay server's with the ability to 488 authenticate relay clients. And since relay client transmit payload 489 packets entirely in the clear, potentially malicious intermediate 490 nodes have the ability to interpret the payload of the relay. The 491 protocols and architecture described in the memo were intended to 492 tolerate variety in choice encapsulation protocol, so where 493 authenticating relay clients and protecting payload transmissions are 494 concerns, an alternative encapsulation protocol which provides these 495 services may be used instead of the simple one describe here. 497 Security mechanisms may also reside on entities conceptually above 498 the relay, using the relay as it's intended, that is, as just another 499 IP link. 501 5. References 503 [RFC1256] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 504 September 1991. 506 [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, 507 October 1996. 509 [RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 510 1996. 512 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 513 Daydreamer, July 1994. 515 [RFC1827] R. Atkinoson, "IP Encapsulating Security Payload (ESP)", 516 RFC1827, August 1995 518 [RFC1075] D. Waitzman, C. Partridge, and S. Deering, "Distance 519 Vector Multicast Routing Protocol", RFC 1705, November 1988. 521 [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 522 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco 523 Systems, October 1994. 525 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 526 Routing Encapsulation over IPv4 networks", RFC 1702, NetSmiths, 527 Ltd., cisco Systems, October 1994. 529 [RFC1241] R. Woodburn, D. Mils, "A Scheme for an Internet 530 Encapsulation Protocol: Version 1", RFC 1241, July 1991. 532 6. Authors' Address: