idnits 2.17.1 draft-ietf-udlr-lltunnel-05.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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 81: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 122: '... communication interfaces. A feed MUST...' RFC 2119 keyword, line 342: '... feed MUST maintain a list of all ot...' RFC 2119 keyword, line 343: '... list MUST indicate which are send-o...' (9 more instances...) 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.) -- 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: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Duros 3 Internet-Draft UDcast 4 November 2000 W. Dabbous 5 Exprires April 2001 INRIA Sophia-Antipolis 6 H. Izumiyama 7 N. Fujii 8 WIDE 9 Y. Zhang 10 HRL 12 A Link-Layer Tunneling Mechanism for Unidirectional Links 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 A version of this draft document is intended for submission to the 37 RFC editor as a Proposed Standard for the Internet Community. 39 Abstract 41 This document describes a mechanism to emulate full bidirectional 42 connectivity between all nodes that are directly connected by a 43 unidirectional link. The "receiver" uses a link-layer tunneling 44 mechanism to forward datagrams to "feeds" over a separate 45 bidirectional IP network. As it is implemented at the link-layer, 46 protocols in addition to IP may also be supported by this mechanism. 48 1. Introduction 50 Internet routing and upper layer protocols assume that links are 51 bidirectional, i.e., directly connected hosts can communicate with 52 each other over the same link. 54 This document describes a link-layer tunneling mechanism that allows 55 a set of nodes (feeds and receivers, see Section 2 for terminology) 56 which are directly connected by a unidirectional link to send 57 datagrams as if they were all connected by a bidirectional link. We 58 present a generic topology in section 3 with a tunneling mechanism 59 that supports multiple feeds and receivers. Note, this mechanism is 60 not designed for topologies where a pair of nodes are connected by 2 61 unidirectional links in opposite direction. 63 The tunneling mechanism requires that all nodes have an additional 64 interface to an IP interconnected infrastructure. 66 The tunneling mechanism is implemented at the link-layer of the 67 interface of every node connected to the unidirectional link. The aim 68 is to hide from higher layers, i.e. the network layer and above, the 69 unidirectional nature of the link. The tunneling mechanism also 70 includes an automatic tunnel configuration protocol that allows nodes 71 to come up/down at any time. 73 Generic Routing Encapsulation [rfc2784] is suggested as the tunneling 74 mechanism as it provides a means for carrying IP, ARP datagrams, and 75 any other layer-3 protocol between nodes. 77 The tunneling mechanism described in this document was discussed and 78 agreed upon by the UDLR working group. 80 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 81 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 82 document, are to be interpreted as described in [rfc2119]. 84 2. Terminology 86 Unidirectional link (UDL): A one way transmission link, e.g. a 87 broadcast satellite link. 89 Receiver: A router or a host that has receive-only connectivity to a 90 UDL. 92 Send-only feed: A router that has send-only connectivity to a UDL. 94 Receive capable feed: A router that has send-and-receive connectivity 95 to a UDL. 97 Feed: A send-only or a receive capable feed. 99 Node: A receiver or a feed. 101 Bidirectional interface: a typical communication interface that can 102 send or receive packets, such as an Ethernet card, a modem, etc. 104 3. Topology 106 Feeds and receivers are connected via a unidirectional link. Send- 107 only feeds can only send data over this unidirectional link, and 108 receivers can only receive data from it. Receive capable feeds have 109 both send and receive capabilities. 111 This mechanism has been designed to work with any topology with any 112 number of receivers and one or more feeds. However, it is expected 113 that the number of feeds will be small. In particular, the special 114 case of a single send-only feed and multiple receivers is among the 115 topologies supported. 117 A receiver has several interfaces, a receive-only interface and one 118 or more additional bidirectional communication interfaces. 120 A feed has several interfaces, a send-only or a send-and-receive 121 capable interface connected to the unidirectional link and one or 122 more additional bidirectional communication interfaces. A feed MUST 123 be a router. 125 Tunnels are constructed between the bidirectional interfaces of 126 nodes, so these interfaces must be interconnected by an IP 127 infrastructure. In this document we assume that that infrastructure 128 is the Internet. 130 Figure 1 depicts a generic topology with several feeds and several 131 receivers. 133 Unidirectional Link 135 ---->---------->------------------->------ 136 | | | | 137 |f1u |f2u |r2u |r1u 138 -------- -------- -------- -------- ---------- 139 |Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A| 140 -------- -------- -------- -------- ---------- 141 |f1b |f2b |r2b |r1b | 142 | | | | | 143 ---------------------------------------------------- 144 | Internet | 145 ---------------------------------------------------- 146 Figure 1: Generic topology 148 f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2) 149 send-only interface. 151 f1b (resp. f2b) is the IP address of the 'Feed 1' (resp. Feed 2) 152 bidirectional interface connected to the Internet. 154 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 155 2) receive-only interface. 157 r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 158 2) bidirectional interface connected to the Internet. 160 Subnet A is a local area network connected to recv1. 162 Note that nodes have IP addresses on their unidirectional and their 163 bidirectional interfaces. The addresses on the unidirectional 164 interfaces (f1u, f2u, r1u, r2u) will be drawn from the same IP 165 network. In general the addresses on the bidirectional interfaces 166 (f1b, f2b, r1b, r2b) will be drawn from different IP networks, and 167 the Internet will route between them. 169 4. Problems related to unidirectional links 171 Receive-only interfaces are "dumb" and send-only interfaces are 172 "deaf". Thus a datagram passed to the link-layer driver of a 173 receive-only interface is simply discarded. The link-layer of a 174 send-only interface never receives anything. 176 The network layer has no knowledge of the underlying transmission 177 technology except that it considers its access as bidirectional. 178 Basically, for outgoing datagrams, the network layer selects the 179 correct first hop on the connected network according to a routing 180 table and passes the packet(s) to the appropriate link-layer driver. 182 Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. 183 However, if Recv 1 initiates a 'ping f1u', it cannot get a response 184 from Feed 1. The network layer of Recv 1 delivers the packet to the 185 driver of the receive-only interface, which obviously cannot send it 186 to the feed. 188 Many protocols in the Internet assume that links are bidirectional. 189 In particular, routing protocols used by directly connected routers 190 no longer behave properly in the presence of a unidirectional link. 192 5. Emulating a broadcast bidirectional network 194 The simplest solution is to emulate a broadcast capable link-layer 195 network. This will allow the immediate deployment of existing higher 196 level protocols without change. Though other network structures, such 197 as NBMA, could also be emulated, a broadcast network is more 198 generally useful. Though a layer 3 network could be emulated, a 199 link-layer network allows the immediate use of any other network 200 layer protocols, and most particularly allows the immediate use of 201 ARP. 203 A link-layer tunneling mechanism which emulates bidirectional 204 connectivity in the presence of a unidirectional link will be 205 described in the next Section. We first consider the various 206 communication scenarios which characterize a broadcast network in 207 order to define what functionalities the link-layer tunneling 208 mechanism has to perform in order to emulate a bidirectional 209 broadcast link. 211 Here we enumerate the scenarios which would be feasible on a 212 broadcast network, i.e. if feeds and receivers were connected by a 213 bidirectional broadcast link: 215 Scenario 1: A receiver can send a packet to a feed (point-to-point 216 communication between a receiver and a feed). 218 Scenario 2: A receiver can send a broadcast/multicast packet on the 219 link to all nodes (point-to-multipoint). 221 Scenario 3: A receiver can send a packet to another receiver (point- 222 to-point communication between two receivers). 224 Scenario 4: A feed can send a packet to a send-only feed (point-to- 225 point communication between two feeds). 227 Scenario 5: A feed can send a broadcast/multicast packet on the link 228 to all nodes (point-to-multipoint). 230 Scenario 6: A feed can send a packet to a receiver or a receive 231 capable feed (point-to-point). 233 These scenarios are possible on a broadcast network. Scenario 6 is 234 already feasible on the unidirectional link. The link-layer tunneling 235 mechanism should therefore provide the functionality to support 236 scenarios 1 to 5. 238 Note that regular IP forwarding over such an emulated network (i.e. 239 using the emulated network as a transit network) works correctly; the 240 next hop address at the receiver will be the unidirectional link 241 address of another router (a feed or a receiver) which will then 242 relay the packet. 244 6. Link-layer tunneling mechanism 246 This link-layer tunneling mechanism operates underneath the network 247 layer. Its aim is to emulate bidirectional link-layer connectivity. 248 This is transparent to the network layer: the link appears and 249 behaves to the network layer as if it was bidirectional. 251 Figure 2 depicts a layered representation of the link-layer tunneling 252 mechanism in the case of Scenario 1. 254 Send-only Feed Receiver 256 decapsulation encapsulation 257 /-----***************----\ /-->---***************--\ 258 | | | | 259 | | | | 260 --|---------------------- | | ---------------------|--- 261 | | f1b | f1u | | | | x r1u | r1b | | 262 | | | ^ | | IP | | | | v | 263 | ^ | | | v | | | | | | 264 | | | | | | | | v | | | 265 |-|---------|-------|---| | | |----|------|--------|--| 266 | | | | | | ^ | | | | | 267 | | | | | | LL | | | | | | 268 | | | | | | | | | | | | 269 | | | O------/ \<------O | | | 270 |-|---------|-----------| |-----------|--------|--| 271 | | | | | | | | 272 | | | | PHY | | | | 273 | | | | | | v | 274 | | | | | | | | | | 275 --|-----------|---------- ----------|----------|--- 276 | Bidir | Send-Only Recv-Only | Bidir | 277 ^ Interf | Interf UDL Interf | Interf | 278 | \------------>------->------------/ | 279 \----------------------<------------------------<--------/ 280 Bidirectional network 282 x : IP layer at the receiver generates a datagram to be forwarded 283 on the receive-only interface. 284 O : Entry point where the link-layer tunneling mechanism is 285 triggered. 287 Figure 2: Scenario 1 using the link-layer Tunneling Mechanism 289 6.1. Tunneling mechanism on the receiver 291 On the receiver, a datagram is delivered to the link-layer of the 292 unidirectional interface for transmission (see Figure 2). It is then 293 encapsulated within a MAC header corresponding to the unidirectional 294 link. This packet cannot be sent directly over the link, so it is 295 then processed by the tunneling mechanism. 297 The packet is encapsulated within an IP header whose destination is 298 the IP address of a feed bidirectional interface (f1b or f2b). This 299 destination address is also called the tunnel end-point. The 300 mechanism for a receiver to learn these addresses and to choose the 301 feed is explained in Section 7. The type of encapsulation is 302 described in Section 8. 304 In all cases the packet is encapsulated, but the tunnel end-point (an 305 IP address) depends on the encapsulated packet's destination MAC 306 address. If the destination MAC address is: 308 1) the MAC address of a feed interface connected to the 309 unidirectional link (Scenario 1). The datagram is encapsulated, 310 the destination address of the encapsulating datagram is the 311 feed tunnel end-point (f1b referring to Figure 2). 313 2) a MAC broadcast/multicast address (Scenario 2). The datagram is 314 encapsulated, the destination address of the encapsulating 315 datagram is the default feed tunnel end-point. See Section 7.4 316 for further details on the default feed. 318 3) a MAC address that belongs to the unidirectional network but is 319 not a feed address (Scenario 3). The datagram is encapsulated, 320 the destination address of the encapsulating datagram is the 321 default feed tunnel end-point. 323 The encapsulated datagram is passed to the network layer which 324 forwards it according to its destination address. The destination 325 address is a feed bidirectional interface which is reachable via the 326 Internet. In this case, the encapsulated datagram is forwarded via 327 the receiver bidirectional interface (r1b). 329 6.2. Tunneling mechanism on the feed 331 A feed processes unidirectional link related packets in two different 332 ways: 333 - packets generated by a local application or packets routed as 334 usual by the IP layer may have to be forwarded over the 335 unidirectional link (Section 6.2.1) 336 - encapsulated packets received from another receiver or feed need 337 tunnel processing (Section 6.2.2). 339 A feed cannot directly send a packet to a send-only feed over the 340 unidirectional link (Scenario 4). In order to emulate this type of 341 communication, feeds have to tunnel packets to send-only feeds. A 342 feed MUST maintain a list of all other feed tunnel end-points. This 343 list MUST indicate which are send-only feed tunnel end-points. This 344 is configured manually at the feed by the local administrator, as 345 described in Section 7. 347 6.2.1. Forwarding packets over the unidirectional link 349 When a datagram is delivered to the link-layer of the unidirectional 350 interface of a feed for transmission, its treatment depends on the 351 packet's destination MAC address. If the destination MAC address is: 353 1) the MAC address of a receiver or a receive capable feed 354 (Scenario 6). The packet is sent over the unidirectional link. 355 This is classical "forwarding". 357 2) the MAC address of a send-only feed (Scenario 4). The packet is 358 encapsulated and sent to the send-only feed tunnel end-point. 359 The type of encapsulation is described in Section 8. 361 3) a broadcast/multicast destination (Scenario 5). The packet is 362 sent over the unidirectional link. Concurrently, a copy of this 363 packet is encapsulated and sent to every feed of the list of 364 send-only feed tunnel end-points. Thus the broadcast/multicast 365 will reach all receivers and all send-only feeds. 367 6.2.2. Receiving encapsulated packets 369 Feeds listen for incoming encapsulated datagrams on their tunnel end- 370 points. Encapsulated packets will have been received on a 371 bidirectional interface, and traversed their way up the IP stack. 372 They will then enter a decapsulation process (See Figure 2). 374 Decapsulation reveals the original link-layer packet. Note that this 375 has not been modified in any way by intermediate routers; in 376 particular, the original MAC header will be intact. 378 Further actions depend on the destination MAC address of the link- 379 layer packet, which can be: 381 1) the MAC address of the feed interface connected to the 382 unidirectional link, i.e. own MAC address (Scenarios 1 and 4). 383 The packet is passed to the link-layer of the interface 384 connected to the unidirectional link which can then deliver it 385 up to higher layers. As a result, the datagram is processed as 386 if it was coming from the unidirectional link, and being 387 delivered locally. Scenarios 1 and 4 are now feasible, a 388 receiver or a feed can send a packet to a feed. 390 2) a receiver address (Scenario 3). The packet is passed to the 391 link-layer of the interface connected to the unidirectional 392 link. It is directly sent over the unidirectional link, to the 393 indicated receiver. Note, the packet must not be delivered 394 locally. Scenario 3 is now feasible, a receiver can send a 395 packet to another receiver. 397 3) a broadcast/multicast address, this corresponds to Scenarios 2 398 and 5. We have to distinguish two cases, either (i) the 399 encapsulated packet was sent from a receiver or (ii) from a feed 400 (encapsulated broadcast/multicast packet sent to a send-only 401 feed). These cases are distinguished by examining the source 402 address of the encapsulating packet and comparing it with the 403 configured list of feed IP addresses. The action then taken is: 405 i) the feed was designated as a default feed by a receiver to 406 forward the broadcast/multicast packet. The feed is then in 407 charge of sending the multicast packet to all nodes. Delivery 408 to all nodes is accomplished by executing all 3 of the 409 following actions: 410 - The packet is encapsulated and sent to the list of send- 411 only feed tunnel end-points. 412 - Also, the packet is passed to the link-layer of the 413 interface which forwards it directly over the 414 unidirectional link (all receivers and receive capable 415 feeds receive it). 416 - Also, the link-layer delivers it locally to higher layers. 417 Caution: a receiver which sends an encapsulated 418 broadcast/multicast packet to a default feed will receive its 419 own packet via the unidirectional link. Correct filtering as 420 described in [rfc1112] must be applied. 422 ii) the feed receives the packet and keeps it for local 423 delivery. The packet is passed to the link-layer of the 424 interface connected to the unidirectional link which delivers 425 it to higher layers. 427 Scenario 2 is now feasible, a receiver can send a 428 broadcast/multicast packet over the unidirectional link and it 429 will be heard by all nodes. 431 7. Dynamic Tunnel Configuration Protocol (DTCP) 433 Receivers and feeds have to know the feed tunnel end-points in order 434 to forward encapsulated datagrams (e.g. Scenarios 1 and 4). 436 The number of feeds is expected to be relatively small (Section 3), 437 so at every feed the list of all feeds is configured manually. This 438 list should note which are send-only feeds, and which are receive 439 capable feeds. The administrator sets up tunnels to all send-only 440 feeds. A tunnel end-point is an IP address of a bidirectional link on 441 a send-only feed. 443 For scalability reasons, manual configuration cannot be done at the 444 receivers. Tunnels must be configured and maintained dynamically by 445 receivers, both for scalability, and in order to cope with the 446 following events: 448 1) New feed detection. 449 When a new feed comes up, every receiver must create a tunnel to 450 enable bidirectional communication with it. 452 2) Loss of unidirectional link detection. 453 When the unidirectional link is down, receivers must disable 454 their tunnels. The tunneling mechanism emulates bidirectional 455 connectivity between nodes. Therefore, if the unidirectional 456 link is down, a feed should not receive datagrams from the 457 receivers. Protocols that consider a link as operational if they 458 receive datagrams from it (e.g. the RIP protocol [rfc2453]) 459 require this behavior for correct operation. 461 3) Loss of feed detection. 462 When a feed is down, receivers must disable their corresponding 463 tunnel. This prevents unnecessary datagrams from being tunneled 464 which might overload the Internet. For instance, there is no 465 need for receivers to forward a broadcast message through a 466 tunnel whose end-point is down. 468 The DTCP protocol provides a means for receivers to dynamically 469 discover the presence of feeds and to maintain a list of operational 470 tunnel end-points. Feeds periodically announce their tunnel end-point 471 addresses over the unidirectional link. Receivers listen to these 472 announcements and maintain a list of tunnel end-points. 474 7.1. The HELLO message 476 The DTCP protocol is a 'unidirectional protocol', messages are only 477 sent from feeds to receivers. 479 The packet format is shown in Figure 3. Fields contain binary 480 integers, in normal Internet order with the most significant bit 481 first. Each tick mark represents one bit. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Vers | Com | Interval | Sequence | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Feed BDL IP addr (FBIP1) (32/128 bits) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | ..... | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Feed BDL IP addr (FBIPn) (32/128 bits) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 3: Packet Format 499 Every datagram contains the following fields, note that constants are 500 written in uppercase and are defined in Section 7.5: 502 Vers (4 bit unsigned integer): DTCP version number. MUST be 503 DTCP_VERSION. 505 Com (4 bit unsigned integer): Command field, possible values are 506 1 - JOIN A message announcing that the feed sending this message 507 is up and running. 508 2 - LEAVE A message announcing that the feed sending this message 509 is being shut down. 511 Interval (8 bit unsigned integer): Interval in seconds between HELLO 512 messages for the IP protocol in "IP Vers". Must be > 0. The 513 recommended value is HELLO_INTERVAL. If this value is increased, 514 the feed MUST continue to send HELLO messages at the old rate for 515 at least the old HELLO_LEAVE period. 517 Sequence (16 bit unsigned integer): Random value initialized at boot 518 time and incremented by 1 every time a value of the HELLO message 519 is modified. 521 res (3 bits): Reserved/unused field, MUST be zero. 523 F (1 bit): bit indicating the type of feed: 524 0 = Send-only feed 525 1 = Receive-capable feed 527 IP Vers (4 bit unsigned integer): IP protocol version of the feed 528 bidirectional IP addresses (FBIP): 529 4 = IP version 4 530 6 = IP version 6 532 Tunnel Type (8 bit unsigned integer): tunneling protocol supported by 533 the feed. This value is the IP protocol number defined in [rfc1700] 534 [iana/protocol-numbers] and their legitimate descendents. Receivers 535 MUST use this form of tunnel encapsulation when tunneling to the 536 feed. 537 47 = GRE [rfc2784] (recommended) 538 Other protocol types allowing link-layer encapsulation are 539 permitted. Obtaining new values is documented in [rfc2780]. 541 Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed 542 addresses which are enumerated in the HELLO message 544 reserved (8 bits): Reserved/unused field, MUST be zero. 546 Feed BDL IP addr (32 or 128 bits). The bidirectional IP address feed 547 is the IP address of a feed bidirectional interface (tunnel end- 548 point) reachable via the Internet. A feed has 'Nb of FBIP' IP 549 addresses which are operational tunnel end-points. They are 550 enumerated in preferred order. FBIP1 being the most suitable tunnel 551 end-point. 553 7.2. DTCP on the feed: sending HELLO packets 555 The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP 556 announcement" multicast address over the unidirectional link on port 557 HELLO_PORT with a TTL of 1. 559 The source address of the HELLO packet is set to the IP address of 560 the feed interface connected to the unidirectional link. In the rest 561 of the document, this value is called FUIP (Feed Unidirectional IP 562 address). 564 The process in charge of sending HELLO packets fills every field of 565 the datagram according to the description given in Section 7.1. 567 As long as a feed is up and running, it periodically announces its 568 presence to receivers. It MUST send HELLO packets containing a JOIN 569 command every HELLO_INTERVAL over the unidirectional link. 571 Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO 572 messages with the FBIP1 field set to f1b (resp. f2b). 574 When a feed is about to be shut down, or when routing over the 575 unidirectional link is about to be intentionally interrupted, it is 576 recommended that feeds: 578 1) stop sending HELLO messages containing a JOIN command. 580 2) send a HELLO message containing a LEAVE command to inform 581 receivers that the feed is no longer performing routing over the 582 unidirectional link. 584 7.3. DTCP on the receiver: receiving HELLO packets 586 Based on the reception of HELLO messages, receivers discover the 587 presence of feeds, maintain a list of active feeds, and keep track of 588 the tunnel end-points for those feeds. 590 For each active feed, and each IP protocol supported, at least the 591 following information will be kept: 592 FUIP - feed unidirectional link IP address 593 FUMAC - MAC address corresponding to the above IP 594 address 595 (FBIP1,...,FBIPn) - list of tunnel end-points 596 tunnel type - tunnel type supported by this feed 597 Sequence - "Sequence" value from the last HELLO received 598 from this feed 599 timer - used to timeout this entry 601 The FUMAC value for an active feed is needed for the operation of 602 this protocol. However, the method of discovery of this value is not 603 specified here. 605 Initially, the list of active feeds is empty. 607 When a receiver is started, it MUST run a process which joins the 608 "DTCP announcement" multicast group and listens to incoming packets 609 on the HELLO_PORT port from the unidirectional link. 611 Upon the reception of a HELLO message, the process checks the version 612 number of the protocol. If it is different from HELLO_VERSION, the 613 packet is discarded and the process waits for the next incoming 614 packet. 616 After successfully checking the version number further action depends 617 on the type of command: 619 - JOIN: 621 The process verifies if the address FUIP already belongs to the 622 list of active feeds. 624 If it does not, a new entry, for feed FUIP, is created and added 625 to the list of active feeds. The number of feed bidirectional IP 626 addresses to read is deduced from the 'Nb of FBID' field. These 627 tunnel end-points (FBIP1,...,FBIPn) can then be added to the new 628 entry. The tunnel Type and Sequence values are also taken from the 629 HELLO packet and recorded in the new entry. A timer set to 630 HELLO_LEAVE is associated with this entry. 632 If it does, the sequence number is compared to the sequence number 633 contained in the previous HELLO packet sent by this feed. If they 634 are equal, the timer associated with this entry is reset to 635 HELLO_LEAVE. Otherwise all the information corresponding to FUIP 636 is set to the values from the HELLO packet. 638 Referring to Figure 1 in Section 3, both receivers (recv 1 and 639 recv 2) have a list of active feeds containing two entries: Feed 1 640 with a FUIP of f1u and a list of tunnel end-points (f1b); and Feed 641 2 with a FUIP of f2u and a list of tunnel end-points (f2b). 643 - LEAVE: 645 The process checks if there is an entry for FUIP in the list of 646 active feeds. If there is, the timer is disabled and the entry is 647 deleted from the list. The LEAVE message provides a means of 648 quickly updating the list of active feeds. 650 A timeout occurs for either of two reasons: 652 1) a feed went down without sending a LEAVE message. As JOIN 653 messages are no longer sent from this feed, a timeout occurs at 654 HELLO_LEAVE after the last JOIN message. 656 2) the unidirectional link is down. Thus no more JOIN messages are 657 received from any of the feeds, and they will each timeout 658 independently. The timeout of each entry depends on its 659 individual HELLO_LEAVE value, and when the last JOIN message was 660 sent by that feed, before the unidirectional link went down. 662 In either case, bidirectional connectivity can no longer be ensured 663 between the receiver and the feed (FUIP): either the feed is no 664 longer routing datagrams over the unidirectional link, or the link is 665 down. Thus the associated entry is removed from the list of active 666 feeds, whatever the cause. As a result, the list only contains 667 operational tunnel end-points. 669 The HELLO protocol provides receivers with a list of feeds, and a 670 list of usable tunnel end-points (FBIP1,..., FBIPn) for each feed. In 671 the following Section, we describe how to integrate the HELLO 672 protocol into the tunneling mechanism described in Sections 6.1 and 673 6.2. 675 7.4. Tunneling mechanism using the list of active feeds 676 This Section explains how the tunneling mechanism uses the list of 677 active feeds to handle datagrams which are to be tunneled. Referring 678 to Section 6.1, it shows how feed tunnel end-points are selected. 680 The choice of the default feed is made independently at each 681 receiver. The choice is a matter of local policy, and this policy is 682 out of scope for this document. However, as an example, the default 683 feed may be the feed that has the lowest round trip time to the 684 receiver. 686 When a receiver sends a packet to a feed, it must choose a tunnel 687 end-point from within the FBIP list. The 'preferred FBIP' is 688 generally FBIP1 (Section 7.1). For various reasons, a receiver may 689 decide to use a different FBIP, say FBIPi instead of FBIP1, as the 690 tunnel end-point. For example, the receiver may have better 691 connectivity to FBIPi. This decision is taken by the receiver 692 administrator. 694 Here we show how the list of active feeds is involved when a receiver 695 tunnels a link-layer packet. Section 6.1 listed the following cases, 696 depending on whether the MAC destination address of the packet is: 698 1) the MAC address of a feed interface connected to the 699 unidirectional link: This is TRUE if the address matches a FUMAC 700 address in the list of active feeds. The packet is tunneled to 701 the preferred FBIP of the matching feed. 703 2) the broadcast address of the unidirectional link or a multicast 704 address: 705 This is determined by the MAC address format rules, and the list 706 of active feeds is not involved. The packet is tunneled to the 707 preferred FBIP of the default feed. 709 3) an address that belongs to the unidirectional network but is not 710 a feed address: 711 This is TRUE if the address is neither broadcast nor multicast, 712 nor found in the list of active feeds. The packet is tunneled to 713 the preferred FBIP of the default feed. 715 In all cases, the encapsulation type depends on the tunnel type 716 required by the feed which is selected. 718 7.5. Constant definitions 720 DTCP_VERSION is 1. 722 HELLO_INTERVAL is 5 seconds. 724 "DTCP announcement" multicast group is 224.0.1.124. 726 HELLO_PORT is 652. It is a reserved system port, no other traffic 727 must be allowed. 729 HELLO_LEAVE is 3*Interval, as advertised in a HELLO packet, i.e. 15 730 seconds if the default HELLO_INTERVAL was advertised. 732 8. Tunnel encapsulation format 734 The tunneling mechanism operates at the link-layer and emulates 735 bidirectional connectivity amongst receivers and feeds. We assume 736 that hardware connected to the unidirectional link supports broadcast 737 and unicast MAC addressing. That is, a feed can send a packet to a 738 particular receiver using a unicast MAC destination address or to a 739 set of receivers using a broadcast/multicast destination address. The 740 hardware (or the driver) of the receiver can then filter the incoming 741 packets sent over the unidirectional links without any assumption 742 about the encapsulated data type. 744 In a similar way, a receiver should be capable of sending unicast and 745 broadcast MAC packets via its tunnels. Link-layer packets are 746 encapsulated. As a result, after decapsulating an incoming packet, 747 the feed can perform link-layer filtering as if the data came 748 directly from the unidirectional link (See Figure 2). 750 Generic Routing Encapsulation (GRE) [rfc2784] suits our requirements 751 because it specifies a protocol for encapsulating arbitrary packets, 752 and allows use of IP as the delivery protocol. 754 The feed's local administrator decides what encapsulation it will 755 demand that receivers use, and sets the tunnel type field in the 756 HELLO message appropriately. The value 47 (decimal) indicates GRE. 757 Other values can be used, but their interpretation must be agreed 758 upon between feeds and receivers. Such usage is not defined here. 760 8.1. Generic Routing Encapsulation on the receiver 762 A GRE packet is composed of a header in which a type field specifies 763 the encapsulated protocol (ARP, IP, IPX, etc.). See [rfc2784] for 764 details about the encapsulation. In our case, only support for the 765 MAC addressing scheme of the unidirectional link MUST be implemented. 767 A packet tunneled with a GRE encapsulation has the following format: 768 the delivery header is an IP header whose destination is the tunnel 769 end-point (FBIP), followed by a GRE header specifying the link-layer 770 type of the unidirectional link. Figure 4 presents the entire 771 encapsulated packet. 773 ---------------------------------------- 774 | IP delivery header | 775 | destination addr = FBIP | 776 | IP proto = GRE (47) | 777 ---------------------------------------- 778 | GRE Header | 779 | type = MAC type of the UDL | 780 ---------------------------------------- 781 | Payload packet | 782 | MAC packet | 783 ---------------------------------------- 785 Figure 4: Encapsulated packet 787 9. Issues 789 9.1. Hardware address resolution 791 Regardless of whether the link is unidirectional or bidirectional, if 792 a feed sends a packet over a non-point-to-point type network, it 793 requires the data link address of the destination. ARP [rfc826] is 794 used on Ethernet networks for this purpose. 796 The link-layer mechanism emulates a bidirectional network in the 797 presence of an unidirectional link. However, there are asymmetric 798 delays between every (feed, receiver) pair. The backchannel between a 799 receiver and a feed has varying delays because packets go through the 800 Internet. Furthermore, a typical example of a unidirectional link is 801 a GEO satellite link whose delay is about 250 milliseconds. 803 Because of long round trip delays, reactive address resolution 804 methods such as ARP [rfc826] may not work well. For example, a feed 805 may have to forward packets at high data rates to a receiver whose 806 hardware address is unknown. The stream of packets is passed to the 807 link-layer driver of the feed send-only interface. When the first 808 packet arrives, the link-layer realizes it does not have the 809 corresponding hardware address of the next hop, and sends an ARP 810 request. While the link-layer is waiting for the response (at least 811 250 ms for the GEO satellite case), IP packets are buffered by the 812 feed. If it runs out of space before the ARP response arrives, IP 813 packets will be dropped. 815 This problem of address resolution protocols is not addressed in this 816 document. An ad-hoc solution is possible when the MAC address is 817 configurable, which is possible in some satellite receiver cards. A 818 simple transformation (maybe null) of the IP address can then be used 819 as the MAC address. In this case, senders do not need to "resolve" an 820 IP address to a MAC address, they just need to perform the simple 821 transformation. 823 9.2. Routing protocols 825 The link-layer tunneling mechanism hides from the network and higher 826 layers the fact that feeds and receivers are connected by a 827 unidirectional link. Communication is bidirectional, but asymmetric 828 in bandwidths and delays. 830 In order to incorporate unidirectional links in the Internet, feeds 831 and receivers might have to run routing protocols in some topologies. 832 These protocols will work fine because the tunneling mechanism 833 results in bidirectional connectivity between all feeds and 834 receivers. Thus routing messages can be exchanged as on any 835 bidirectional network. 837 The tunneling mechanism allows any IP traffic, not just routing 838 protocol messages, to be forwarded between receivers and feeds. 839 Receivers can route datagrams on the Internet using the most suitable 840 feed or receiver as a next hop. Administrators may want to set the 841 metrics used by their routing protocols in order to reflect in 842 routing tables the asymmetric characteristics of the link, and thus 843 direct traffic over appropriate paths. 845 Feeds and receivers may implement multicast routing and therefore 846 dynamic multicast routing can be performed over the unidirectional 847 link. However issues related to multicast routing (e.g. protocol 848 configuration) are not addressed in this document. 850 9.3. Scalability 852 The DTCP protocol does not generate a lot of traffic whatever the 853 number of nodes. The problem with a large number of nodes is not 854 related to this protocol but to more general issues such as the 855 maximum number of nodes which can be connected to any link. This is 856 out of scope of this document. 858 10. Security Considerations 860 Many unidirectional link technologies are characterised by the ease 861 with which the link contents can be received. If sensitive or 862 valuable information is being sent, then link-layer security 863 mechanisms are an appropriate measure. For the UDLR protocol itself, 864 the feed tunnel end-point addresses, sent in HELLO messages, may be 865 considered sensitive. In such cases link-layer security mechanisms 866 may be used. 868 Security in a network using the link-layer tunneling mechanism should 869 be relatively similar to security in a normal IPv4 network. However, 870 as the link-layer tunneling mechanism requires the use of tunnels, it 871 introduces a potential for unauthorised access to the service. In 872 particular, ARP and IP spoofing are potential threats because nodes 873 may not be authorised to tunnel packets. This can be countered by 874 authenticating all tunnels. The authenticating mechanism is not 875 specified in this document, it can take place either in the delivery 876 IP protocol (e.g. AH[rfc2402]) or in an authentication protocol 877 integrated with the tunneling mechanism. 879 At a higher level, receivers may not be authorised to provide routing 880 information even though they are connected to the unidirectional 881 link. In order to prevent unauthorised receivers from providing fake 882 routing information, routing protocols running on top of the link- 883 layer tunneling mechanism MUST use authentication mechanisms when 884 available. 886 11. Acknowledgments 888 We would like to thank Tim Gleeson (Cisco Japan) for his valuable 889 editing and technical input during the finalization phase of the 890 document. 892 We would like to thank Patrick Cipiere (UDcast) for his valuable 893 input concerning the design of the encapsulation mechanism. 895 We would like also to thank for their participation: Akihiro Tosaka 896 (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi 897 Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), 898 Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu 899 (Sony CSL), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri 900 Hakulinen (Nokia). 902 A. Conformance and interoperability 904 This document describes a mechanism to emulate bidirectional 905 connectivity between nodes that are directly connected by a 906 unidirectional link. Applicability over a variety of equipment and 907 environments is ensured by allowing a choice of several key system 908 parameters. 910 Thus in order to ensure interoperability of equipment it is not 911 enough to simply claim conformance with the mechanism defined here. A 912 usage profile for a particular environment will require the 913 definition of several parameters: 914 - the MAC format used 915 - the tunneling mechanism to be used (GRE is recommended) 916 - the "tunnel type" indication if GRE is not used 918 For example, a system might claim to implement "the link-layer 919 tunneling mechanism for unidirectional links, using IEEE 802 LLC, and 920 GRE encapsulation for the tunnels." 922 References 924 [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, 925 November 1982. 927 [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford 928 University, August 1989 930 [rfc1700] 'ASSIGNED NUMBERS', J. Reynolds, J. Postel, ISI, October 931 1994 933 [rfc2119] 'Key words for use in RFCs to Indicate Requirement Levels', 934 S. Bradner, Harvard University, March 1997 936 [rfc2402] 'IP Authentication Header', S. Kent, BBN Corp, R. Atkinson, 937 @Home Network 939 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 941 [rfc2780] 'IANA Allocation Guidelines For Values In the Internet 942 Protocol and Related Headers', S. Bradner, Harvard 943 University, V. Paxson, ACIRI, March 2000 945 [rfc2784] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li, 946 Procket Networks, S. Hanks, Enron Communications, D. Meyer, 947 Cisco Systems, P. Traina, Juniper Networks, March 2000 949 Author's address 951 Emmanuel Duros 952 UDcast 953 Les Taissounieres - HB3 954 1681, route des Dolines 955 06560 Sophia-Antipolis 956 France 957 Phone : +33 4 93 00 16 60 958 Fax : +33 4 93 00 16 61 959 Email : Emmanuel.Duros@UDcast.com 961 Walid Dabbous 962 INRIA Sophia Antipolis 963 2004, Route des Lucioles BP 93 964 06902 Sophia Antipolis 965 France 966 Phone : +33 4 92 38 77 18 967 Fax : +33 4 92 38 79 78 968 Email : Walid.Dabbous@inria.fr 970 Hidetaka Izumiyama 971 JSAT Corporation 972 Toranomon 17 Mori Bldg.5F 973 1-26-5 Toranomon, Minato-ku 974 Tokyo 105 975 Japan 976 Voice : +81-3-5511-7568 977 Fax : +81-3-5512-7181 978 Email : izu@jsat.net 980 Noboru Fujii 981 Sony Corporation 982 2-10-14 Osaki, Shinagawa-ku 983 Tokyo 141 984 Japan 985 Voice : +81-3-3495-3092 986 Fax : +81-3-3495-3527 987 Email : fujii@dct.sony.co.jp 989 Yongguang Zhang 990 HRL 991 RL-96, 3011 Malibu Canyon Road 992 Malibu, CA 90265, 993 USA 994 Phone : 310-317-5147 995 Fax : 310-317-5695 996 Email : ygz@hrl.com