idnits 2.17.1 draft-ietf-ipdvb-ar-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1817. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Category: Draft intended as INFORMATIONAL', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (March 2007) is 6245 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) == Missing Reference: 'DVB-DAT' is mentioned on line 124, but not defined == Missing Reference: 'IEEE-802.3' is mentioned on line 301, but not defined == Missing Reference: 'ATSC-A90G' is mentioned on line 320, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-MHP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-SI' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG2' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) -- No information found for draft-ietf-ipdvb-sec-req-xx - is the name correct? == Outdated reference: A later version (-02) exists of draft-daley-send-spnd-prob-01 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3451 (Obsoleted by RFC 5651) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gorry Fairhurst 3 Internet Draft University of Aberdeen 4 Expires: September 1, 2007 Marie-Jose Montpetit 5 Motorola Connected 6 Home Solutions 8 Category: Draft intended as INFORMATIONAL March 2007 10 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks 11 draft-ietf-ipdvb-ar-06.txt 13 Status of this Draft 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 1, 2007. 38 Abstract 40 This document describes the process of binding/associating IPv4/IPv6 41 addresses with MPEG-2 Transport Streams (TS). This procedure is 42 known as Address Resolution (AR), or Neighbour Discovery (ND). Such 43 address resolution complements the higher layer resource discovery 44 tools that are used to advertise IP sessions. 46 In MPEG-2 Networks, an IP address must be associated with a Packet 47 ID (PID) value and a specific Transmission Multiplex. The document 48 reviews current methods appropriate to a range of technologies (DVB, 49 ATSC, DOCSIS, and variants). It also describes the interaction with 50 well-known protocols for address management including DHCP, ARP, and 51 the ND protocol, and provides guidance on usage. 53 Table of Contents 55 1. Introduction 56 1.1 Bridging and Routing 58 2. Convention used in the document 60 3. Address Resolution Requirement 61 3.1 Unicast Support 62 3.2 Multicast Support 64 4. MPEG-2 Address Resolution 65 4.1 Static configuration. 66 4.1.1 MPEG-2 Cable Networks 67 4.2 MPEG-2 Table-Based Address Resolution 68 4.2.1 IP/MAC Notification Table (INT) and its usage 69 4.2.2 Multicast Mapping Table (MMT) and its usage 70 4.2.3 Application Information Table (AIT) and its usage 71 4.2.4 Address Resolution in ATSC 72 4.2.5 Comparison of SI/PSI table approaches 73 4.3 IP-based address resolution for TS Logical Channels 74 4.3.1 IP-based multicast resolution of TS Logical Channels 76 5. Mapping IP addresses to MAC/NPA addresses 77 5.1 Uni-directional links supporting uni-directional connectivity 78 5.2 Uni-directional links with bi-directional connectivity 79 5.3 Bi-directional links 80 5.4 AR Server 81 5.5 DHCP Tuning 82 5.6 IP Multicast AR 83 5.6.1 Multicast/Broadcast addressing for UDLR 85 6. Link Layer Support 86 6.1 ULE without a destination MAC/NPA address (D=1) 87 6.2 ULE with a destination MAC/NPA address (D=0) 88 6.3 MPE without LLC/SNAP Encapsulation 89 6.4 MPE with LLC/SNAP Encapsulation 90 6.5 ULE with Bridging Header Extension (D=1) 91 6.6 ULE with Bridging Header Extension and NPA Address (D=0) 92 6.7 MPE with LLC/SNAP and Bridging 94 7. Conclusions 96 8. Security Considerations 97 9. Acknowledgements 98 10. References 99 11. Author's Addresses 100 12. IPR Notices 101 13. Copyright Statements 102 14. IANA Considerations 103 1. Introduction 105 The MPEG-2 Transport Stream (TS) provides a time-division 106 multiplexed (TDM) stream that may contain audio, video and data 107 information, including encapsulated IP Datagrams [RFC4259], defined 108 in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 (L2) 109 frame, known as a TS Packet, contains a 4 byte header and a 184 byte 110 payload. Each TS Packet is associated with a single TS Logical 111 Channel, identified by a 13-bit Packet ID (PID) value that is 112 carried in the MPEG-2 TS Packet header. 114 The MPEG-2 standard also defines a control plane that may be used to 115 transmit control information to Receivers in the form of System 116 Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific 117 Information (PSI) Tables. 119 To utilize the MPEG-2 TS as a Layer-2 (L2) link supporting IP, a 120 sender must associate an IP address with a particular Transmission 121 Multiplex, and within the multiplex identify the specific PID to be 122 used. This document calls this mapping an Address Resolution (AR) 123 function. In some AR schemes, the MPEG-2 TS address space is sub- 124 divided into logical contexts known as Platforms [DVB-DAT]. Each 125 Platform associates an IP service provider with a separate context 126 that share a common MPEG-2 TS (use the same PID value). 128 MPEG-2 Receivers may use a Network Point of Attachment (NPA) 129 [RFC4259] to uniquely identify a L2 node within an MPEG-2 130 transmission network. An example of an NPA is the IEEE Medium Access 131 Control (MAC) address. Where such addresses are used, these must 132 also be signalled by the AR procedure. Finally, address resolution 133 could signal the format of the data being transmitted, for example, 134 the encapsulation, any L2 encryption method and any compression 135 scheme [RFC4259]. 137 The numbers of Receivers connected via a single MPEG-2 link may be 138 much larger than found in other common LAN technologies, (e.g. 139 Ethernet). This has implications on design/configuration of the 140 address resolution mechanisms. Current routing protocols, and some 141 multicast application protocols also do not scale to arbitrary large 142 numbers of participants. Such networks do not by themselves 143 introduce an appreciable subnetwork round trip delay, however many 144 practical MPEG-2 transmission networks are built using links that 145 may introduce significant path delay (satellite links, use of dial- 146 up modem return, cellular return, etc). This higher delay may need 147 to be accommodated for by address resolution protocols that use this 148 service. 150 1.1 Bridging and Routing 152 The following two figures illustrate the use of AR for a routed and 153 a bridged subnetwork. Various other combinations of L2 and L3 154 forwarding may also be used over MPEG-2 links (including Receivers 155 that are IP end hosts and end hosts directly connected to bridged 156 LAN segments). 158 Broadcast Link AR 159 - - - - - - - - - 160 | | 161 \/ 162 1a 2b 2a 163 +--------+ +--------+ 164 ----+ R1 +----------+---+ R2 +---- 165 +--------+ MPEG-2 | +--------+ 166 Link | 167 | +--------+ 168 +---+ R3 +---- 169 | +--------+ 170 | 171 | +--------+ 172 +---+ R4 +---- 173 | +--------+ 174 | 175 | 177 Figure 1: A routed MPEG-2 link feeding three downstream routers (R2- 178 R4). AR takes place at the Encapsulator (R1) to identify each 179 Receiver at Layer 2 within the IP subnetwork (R2, etc). 181 When considering unicast communication from R1 to R2, several L2 182 addresses are involved: 184 1a is the L2 (sending) interface address of R1 on the MPEG-2 link 185 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link 186 2a is the L2 (sending) interface address of R2 on the next hop link 188 AR for the MPEG-2 link allows R1 to determine the L2 address (2b) 189 corresponding to the next hop Receiver, router R2. 191 Figure 2 shows a bridged topology. The Encapsulator associates a 192 destination MAC/NPA address with each bridged PDU sent on an MPEG-2 193 link. Two methods are defined by ULE [RFC4326]: 195 The simplest method uses the L2 address of the transmitted frame. 196 This is the MAC address corresponding to the destination within the 197 L2 subnetwork (the next hop router, 2b of R2). This requires each 198 Receiver (B4) to associate the receiving MPEG-2 interface with the 199 set of MAC addresses that exist on the L2 subnetworks that it feeds. 200 Similar considerations apply when IP-based tunnels support L1/L2 201 services (including the use of UDLR [RFC3077]). 203 It is also possible for a bridging Encapsulator (B1) to encapsulate 204 a PDU with a link-specific header that also contains the MAC/NPA 205 address associated with a Receiver L2 interface on the MPEG-2 link 206 (figure 2). In this case, the destination MAC/NPA address of the 207 encapsulated frame is set to the Receiver MAC/NPA address (y), 208 rather than the address of the final L2 destination. At a different 209 level, an AR binding is also required for R1 to associate the 210 destination L2 address 2b with R2. In a subnetwork using bridging, 211 the systems R1, R2 will normally use standard IETF-defined AR 212 mechanisms (e.g. IPv4 Address Resolution Protocol, ARP [RFC826] and 213 the IPv6 Neighbor Discovery Protocol, ND [RFC2461) edge-to-edge 214 across the IP subnetwork. 216 Subnetwork AR 217 - - - - - - - - - - - - - - - - 218 | | 220 | MPEG-2 Link AR | 221 - - - - - - - - - 222 | | | | 223 \/ \/ 224 1a x y 2b 2a 225 +--------+ +----+ +----+ +--------+ 226 ----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +---- 227 +--------+ +----+ MPEG-2 | +----+ +--------+ 228 Link | 229 | +----+ 230 +---+ B3 +-- 231 | +----+ 232 | 233 | +----+ 234 +---+ B4 +-- 235 | +----+ 236 | 238 Figure 2: A bridged MPEG-2 link feeding three downstream bridges 239 (B2-B4). AR takes place at the Encapsulator (B1) to identify each 240 Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork 241 allowing the feed router (R1) to identify the downstream Routers at 242 Layer 2 (R2, etc). 244 Methods also exist to assign IP addresses to Receivers within a 245 network (e.g. stateless autoconfiguration [RFC2461], DHCP [RFC2131], 246 DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736]). Receivers may also 247 participate in remote configuration of the L3 IP addresses used in 248 connected equipment (e.g. using DHCP-Relay [RFC3046]). 250 The remainder of this document describes current mechanisms and 251 their use to associate an IP address with the corresponding TS 252 Multiplex, PID value, the MAC/NPA address and/or Platform ID. A 253 range of approaches is described, including Layer 2 mechanisms 254 (using MPEG-2 SI tables), and protocols at the IP level (including 255 ARP [RFC826] and the ND [RFC2461]). Interactions and dependencies 256 between these mechanisms and the encapsulation methods are 257 described. The document does not propose or define a new protocol, 258 but does provide guidance on issues that would need to be considered 259 to supply IP-based address resolution. 261 2. Conventions used in this document 263 AIT: Application Information Table specified by the Multimedia Home 264 Platform (MHP) specifications [ETSI-MHP]. This table may carry 265 IPv4/IPv6 to MPEG-2 TS address resolution information. 267 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 268 a set of associated standards for the transmission of video, audio, 269 and data using the ISO MPEG-2 standard [ISO-MPEG2]. 271 b: bit. For example, one byte consists of 8b. 273 B: Byte. Groups of bytes are represented in Internet byte order. 275 DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A 276 format for transmission of data and control information carried in 277 an MPEG-2 Private Section, defined by the ISO MPEG-2 standard. 279 DVB: Digital Video Broadcasting [DVB]. A framework and set of 280 associated standards published by the European Telecommunications 281 Standards Institute (ETSI) for the transmission of video, audio, and 282 data, using the ISO MPEG-2 Standard. 284 DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bi- 285 directional IPv4/IPv6 service employing low-cost Receivers. 287 Encapsulator: A network device that receives PDUs and formats these 288 into Payload Units (known here as SNDUs) for output as a stream of 289 TS Packets. 291 Feed Router: The router delivering the IP service over a 292 Unidirectional Link. 294 INT: Internet/MAC Notification Table. A uni-directional address 295 resolution mechanism using SI and/or PSI Tables. 297 L2: Layer 2, the link layer. 299 L3: Layer 3, the IP network layer. 301 MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol 302 defined by the IEEE 802.3 standard (or by Ethernet v2). 304 MAC Address: A 6 byte link layer address of the format described by 305 the Ethernet IEEE 802 standard (see also NPA). 307 MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE- 308 802.3 or Ethernet v2. It consists of a 6 byte destination 309 address, 6 byte source address, and 2 byte type field (see also NPA, 310 LLC). 312 MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia 313 receiver, that may (in some cases) support IPv4/IPv6 services [ETSI- 314 MHP]. 316 MMT: Multicast Mapping Table (proprietary extension to DVB-RCS 317 [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses 318 to PID values). 320 MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90], [ATSC- 321 A90G]. A method that encapsulates PDUs, forming a DSM-CC Table 322 Section. Each Section is sent in a series of TS Packets using a 323 single Stream (TS Logical Channel). 325 MPEG-2: A set of standards specified by the Motion Picture Experts 326 Group (MPEG), and standardized by the International Standards 327 Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 329 NPA: Network Point of Attachment. A 6 byte destination address 330 (resembling an IEEE MAC address) within the MPEG-2 transmission 331 network that is used to identify individual Receivers or groups of 332 Receivers [RFC4259]. 334 PAT: Program Association Table. An MPEG-2 PSI control table. It 335 associates each program with the PID value that is used to send the 336 associated PMT. The table is sent using the well-known PID value of 337 0x000, and is required for an MPEG-2 compliant Transport Stream. 339 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 340 IPv4 or IPv6 Datagrams, and other network packets. 342 PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the 343 header of each TS Packet. This identifies the TS Logical Channel to 344 which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the 345 parts of a Table Section, or other Payload Unit must all carry the 346 same PID value. The all ones PID value indicates a Null TS Packet 347 introduced to maintain a constant bit rate of a TS Multiplex. There 348 is no required relationship between the PID values used for TS 349 Logical Channels transmitted using different TS Multiplexes. 351 PMT: Program Map Table. An MPEG-2 PSI control table that associates 352 the PID values used by the set of TS Logical Channels/ Streams that 353 comprise a program [ISO-MPEG2]. The PID value used to send the PMT 354 for a specific program is defined by an entry in the PAT. 356 Private Section: A syntactic structure constructed according to 357 Table 2-30 of [ISO-MPEG2]. The structure may be used to identify 358 private information (i.e. not defined by [ISO-MPEG2]) relating to 359 one or more elementary streams, or a specific MPEG-2 program, or the 360 entire Transport Stream. Other Standards bodies, e.g. ETSI, ATSC, 361 have defined sets of table structures using the private_section 362 structure. A Private Section is transmitted as a sequence of TS 363 Packets using a TS Logical Channel. A TS Logical Channel may carry 364 sections from more than one set of tables. 366 PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey 367 information about services carried in a TS Multiplex. It is carried 368 in one of four specifically identified table section constructs 369 [ISO-MPEG2], see also SI Table. 371 Receiver: Equipment that processes the signal from a TS Multiplex 372 and performs filtering and forwarding of encapsulated PDUs to the 373 network-layer service (or bridging module when operating at the 374 link-layer). 376 SI Table: Service Information Table [ISO-MPEG2]. In this document, 377 this term describes a table that is been defined by another 378 standards body to convey information about the services carried in a 379 TS Multiplex. A Table may consist of one or more Table Sections, 380 however, all sections of a particular SI Table must be carried over 381 a single TS Logical Channel [ISO-MPEG2]. 383 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 384 Payload Unit. 386 Table Section: A Payload Unit carrying all or a part of an SI or PSI 387 Table [ISO-MPEG2]. 389 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 390 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 391 reference model. See also TS Logical Channel and TS Multiplex. 393 TS Logical Channel: Transport Stream Logical Channel. In this 394 document, this term identifies a channel at the MPEG-2 level [ISO- 395 MPEG2]. This exists at level 2 of the ISO/OSI reference model. All 396 packets sent over a TS Logical Channel carry the same PID value 397 (this value is unique within a specific TS Multiplex). The term 398 "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the 399 content carried by a specific TS Logical Channel (see, ULE Stream). 400 Some PID values are reserved (by MPEG-2) for specific signaling. 401 Other standards (e.g., ATSC, DVB) also reserve specific PID values. 403 TS Multiplex: In this document, this term defines a set of MPEG-2 TS 404 Logical Channels sent over a single lower layer connection. This may 405 be a common physical link (i.e. a transmission at a specified symbol 406 rate, FEC setting, and transmission frequency) or an encapsulation 407 provided by another protocol layer (e.g. Ethernet, or RTP over IP). 408 The same TS Logical Channel may be repeated over more than one TS 409 Multiplex (possibly associated with a different PID value) 410 [RFC4259], for example to redistribute the same multicast content to 411 two terrestrial TV transmission cells. 413 TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex 414 [ISO-MPEG2]. Each TS Packet carries a 4B header. 416 UDL: Unidirectional link: A one-way transmission link. For example, 417 and IP over DVB link using a broadcast satellite link. 419 ULE: Unidirectional Lightweight Encapsulation (ULE). A 420 scheme that encapsulates PDUs, into SNDUs that are sent in a series 421 of TS Packets using a single TS Logical Channel [RFC4326]. 423 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE 424 encapsulated PDUs. ULE Streams may be identified by definition of a 425 stream_type in SI/PSI [RFC4326, ISO-MPEG2]. 427 3. Address Resolution Requirements 429 The MPEG IP address resolution process is independent of the choice 430 of encapsulation and needs to support a set of IP over MPEG-2 431 encapsulation formats, including Multi-Protocol Encapsulation (MPE) 432 ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional 433 Lightweight Encapsulation (ULE) [RFC4326]. 435 The general IP over MPEG-2 AR requirements are summarized below: 437 A scalable architecture that may support large numbers of 438 systems within the MPEG-2 network [RFC4259]. 440 A protocol version, to indicate the specific AR protocol in use 441 and which may include the supported encapsulation method. 443 A method (e.g. well-known L2/L3 address/addresses) to identify 444 the AR Server sourcing the AR information. 446 A method to represent IPv4/IPv6 AR information (including 447 security mechanisms to authenticate the AR information to 448 protect against address masquerading [RFC3756]). 450 A method to install AR information associated with clients at 451 the AR Server (registration). 453 A method for transmission of AR information from an AR Server 454 to clients that minimise the transmission cost (link local 455 multicast, is preferable to subnet broadcast). 457 Incremental update of the AR information held by clients. 459 Procedures for purging clients of stale AR information. 461 An MPEG-2 transmission network may support multiple IP networks. If 462 this is the case, it is important to recognise the scope within 463 which an address is resolved, to prevent packets from one addressed 464 scope leaking into other scopes [RFC4259]. Examples of overlapping 465 IP address assignments include: 467 (i) Private unicast addresses (e.g. in IPv4, 10/8 prefix; 468 172.16/12 prefix; 192.168/16 prefix). Packets with these 469 addresses should be confined to one addressed area. IPv6 470 also defines link-local addresses that must not be 471 forwarded beyond the link on which they were first sent. 473 (ii) Local scope multicast addresses. These are only valid 474 within the local area (examples for IPv4 include: 475 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 476 multicast addresses [RFC2375]. 478 (iii) Scoped multicast addresses [RFC2365] [RFC2375]. 480 Forwarding of these addresses is controlled by the scope 481 associated with the address. The addresses are only valid 482 within an addressed area (e.g. the 239/8 [RFC2365]). 484 Overlapping address assignments may also occur at L2, where the same 485 MAC/NPA address is used to identify multiple Receivers [RFC4259]: 487 (i) An MAC/NPA unicast address must be unique within the 488 addressed area. The IEEE-assigned MAC addresses used in 489 Ethernet LANs are globally unique. If the addresses are 490 not globally unique, an address must only be re-used by 491 Receivers in different addressed (scoped) areas. 493 (ii) The MAC/NPA address broadcast address (an all ones L2 494 address). Traffic with this address should be confined to 495 one addressed area. 497 (iii) IP and other protocols may view sets of L3 multicast 498 addresses as link-local. This may produce unexpected results 499 if frames with the corresponding multicast L2 addresses are 500 distributed to systems in a different L3 network or 501 multicast scope (sections 3.2 and 5.6). 503 Reception of unicast packets destined for another addressed area 504 will lead to an increase in the rate of received packets by systems 505 connected via the network. Reception of the additional network 506 traffic may contribute to processing load, but should not lead to 507 unexpected protocol behaviour, providing that systems can be 508 uniquely addressed at L2. It does however introduce a potential 509 Denial of Service (DoS) opportunity. When the Receiver operates as 510 an IP router, the receipt of such a packet can lead to unexpected 511 protocol behaviour. 513 3.1 Unicast Support 515 Unicast address resolution is required at two levels. 517 At the lower level, the IP (or MAC) address needs to be associated 518 with a specific TS Logical Channel (PID value) and the corresponding 519 TS Multiplex (section 4). Each Encapsulator within an MPEG-2 Network 520 is associated with a set of unique TS Logical Channels (PID values) 521 that it sources [ETSI-DAT, RFC4259]. Within a specific scope, the 522 same unicast IP address may therefore be associated with more than 523 one Stream, and each Stream contributes different content (e.g. when 524 several different IP Encapsulators contribute IP flows destined to 525 the same Receiver). MPEG-2 Networks may also replicate IP packets 526 to send the same content (simulcast) to different Receivers or via 527 different TS Multiplexes. The configuration of the MPEG-2 Network 528 must prevent a Receiver accepting duplicated copies of the same IP 529 packet. 531 At the upper level, the AR procedure needs to associate an IP 532 address with a specific MAC/NPA address (section 5). 534 3.2 Multicast Support 536 Multicast is an important application for MPEG-2 Transmission 537 Networks, since it exploits the advantages of native support for 538 link broadcast. Multicast address resolution occurs at the network- 539 level in associating a specific L2 address with an IP Group 540 Destination Address (section 5.6). In IPv4 and IPv6 over Ethernet, 541 this association is normally a direct mapping, and this is the 542 default method also specified in both ULE [RFC4326] and MPE [ETSI- 543 DAT]. 545 Address resolution must also occur at the MPEG-2 level (section 4). 546 The goal of this multicast address resolution is to allow a receiver 547 to associate an IPv4 or IPv6 multicast address with a specific TS 548 Logical Channel and the corresponding TS Multiplex [RFC4259]. This 549 association needs to permit a large number of active multicast 550 groups, and should minimise the processing load at the Receiver when 551 filtering and forwarding IP multicast packets (e.g. by distributing 552 the multicast traffic over a number of TS Logical Channels). Schemes 553 that allow hardware filtering can be beneficial, since these may 554 relieve the drivers and operating systems from discarding unwanted 555 multicast traffic. 557 There are two specific functions required for address resolution in 558 IP multicast over MPEG-2 Networks: 560 (i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical 561 Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator. 563 (ii) Provide signalling information to allow a Receiver to 564 locate an IP multicast flow within an MPEG-2 TS Multiplex. 566 Methods are required to identify the scope of an address when an 567 MPEG-2 Network supports several logical IP networks and carries 568 groups within different multicast scopes [RFC4259]. 570 Appropriate procedures need to specify the correct action when the 571 same multicast group is available on separate TS Logical Channels. 572 This could arise when different Encapsulators contribute IP packets 573 with the same IP Group Destination Address in the ASM address range. 574 Another case arises when a Receiver could receive more than one copy 575 of the same packet (e.g. when packets are replicated across 576 different TS Logical Channels, or even different TS Multiplexes, a 577 method known as Simulcasting [ETSI-DAT]). At the IP level, the 578 host/router may be unaware of this duplication and this needs to be 579 detected by other means. 581 When the MPEG-2 Network is peered to the multicast-enabled Internet, 582 an arbitrarily large number of IP multicast group destination 583 addresses may be in use, and the set forwarded on the transmission 584 network may be expected to vary significantly with time. Some uses 585 of IP multicast employ a range of addresses to support a single 586 application (e.g., ND [RFC2461], LCT [RFC3451], WEBRC [RFC3738]). 587 The current set of active addresses may be determined dynamically 588 via a multicast group membership protocol (e.g., IGMP [RFC3376], MLD 589 [RFC3810]), via multicast routing (e.g., PIM [RFC4601]) and/or other 590 means (e.g. [RFC3819], [RFC4605]), however each active address 591 requires a binding by the AR method. There are therefore advantages 592 in using a method that does not need to explicitly advertise an AR 593 binding for each IP traffic flow, but is able to distribute traffic 594 across a number of L2 TS Logical Channels (e.g., using a 595 hash/mapping that resembles the mapping from IP addresses to MAC 596 addresses [RFC1112, RFC2464]). Such methods can reduce the volume of 597 AR information that needs to be distributed, and reduce the AR 598 processing. 600 Section 5.6 describes the binding of IP multicast addresses to 601 MAC/NPA addresses. 603 4. MPEG-2 Address Resolution 605 The first part of this section describes the role of MPEG-2 606 signalling to identify streams (TS Logical Channels [RFC4259]) 607 within the L2 infrastructure. 609 At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the 610 existence and format of a Stream, using a combination of two PSI 611 tables: the Programme Association Table (PAT) and entries in the 612 program element loop of a Programme Map Table (PMT). PMT Tables are 613 sent infrequently, and are typically small in size. The PAT is sent 614 using the well-known PID value of 0X000. This table provides the 615 correspondence between a program_number and a PID value. (The 616 program_number is the numeric label associated with a program.) Each 617 program in the Table is associated with a specific PID value, used 618 to identify a TS Logical Channel (i.e. a TS). The identified TS is 619 used to send the PMT, which associates a set of PID values with the 620 individual components of the programme. This approach de-references 621 the PID values when the MPEG-2 Network includes multiplexors or re- 622 multiplexors that renumber the PID values of the TS Logical Channels 623 that they process. 625 In addition to signalling the Receiver with the PID value assigned 626 to a Stream, PMT entries indicate the presence of Streams using ULE 627 and MPE to the variety of devices that may operate in the MPEG-2 628 transmission network (multiplexors, remultiplexors, rate shapers, 629 advertisement insertion equipment, etc). 631 A multiplexor or remultiplexor may change the PID values associated 632 with a Stream during the multiplexing process, the new value being 633 reflected in an updated PMT. TS Packets that carry a PID value that 634 is not associated with a PMT entry (an orphan PID), may, and usually 635 will, be dropped by ISO 13818-1 compliant L2 equipment, resulting in 636 the Stream not being forwarded across the transmission network. In 637 networks that do not employ any intermediate devices (e.g. scenarios 638 C,E,F of [RFC4259]), or where devices have other means to determine 639 the set of PID values in use, the PMT table may still be sent (but 640 is not required for this purpose). 642 Although the basic PMT information may be used to identify the 643 existence of IP traffic, it does not associate a Stream with an IP 644 prefix/address. The remainder of the section describes IP addresses 645 resolution mechanisms relating to MPEG-2. 647 4.1 Static configuration. 649 The static mapping option, where IP addresses or flows are 650 statically mapped to specific PIDs is the equivalent to signalling 651 "out-of-band". The application programmer, installing engineer, or 652 user receives the mapping via some outside means, not in the MPEG-2 653 TS. This is useful for testing, experimental networks, small 654 subnetworks and closed domains. 656 A pre-defined set of IP addresses may be used within a MPEG-2 657 transmission network. Prior knowledge of the active set of addresses 658 allows appropriate AR records to be constructed for each address, 659 and to pre-assign the corresponding PID value (e.g., selected to 660 optimise Receiver processing; to group related addresses to the same 661 PID value; and/or to reflect a policy for usage of specific ranges 662 of PID values). This presumes that the PID mappings are not modified 663 during transmission (section 4). 665 A single "well-known" PID is a specialisation of this. This scheme 666 is used by current DOCSIS cable modems [DOCSIS], where all IP 667 traffic is placed into the specified TS stream. MAC filtering 668 (and/or Section filtering in MPE) may be used to differentiate 669 subnetworks. 671 4.1.1 MPEG-2 Cable Networks 673 Cable networks use a different transmission scheme for downstream, 674 (head-end to cable modem) and upstream (cable modem to head-end) 675 transmission. 677 IP/Ethernet packets are sent (on the downstream) to the cable 678 modem(s) encapsulated in MPEG-2 TS Packets sent on a single well- 679 known TS Logical Channel (PID). There is no use of in-band 680 signalling tables. On the upstream, the common approach is to use 681 Ethernet framing, rather than IP/Ethernet over MPEG-2, although 682 other proprietary schemes also continue to be used. 684 Until the deployment of DOCSIS and EuroDOCSIS, most address 685 resolution schemes for IP traffic in cable networks were 686 proprietary, and did not usually employ a table-based address 687 resolution method. Proprietary methods continue to be used in some 688 cases where cable modems require interaction. In this case, 689 equipment at the head-end may act as gateways between the cable 690 modem and the Internet. These gateways receive L2 information and 691 allocate an IP address. 693 DOCSIS uses DHCP for IP client configuration. The Cable Modem 694 Terminal System (CMTS) provides a DHCP server that allocates IP 695 addresses to DOCSIS cable modems. The MPEG-2 Transmission Network 696 provides a L2 bridged network to the cable modem (section 1). This 697 usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], 698 [RFC3256]. Issues in deployment of IPv6 are described in [RFC4779]. 700 4.2 MPEG-2 Table-Based Address Resolution 702 The information about the set of MPEG-2 Transport Streams carried 703 over a TS Multiplex can be distributed via SI/PSI Tables. These 704 tables are usually sent periodically (section 4). This design 705 requires access to and processing of the SI Table information by 706 each Receiver [ETSI-SI], [ETSI-SI1]. This scheme reflects the 707 complexity of delivering and co-ordinating the various Transport 708 Streams associated with multimedia TV. A TS Multiplex may provide AR 709 information for IP services by integrating additional information 710 into the existing control tables or by transmitting additional SI 711 Tables that are specific to the IP service. 713 Examples of MPEG-2 Table usage to allow an MPEG-2 Receiver to 714 identify the appropriate PID and multiplex associated with a 715 specific IP address include: 717 (i) IP/MAC Notification Table (INT) in the DVB Data standard 718 [ETSI-DAT]. This provides uni-directional address resolution of 719 IPv4/IPv6 multicast addresses to an MPEG-2 TS. 721 (ii) Application Information Table (AIT) in the Multimedia Home 722 Platform (MHP) specifications [ETSI-MHP]. 724 (iii) Multicast Mapping Table (MMT) an MPEG-2 Table employed by some 725 DVB-RCS systems to provide uni-directional address resolution 726 of IPv4 multicast addresses to an MPEG-2 TS. 728 The MMT and AIT are used for specific applications, whereas the INT 729 [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and 730 IPv6 AR when used in combination with the other MPEG-2 tables 731 (section 4). 733 4.2.1 IP/MAC Notification Table (INT) and its usage 735 The INT provides a set of descriptors to specify addressing in a DVB 736 network. Use of this method is specified for Multi-Protocol 737 Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying 738 information about the location of IP/L2 flows within a DVB network. 739 A Platform_ID, identifies the addressing scope for a set of IP/L2 740 streams and/or Receivers. A Platform may span several Transport 741 Streams carried by one or multiple TS Multiplexes and represents a 742 single IP network with a harmonized address space (scope). This 743 allows for the coexistence of several independent IP/MAC address 744 scopes within an MPEG-2 Network. 746 The INT allows both fully-specified IP addresses and prefix 747 matching, to reduce the size of the table (and hence enhance 748 signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified 749 in full form or using a slash notation (e.g. /127). IP multicast 750 addresses can be specified with or without a source (address or 751 range), although if a source address is specified, then only the 752 slash notation may be used for prefixes. 754 In addition to identification and security descriptors, the 755 following descriptors are defined for address binding in INT tables: 757 (i) target_MAC_address_descriptor: A descriptor to describe a 758 single or set of MAC addresses (and their mask). 760 (ii) target_MAC_address_range_descriptor: A descriptor that may be 761 used to set filters. 763 (iii) target_IP_address_descriptor: A descriptor describing a 764 single or set of IPv4 unicast or multicast addresses (and 765 their mask). 767 (iv) target_IP_slash_descriptor: Allows definition and 768 announcement of an IPv4 prefix. 770 (v) target_IP_source_slash_descriptor: Uses source and 771 destination addresses to target a single or set of systems. 773 (vi) IP/MAC stream_location_descriptor: A descriptor that locates 774 an IP/MAC stream in a DVB network. 776 The following descriptors provide corresponding functions for IPv6 777 addresses: 779 target_IPv6_address_descriptor 780 target_IPv6_slash_descriptor 781 and target_IPv6_source_slash_descriptor 783 The ISP_access_mode_descriptor allows specification of a second 784 address descriptor to access an ISP via an alternative non-DVB 785 (possibly non-IP) network. 787 One key benefit is that the approach employs MPEG-2 signalling 788 (section 4) and is integrated with other signalling information. 789 This allows the INT to operate in the presence of (re)multiplexors 790 [RFC4259] and to refer to PID values that are carried in different 791 TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario 792 [RFC4259]. 794 The principal drawback is a need for an Encapsulator to introduce 795 associated PSI/SI MPEG-2 control information. This control 796 information needs to be processed at a Receiver. This requires 797 access to information below the IP layer. The position of this 798 processing within the protocol stack makes it hard to associate the 799 results with IP Policy, management and security functions. The use 800 of centralized management prevents the implementation of a more 801 dynamic scheme. 803 4.2.2 Multicast Mapping Table (MMT) and its usage 805 In DVB-RCS, unicast AR is seen as a part of a wider configuration 806 and control function and does not employ a specific protocol. 808 A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control 809 table that associates a set of multicast addresses with the 810 corresponding PID values [MMT]. This table allows a DVB-RCS Forward 811 Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 812 multicast addresses to PID values within a specific TS Multiplex. 813 Receivers (DVB-RCS Return Channel Satellite Terminals, RCSTs) may 814 use this table to determine the PID values associated with an IP 815 multicast flow that it requires to receive. The MMT is specified by 816 the SatLabs Forum [MMT], and is not currently a part of the DVB-RCS 817 specification. 819 4.2.3 Application Information Table (AIT) and its usage 821 The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does 822 not define a specific AR function. However, an Application 823 Information Table (AIT) is defined that allows MHP Receivers to 824 receive a variety of control information. The AIT uses an MPEG-2 825 signalling table providing information about data broadcasts, the 826 required activation state of applications carried by a broadcast 827 stream, etc. This information allows a broadcaster to request that a 828 Receiver change the activation state of an application, and to 829 direct applications to receive specific multicast packet flows 830 (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a 831 specific function, but as a part of a wider configuration and 832 control function. 834 4.2.4 Address Resolution in ATSC 836 ATSC [ATSC-A54A] defines a system that allows transmission of IP 837 packets within an MPEG-2 Network. An MPEG-2 Program (defined by the 838 PMT) may contain one or more applications [ATSC-A90] that include IP 839 multicast streams [ATSC-A92]. IP multicast data are signalled in the 840 PMT using a stream_type indicator of value 0x0D. A MAC address list 841 descriptor [SCTE-1] may also be included in the PMT. 843 The approach focuses on applications that serve the transmission 844 network. A method is defined that uses MPEG-2 SI Tables to bind the 845 IP multicast media streams and the corresponding Session Description 846 Protocol (SDP) announcement streams to particular MPEG-2 Program 847 Elements. Each application constitutes an independent network. The 848 MPEG-2 Network boundaries establish the IP addressing scope. 850 4.2.5 Comparison of SI/PSI table approaches 852 The MPEG-2 methods based on SI/PSI meet the specified requirements 853 of the groups that created them and each has their strength: the 854 INT in terms of flexibility and extensibility, the MMT in its 855 simplicity, the AIT in its extensibility. However, they exhibit 856 scalability constraints, represent technology specific solutions and 857 do not fully adopt IP-centric approaches that would enable easier 858 use of the MPEG-2 bearer as a link technology within the wider 859 Internet. 861 4.3 IP-based address resolution for TS Logical Channels 863 As MPEG-2 Networks evolve to become multi-service networks, the use 864 of IP protocols is becoming more prevalent. Most MPEG-2 Networks now 865 use some IP protocols for operations, control and data delivery, 866 address resolution information could also be sent using IP 867 transport. At the time of writing there is no standards-based IP- 868 level AR protocol that supports the MPEG-2 TS. 870 There is an opportunity to define an IP-level method that could use 871 an IP multicast protocol over a well-known IP multicast address to 872 resolve an IP address to a TS Logical Channel (i.e., a Transport 873 Stream). The advantages of using an IP-based address resolution 874 include: 876 (i) Simplicity: 877 The AR mechanism does not require interpretation of L2 tables; this 878 is an advantage especially in the growing market share for home 879 network and audio video networked entities. 881 (ii) Uniformity: 882 An IP-based protocol can provide a common method across different 883 network scenarios for both IP to MAC address mappings and to map to 884 TS Logical Channels (PID value associated with a Stream). 886 (iii) Extensibility: 887 IP-based AR mechanisms allow an independent evolution of the AR 888 protocol. This includes dynamic methods to request address 889 resolution and the ability to include other L2 information (e.g. 890 Encryption keys). 892 (iv) Integration 893 The information exchanged by IP-based AR protocols can easily be 894 integrated as a part of the IP network layer, simplifying support 895 for AAA, policy, OAM, mobility, configuration control, etc. that 896 combine AR with security. 898 The drawbacks of an IP-based method include: 900 (i) It can not operate over an MPEG-2 Network that uses MPEG-2 901 remultiplexors [RFC4259] that modify the PID values associated with 902 the TS Logical Channels during the multiplexing operation (section 903 4). This makes the method unsuitable for use in deployed broadcast 904 TV networks [RFC4259]. 906 (ii) IP-based methods can introduce concerns about the integrity of 907 the information and authentication of the sender [RFC4259]. (These 908 concerns are also applicable to MPEG-2 Table methods, but in this 909 case the information is confined to the L2 network, or parts of the 910 network where gateway devices isolate the MPEG-2 devices from the 911 larger Internet creating virtual MPEG-2 private networks.) IP-based 912 solutions should therefore implement security mechanisms that may be 913 used to authenticate the sender and verify the integrity of the AR 914 information, as a part of a larger security framework. 916 An IP-level method could use an IP multicast protocol running an AR 917 Server (see also section 5.4) over a well-known (or discovered) IP 918 multicast address. To satisfy the requirement for scalability to 919 networks with large number of systems (section 1), a single packet 920 needs to transport multiple AR records, and define the intended 921 scope for each address. Methods that employ prefix matching (e.g. 922 where a range of source/destination addresses are matched to a 923 single entry are desirable), as also are methods that allow a range 924 of IP addresses to mapped to a set of TS Logical Channels (a hashing 925 technique similar to the mapping of IP Group Destination Addresses 926 to Ethernet MAC addresses may be beneficial). 928 5. Mapping IP addresses to MAC/NPA addresses 930 This section reviews IETF protocols that may be used to assign and 931 manage the mapping of IP addresses to/from MAC/NPA addresses over 932 MPEG-2 Networks. 934 An IP Encapsulator requires AR information to select an appropriate 935 MAC/NPA address in the SNDU header [RFC4259] (section 6). The 936 information to complete this header may be taken directly from a 937 neighbour/arp cache, or may require the Encapsulator to retrieve the 938 information using an AR protocol. The way in which this information 939 is collected will depend upon whether the Encapsulator functions as 940 a Router (at L3) or a Bridge (at L2) (section 1.1). 942 Two IETF-defined protocols for mapping IP addresses to MAC/NPA 943 addresses are the Address Resolution Protocol, ARP [RFC826], and the 944 Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and 945 IPv6. Both protocols are normally used in a bi-directional mode, 946 although both also permit unsolicited transmission of mappings. The 947 IPv6 mapping defined in [RFC2464] can result in a large number of 948 active MAC multicast addresses (e.g. one for each end host). 950 ARP requires support for L2 broadcast packets. A large number of 951 Receivers can lead to a proportional increase in ARP traffic, a 952 concern for bandwidth-limited networks. Transmission delay can also 953 impact protocol performance. 955 ARP also has a number of security vulnerabilities. ARP spoofing is 956 where a system can be fooled by a rogue device that sends a 957 fictitious ARP response that includes the IP address of a legitimate 958 network system, and the MAC of a rogue system. This causes 959 legitimate systems on the network to update their ARP tables with 960 the false mapping and then send future packets to the rogue system 961 instead of the legitimate system. Using this method, a rogue system 962 can see (and modify) packets sent through the network. 964 Secure ARP (SARP) uses a secure tunnel (e.g. between each client and 965 a server at a wireless access point or router) [RFC4346]. The router 966 ignores any ARP responses not associated with clients using the 967 secure tunnels. Therefore, only legitimate ARP Responses are used 968 for updating ARP tables. SARP requires the installation of software 969 at each client. It suffers from the same scalability issues as the 970 standard ARP. 972 The ND protocol uses a set of IP multicast addresses. In large 973 networks, many multicast addresses are used, but each client 974 typically only listens to a restricted set of group destination 975 addresses and little traffic is usually sent in each group. Layer-2 976 AR for MPEG-2 Networks therefore must support this in a scalable 977 manner. 979 A large number of ND messages may cause a large demand for 980 performing asymmetric operations. The base ND protocol limits the 981 rate at which multicast responses to solicitations can be sent, 982 configurations may need to be tuned when operating with large 983 numbers of Receivers. 985 The default parameters specified in the ND protocol [RFC2461] can 986 introduce interoperability problems (e.g. a failure to resolve when 987 the link RTT exceed 3 seconds) and performance degradation 988 (duplicate ND messages with a link RTT > 1 second) when used in 989 networks where the link RTT is significantly larger than experienced 990 by Ethernet LANs. Tuning of the protocol parameters (e.g. 991 RTR_SOLICITATION_INTERVAL) is therefore recommended when using 992 network links with appreciable delay (section 6.3.2 of [RFC2461]). 994 ND has similar security vulnerabilities to ARP. The Secure Neighbor 995 Discovery, SEND [RFC3971] was developed to address known security 996 vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic 997 compared to ND. In addition, SEND does not require the configuration 998 of per-host keys and can co-exist with the use of both SEND and 999 insecure ND on the same link. 1001 The ND Protocol is also used by IPv6 systems to perform other 1002 functions beyond address resolution, including Router Solicitation / 1003 Advertisement, Duplicate Address Detection (DAD), Neighbor 1004 Unreachability Detection (NUD), Redirect. These functions are useful 1005 for hosts, even when address resolution is not required. 1007 5.1 Uni-directional links supporting uni-directional connectivity 1009 MPEG-2 Networks may provide a Uni-Directional broadcast Link (UDL), 1010 with no return path. Such links may be used for unicast applications 1011 that do not require a return path (e.g. based on UDP), but commonly 1012 are used for IP multicast content distribution. 1014 /-----\ 1015 MPEG-2 Uplink /MPEG-2 \ 1016 ###################( Network ) 1017 # \ / 1018 +----#------+ \--.--/ 1019 | Network | | 1020 | Provider + v MPEG-2 downlink 1021 +-----------+ | 1022 +-----v------+ 1023 | MPEG-2 | 1024 | Receiver | 1025 +------------+ 1027 Figure 3: Uni-directional connectivity 1028 The ARP and ND protocols require bi-directional L2/L3 connectivity. 1029 They do not provide an appropriate method to resolve the remote 1030 (destination) address in a uni-directional environment. 1032 Unidirectional links therefore require a separate out-of-band 1033 configuration method to establish the appropriate AR information at 1034 the Encapsulator and Receivers. ULE [RFC4326] defines a mode in 1035 which the MAC/NPA address is omitted from the SNDU. In some 1036 scenarios, this may relieve an Encapsulator of the need for L2 AR. 1038 5.2 Uni-directional links with bi-directional connectivity 1040 Bi-directional connectivity may be realised using a uni-directional 1041 link in combination with another network path. Common combinations 1042 are a Feed link using MPEG-2 satellite transmission and a return 1043 link using terrestrial network infrastructure. This topology is 1044 often known as a Hybrid network, and has asymmetric network routing. 1046 /-----\ 1047 MPEG-2 uplink /MPEG-2 \ 1048 ###################( Network ) 1049 # \ / 1050 +----#------+ \--.--/ 1051 | Network | | 1052 | Provider +-<-+ v MPEG-2 downlink 1053 +-----------+ | | 1054 | +-----v------+ 1055 +--<<--+ MPEG-2 | 1056 Return | Receiver | 1057 Path +------------+ 1059 Figure 4: Bi-directional connectivity 1061 The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be 1062 used to overcome issues associated with asymmetric routing. The 1063 Dynamic Tunnel Configuration Protocol (DTCP) enables automatic 1064 configuration of the return path. UDLR hides the uni-directional 1065 routing from the IP and upper layer protocols, by providing a L2 1066 tunnelling mechanism that emulates a bi-directional broadcast link 1067 at L2. A network using UDLR has a topology where a Feed Router and 1068 all Receivers form a logical Local Area Network. Encapsulating L2 1069 frames allows them to be sent through an Internet Path (i.e. 1070 bridging). 1072 Since many uni-directional links employ wireless technology for the 1073 forward (Feed) link, there may be an appreciable cost associated 1074 with forwarding traffic on the Feed link. Therefore, it is often 1075 desirable to prevent forwarding unnecessary traffic, (e.g. for 1076 multicast this implies control of which groups are forwarded). The 1077 implications of forwarding in the return direction must also be 1078 considered (e.g., asymmetric capacity and loss [RFC3449]). This 1079 suggests a need to minimise the volume and frequency of control 1080 messages. 1082 Three different AR cases may be identified (each considers sending 1083 an IP packet to a next-hop IP address that is not currently cached 1084 by the sender): 1086 (i) A Feed Router needs a Receiver MAC/NPA address. 1088 This occurs when a Feed Router sends an IP packet using the Feed UDL 1089 to a Receiver whose MAC/NPA address is unknown. In IPv4, the Feed 1090 Router sends an ARP REQUEST with the IP address of the Receiver. The 1091 Receiver that recognises its IP address replies with an ARP RESPONSE 1092 to the MAC/NPA address of the Feed Router (e.g. using a UDLR 1093 tunnel). The Feed Router may then address IP packets to the unicast 1094 MAC/NPA address associated with the Receiver. The ULE packet format 1095 also permits packets to be sent without specifying a MAC/NPA 1096 address, where this is desirable (section 6.1, 6.5). 1098 (ii) A Receiver needs the Feed Router MAC/NPA address. 1100 This occurs when a Receiver sends an IP packet to a Feed Router 1101 whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP 1102 REQUEST with the IP address of the Feed Router (e.g. using a UDLR 1103 tunnel). The Feed Router replies with an ARP RESPONSE using the Feed 1104 UDL. The Receiver may then address IP packets to the MAC/NPA address 1105 of the recipient. 1107 (iii) A Receiver needs another Receiver MAC/NPA address. 1109 This occurs when a Receiver sends an IP packet to another Receiver 1110 whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP 1111 REQUEST with the IP address of the remote Receiver (e.g. using a 1112 UDLR tunnel to the Feed Router). The request is forwarded over the 1113 Feed UDL. The target Receiver replies with an ARP RESPONSE (e.g. 1114 using a UDLR tunnel). The Feed Router forwards the response on the 1115 UDL. The Receiver may then address IP packets to the MAC/NPA address 1116 of the recipient. 1118 These 3 cases allow any system connected to the UDL to obtain the 1119 MAC/NPA address of any other system. Similar exchanges may be 1120 performed using the ND protocol for IPv6. 1122 A long round trip delay (via the UDL and UDLR tunnel) impacts the 1123 performance of the reactive address resolution procedures provided 1124 by ARP, ND and SEND. In contrast to Ethernet, during the interval 1125 when resolution is taking place, many IP packets may be received 1126 that are addressed to the AR Target address. The arp specification 1127 allows an interface to discard these packets while awaiting the 1128 response to the resolution request. An appropriately sized buffer 1129 would however prevent this loss. 1131 In case (iii), the time to complete address resolution may be 1132 reduced by use of an AR Server at the Feed (section 5.4). 1134 Using DHCP requires prior establishment of the L2 connectivity to a 1135 DHCP server. The delay in establishing return connectivity in UDLR 1136 networks that use DHCP, may make it beneficial to increase the 1137 frequency of the DTCP HELLO message. Further information about 1138 tuning DHCP is provided in section 5.5. 1140 5.3 Bi-directional Links 1142 Bi-directional IP networks can be and are constructed by a 1143 combination of two MPEG-2 transmission links. One link is usually a 1144 broadcast link that feeds a set of remote Receivers. Links are also 1145 provided from Receivers so that the combined link functions as a 1146 full duplex interface. Examples of this use include two-way DVB-S 1147 satellite links and the DVB-RCS system. 1149 5.4 AR Server 1151 An AR Server can be used to distribute AR information to Receivers 1152 in an MPEG-2 Network. In some topologies this may significantly 1153 reduce the time taken for Receivers to discover AR information. 1155 The AR Server can operate as a proxy responding on behalf of 1156 Receivers to received AR requests. When an IPv4 AR request is 1157 received (e.g. Receiver ARP REQUEST), an AR Server responds by 1158 (proxy) sending an AR response providing the appropriate IP to 1159 MAC/NPA binding (mapping the IP address to the L2 address). 1161 Information may also be sent unsolicited by the AR Server using 1162 multicast/broadcast to update the arp/neighbor cache at the 1163 Receivers without the need for explicit requests. The unsolicited 1164 method can improve scaling in large networks. Scaling could be 1165 further improved by distributing a single broadcast/multicast AR 1166 message that binds multiple IP and MAC/NPA addresses. This reduces 1167 the network capacity consumed and simplifies client 1168 processing/server in networks with large numbers of clients. 1170 An AR Server can be implemented using IETF-defined Protocols by 1171 configuring the subnetwork so that AR Requests from Receivers are 1172 intercepted rather than forwarded to the Feed/broadcast link. The 1173 intercepted messages are sent to an AR Server. The AR Server 1174 maintains a set of MAC/NPA address bindings. These may be configured 1175 or may learned by monitoring ARP messages sent by Receivers. 1176 Currently defined IETF protocols only allow one binding per message, 1177 (i.e. there is no optimisation to conserve L2 bandwidth). 1179 Equivalent methods could provide IPv6 AR. Procedures for 1180 intercepting ND messages are defined in [RFC4389]. To perform an AR 1181 Server function, the AR information must also be cached. A caching 1182 AR proxy stores system state within a middle-box device. This 1183 resembles a classic man-in-the-middle security attack; interactions 1184 with SEND are described in [ID-SP-ND]. 1186 Methods are needed to purge stale AR data from the cache. The 1187 consistency of the cache must also be considered when the receiver 1188 bindings can change (e.g. IP mobility, network topology changes, or 1189 intermittent Receiver connectivity). In these cases, the use of old 1190 (stale) information can result in IP packets being directed to an 1191 inappropriate L2 address, with consequent packet loss. 1193 Current IETF-defined methods provide bindings of IP addresses to 1194 MAC/NPA, but do not allow the bindings to other L2 information 1195 pertinent to MPEG-2 Networks, requiring the use of other methods for 1196 this function (section 4). AR Servers can also be implemented using 1197 non-IETF AR protocols to provide the AR information required by 1198 Receivers. 1200 5.5 DHCP Tuning 1202 DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 1203 Networks. DHCP consists of two components: a protocol for delivering 1204 system-specific configuration parameters from a DHCP server to a 1205 DHCP client (e.g. default router, DNS server) and a mechanism for 1206 allocation of network addresses to systems. 1208 The configuration of DHCP Servers and Clients should take into 1209 account the local link round trip delay (possibly including the 1210 additional delay from bridging, e.g. using UDLR). A large number of 1211 clients can make it desirable to tune the DHCP lease duration and 1212 the size of the address pool. Appropriate timer values should also 1213 be selected: the DHCP messages retransmission timeout, and the 1214 maximum delay that a DHCP Server waits before deciding that the 1215 absence of an ICMP echo response indicates that the relevant address 1216 is free. 1218 DHCP Clients may retransmit DHCP messages if they do not receive a 1219 response. Some client implementations specify a timeout for the 1220 DHCPDISCOVER message that is small (e.g. suited to Ethernet delay, 1221 rather than appropriate to a MPEG-2 Network) providing insufficient 1222 time for a DHCP Server to respond to a DHCPDISCOVER retransmission 1223 before expiry of the check on the lease availability (by an ICMP 1224 Echo Request), resulting in potential address conflict. This value 1225 may need to be tuned for MPEG-2 networks. 1227 5.6 IP Multicast AR 1229 Section 3.2 describes multicast address resolution requirements. 1230 This section describes L3 address bindings when the destination 1231 network layer address is an IP multicast Group Destination Address. 1233 In MPE [ETSI-DAT], a mapping is specified for the MAC Address based 1234 on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464]. 1235 (A variant of DVB (DVB-H) uses a modified MAC header [ETSI-DAT]). 1237 In ULE [RFC4326], the L2 NPA address is optional, and is not 1238 necessarily required when the Receiver is able to perform efficient 1239 L3 multicast address filtering. When present, a mapping is defined 1240 based on the IP multicast address for IPv4 [RFC1112] and IPv6 1241 [RFC2464]. 1243 The L2 group addressing method specified in [RFC1112] and [RFC2464] 1244 can result in more than one IP destination addresses mapping to the 1245 same L2 address. In Source-Specific Multicast, SSM [RFC3569], 1246 multicast groups are identified by the combination of the IP source 1247 and IP destination addresses. Senders may therefore independently 1248 select an IP group destination address that could map to the same L2 1249 address if forwarded onto the same L2 link. The resulting addressing 1250 overlap at L2 can increase the volume of traffic forwarded to L3, 1251 where it then needs to be filtered. 1253 These considerations are the same as for Ethernet LANs, and may not 1254 be of concern to Receivers that can perform efficient L3 filtering. 1255 Section 3 noted that a MPEG-2 Network may need to support multiple 1256 addressing scopes at the network and link layers. Separation of the 1257 different groups into different Transport Streams is one remedy 1258 (with signalling of IP to PID value mappings). Another approach is 1259 to employ alternate MAC/NPA mappings to those defined in [RFC1112] 1260 and [RFC2464], but such mappings need to be consistently bound at 1261 the Encapsulator and Receiver using AR procedures in a scalable 1262 manner. 1264 5.6.1 Multicast/Broadcast addressing for UDLR 1266 UDLR is a layer 2 solution, in which a Receiver may send 1267 multicast/broadcast frames that are subsequently forwarded natively 1268 by a Feed Router (using the topology in figure 2), and are finally 1269 received at the feed interface of the originating Receiver. This 1270 multicast forwarding does not include the normal L3 Reverse Path 1271 Forwarding (RPF) check or L2 spanning tree checks, the processing of 1272 the IP Time To Live (TTL) field, or the filtering of 1273 administratively scoped multicast addresses. This raises a need to 1274 carefully consider multicast support. To avoid forwarding loops, 1275 RFC3077 notes that a Receiver needs to be configured with 1276 appropriate filter rules to ensure it discards packets that 1277 originate from an attached network and are later received over the 1278 feed link. 1280 When the encapsulation includes an MAC/NPA source address, re- 1281 broadcast packets may be filtered at the link-layer using a filter 1282 that discards L2 addresses that are local to the Receiver. In some 1283 circumstances, systems can send packets with an unknown (all zero) 1284 MAC source address (e.g. IGMP Proxy Queriers [RFC4605]), where the 1285 source at L2 can not be determined at the Receiver, these packets 1286 need to be silently discarded, which may prevent running the 1287 associated services on the Receiver. 1289 Some encapsulation formats also do not include an MAC/NPA source 1290 address (Table 2). Multicast packets may therefore alternatively be 1291 discarded at the IP layer if their IP source address matches a local 1292 IP address (or address range). Systems can send packets with an all 1293 zero IP source address (e.g. BOOTP [RFC951], DHCP [RFC2131] and ND 1294 [RFC2461]), where the source at L3 can not be determined at the 1295 Receiver these packets need to be silently discarded. This may 1296 prevent running the associated services at a Receiver, e.g. 1297 participation in IPv6 Duplicate Address Detection, or running a DHCP 1298 server. 1300 6. Link Layer Support 1302 This section considers link-layer (L2) support for address 1303 resolution in MPEG-2 Networks. It considers two issues: The code- 1304 point used at L2 and the efficiency of encapsulation for 1305 transmission required to support the AR method. The table below 1306 summarises the options for both MPE ([ETSI-DAT],[ATSC-A90]) and ULE 1307 [RFC4326] encapsulations. 1309 [ID-IAB-LINK] describes issues and concerns that may arise when a 1310 link can support multiple encapsulations. In particular, it 1311 identifies problems that arise when end hosts that belong to the 1312 same IP network employ different incompatible encapsulation methods. 1313 An Encapsulator must therefore use only one method e.g. ULE or MPE) 1314 to support a single IP network (i.e. set of IPv4 systems sharing the 1315 same subnet broadcast address, or same IPv6 Prefix). In this way, 1316 all Receivers belonging to a network will Receive the same set of 1317 multicast/broadcast messages. 1319 In ULE, the bridging format may be used in combination with the 1320 normal mode to address packets to a Receiver (all ULE Receivers are 1321 required to implement both methods). Frames carrying IP packets 1322 using the ULE Bridging mode that have a destination address 1323 corresponding to the MAC address of the Receiver and have an IP 1324 address corresponding to a Receiver interface will be delivered to 1325 the IP stack of the Receiver. All bridged IP multicast and broadcast 1326 frames will also be copied to the IP stack of the Receiver. 1327 Receivers must filter (discard) a frame that carries a MAC source 1328 address of a system that is reachable via a different network 1329 interface to that upon which it is received, including reception of 1330 a frame with an address that matches the source address of the 1331 Receiver itself [802.1D]. 1333 +-------------------------------+--------+----------------------+ 1334 | | PDU |L2 Frame Header Fields| 1335 | L2 Encapsulation |overhead+----------------------+ 1336 | |[bytes] |src mac|dst mac| type | 1337 +-------------------------------+--------+-------+-------+------+ 1338 |6.1 ULE without dst MAC address| 8 | - | - | x | 1339 |6.2 ULE with dst MAC address | 14 | - | x | x | 1340 |6.3 MPE without LLC/SNAP | 16 | - | x | - | 1341 |6.4 MPE with LLC/SNAP | 24 | - | x | x | 1342 |6.5 ULE with Bridging extension| 22 | x | x | x | 1343 |6.6 ULE with Bridging & NPA | 28 | x | x | x | 1344 |6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x | 1345 +-------------------------------+--------+-------+-------+------+ 1347 Table showing L2 support and overhead (x=supported, -=not supported) 1349 The remainder of the section describes IETF-specified AR methods for 1350 use with these encapsulation formats. Most of these methods rely on 1351 bi-directional communications (see section 5.1, 5.2, 5.3 for a 1352 discussion of this). 1354 6.1 ULE without a destination MAC/NPA address (D=1) 1356 The ULE encapsulation supports a mode (D=1) where the MAC/NPA 1357 address is not present in the encapsulated frame. This mode may be 1358 used with both IPv4 and IPv6. When used, the Receiver is expected 1359 to perform L3 filtering of packets based on their IP destination 1360 address [RFC4326]. This requires careful consideration of the 1361 network topology when a receiver is an IP router, or delivers data 1362 to an IP router (a simple case where this is permitted arises in the 1363 connection of stub networks at a Receiver that have no connectivity 1364 to other networks). Since there is no MAC/NPA address in the SNDU, 1365 ARP and the ND protocol are not required for AR. 1367 IPv6 systems can automatically configure their IPv6 network address 1368 based upon a local MAC address [RFC2462]. To use auto-configuration, 1369 the IP driver at the Receiver may need to access the MAC/NPA address 1370 of the receiving interface, even though this value is not being used 1371 to filter received SNDUs. 1373 Even when not used for AR, the ND protocol may still be required to 1374 support DAD, and other IPv6 network-layer functions. This protocol 1375 uses a block of IPv6 multicast addresses, which need to be carried 1376 by the L2 network. However, since this encapsulation format does not 1377 provide a MAC source address, there are topologies (e.g., section 1378 5.6.1) where a system can not differentiate DAD packets that were 1379 originally sent by itself and were re-broadcast, from those that may 1380 have been sent by another system with the same L3 address. DAD 1381 therefore can not be used with this encapsulation format in 1382 topologies where this L2 forwarding may occur. 1384 6.2 ULE with a destination MAC/NPA address (D=0) 1386 The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by 1387 an IEEE EtherType and may be used over ULE [RFC4326]. Although no 1388 MAC source address is present in the ULE SNDU, the ARP protocol 1389 still communicates the source MAC (hardware) address in the ARP 1390 record payload of any query messages that it generates. 1392 The IPv6 ND protocol is supported. The protocol uses a block of IPv6 1393 multicast addresses, which need to be carried by the L2 network. The 1394 protocol uses a block of IPv6 multicast addresses, which need to be 1395 carried by the L2 network. However, since this encapsulation format 1396 does not provide a MAC source address, there are topologies (e.g., 1397 section 5.6.1) where a system can not differentiate DAD packets that 1398 were originally sent by itself and were re-broadcast, from those 1399 that may have been sent by another system with the same L3 address. 1400 DAD therefore can not be used with this encapsulation format in 1401 topologies where this L2 forwarding may occur. 1403 6.3 MPE without LLC/SNAP Encapsulation 1405 This is the default (and sometimes only) mode specified by most MPE 1406 Encapsulators. MPE does not provide an EtherType field and therefore 1407 can not support the Address Resolution Protocol (ARP) [RFC826]. 1409 IPv6 is not supported in this encapsulation format, and therefore it 1410 is not appropriate to consider the ND protocol. 1412 6.4 MPE with LLC/SNAP Encapsulation 1414 The LLC/SNAP format of MPE provides an EtherType field and therefore 1415 may support the ARP [RFC826]. There is no specification to define 1416 how this is performed. No MAC source address is present in the SNDU, 1417 although the protocol still communicates the source MAC address in 1418 the ARP record payload of any query messages that it generates. 1420 The IPv6 ND protocol is supported using The LLC/SNAP format of MPE. 1421 This requires specific multicast addresses to be carried by the L2 1422 network. The IPv6 ND protocol is supported. The protocol uses a 1423 block of IPv6 multicast addresses, which need to be carried by the 1424 L2 network. However, since this encapsulation format does not 1425 provide a MAC source address, there are topologies (e.g., section 1426 5.6.1) where a system can not differentiate DAD packets that were 1427 originally sent by itself and were re-broadcast, from those that may 1428 have been sent by another system with the same L3 address, DAD 1429 therefore can not be used with this encapsulation format in 1430 topologies where this L2 forwarding may occur. 1432 6.5 ULE with Bridging Header Extension (D=1) 1434 The ULE encapsulation supports a bridging extension header that 1435 supplies both a source and destination MAC address. This can be 1436 used without an NPA address (D=1). When no other Extension Headers 1437 precede this Extension, the MAC destination address has the same 1438 position in the ULE SNDU as that used for an NPA destination 1439 address. The Receiver may optionally be configured so that the MAC 1440 destination address value is identical to a Receiver NPA address. 1442 At the Encapsulator, the ULE MAC/NPA destination address is 1443 determined by a L2 forwarding decision. Received frames may be 1444 forwarded or may be addressed to the Receiver itself. As in other L2 1445 LANs, the Receiver may choose to filter received frames based on a 1446 configured MAC destination address filter. ARP and ND messages may 1447 be carried within a PDU that is bridged by this encapsulation 1448 format. Where the topology may result in subsequent reception of re- 1449 broadcast copies of multicast frames that were originally sent by a 1450 Receiver (e,g. section 5.6.1), the system must discard frames that 1451 are received with a source address that it used in frames sent from 1452 the same interface [802.1D]. This prevents duplication on the 1453 bridged network (e.g. this would otherwise invoke DAD). 1455 6.6 ULE with Bridging Header Extension and NPA Address (D=0) 1457 The combination of a NPA address (D=0) and a bridging extension 1458 header are allowed in ULE. This SNDU format supplies both a source 1459 and destination MAC address and a NPA destination address (i.e. 1460 Receiver MAC/NPA address). 1462 At the Encapsulator, the value of the ULE MAC/NPA destination 1463 address is determined by a L2 forwarding decision. At the Receiver, 1464 frames may be forwarded or may be addressed to the Receiver itself. 1465 As in other L2 LANs, the Receiver may choose to filter received 1466 frames based on a configured MAC destination address filter. ARP and 1467 ND messages may be carried within a PDU that is bridged by this 1468 encapsulation format. Where the topology may result in subsequent 1469 reception of re-broadcast copies of multicast frames that were 1470 originally sent by a Receiver (e,g. section 5.6.1), the system must 1471 discard frames that are received with a source address that it used 1472 in frames sent from the same interface [802.1D]. This prevents 1473 duplication on the bridged network (e.g., this would otherwise 1474 invoke DAD). 1476 6.7 MPE+LLC/SNAP+Bridging 1478 The LLC/SNAP format MPE frames may optionally support an IEEE 1479 bridging header [LLC]. This header supplies both a source and 1480 destination MAC address, at the expense of larger encapsulation 1481 overhead. The format defines two MAC destination addresses, one 1482 associated with the MPE SNDU (i.e. Receiver MAC address) and one 1483 with the bridged MAC frame (i.e. the MAC address of the intended 1484 recipient in the remote LAN). 1486 At the Encapsulator, the MPE MAC destination address is determined 1487 by a L2 forwarding decision. There is currently no formal 1488 description of the Receiver processing for this encapsulation 1489 format. A Receiver may forward frames or they may be addressed to 1490 the Receiver itself. As in other L2 LANs, the Receiver may choose to 1491 filter received frames based on a configured MAC destination address 1492 filter. ARP and ND messages may be carried within a PDU that is 1493 bridged by this encapsulation format. The MPE MAC destination 1494 address is determined by a L2 forwarding decision. Where the 1495 topology may result in subsequent reception of re-broadcast copies 1496 of multicast frames that were originally sent by a Receiver (e,g. 1497 section 5.6.1), the system must discard frames that are received 1498 with a source address that it used in frames sent from the same 1499 interface [802.1D]. This prevents duplication on the bridged network 1500 (e.g. this would otherwise invoke DAD). 1502 7. Conclusions 1504 This document describes addressing and address resolution issues for 1505 IP protocols over MPEG-2 transmission networks using both wired and 1506 wireless technologies. A number of specific IETF protocols are 1507 discussed along with their expected behaviour over MPEG-2 1508 transmission networks. Recommendations for their usage are provided. 1510 There is no single common approach used in all MPEG-2 networks. A 1511 static binding may be configured for IP addresses and PIDs (as in 1512 some cable networks). In broadcast networks, this information is 1513 normally provided by the Encapsulator/Multiplexor and carried in 1514 signalling tables (e.g. AIT in MHP, the IP Notification Table, INT, 1515 of DVB and the DVB-RCS Multicast Mapping Table, MMT). This document 1516 has reviewed the status of these current address resolution 1517 mechanisms in MPEG-2 transmission networks and defined their usage. 1519 The document also considers a unified IP-based method for AR that 1520 could be independent of the physical layer, but does not define a 1521 new protocol. It examines the design criteria for a method, with 1522 recommendations to ensure scalability and improve support for the IP 1523 protocol stack. 1525 8. Security Considerations 1527 The normal security issues relating to the use of wireless links for 1528 transmission of Internet traffic should be considered. 1530 L2 signalling in MPEG-2 transmission networks is currently provided 1531 by (periodic) broadcasting of information in the control plane using 1532 PSI/SI tables (section 4). A loss or modification of the SI 1533 information may result in an inability to identify the TS Logical 1534 Channel (PID) that is used for a service. This will prevent 1535 reception of the intended IP packet stream. 1537 There are known security issues relating to the use of unsecured 1538 address resolution [RFC3756]. Readers are also referred to the 1539 known security issues when mapping IP addresses to MAC/NPA addresses 1540 using ARP [RFC826] and ND [RFC2461]. It is recommended that AR 1541 protocols support authentication of the source of AR messages and 1542 the integrity of the AR information, this avoids known security 1543 vulnerabilities resulting from insertion of unauthorised AR messages 1544 within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] 1545 may be used in place of ND. This defines security mechanisms that 1546 can protect AR. 1548 AR protocols can also be protected by the use of L2 security methods 1549 (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods 1550 are used, the security of ARP and ND can be comparable to that of a 1551 private LAN: A Receiver will only accept ARP or ND transmissions 1552 from the set of peer senders that share a common group encryption 1553 and common group authentication key provided by the L2 key 1554 management. 1556 AR Servers (section 5.4) are susceptible to the same kind of 1557 security issues as end hosts using unsecured AR. These issues 1558 include hijacking traffic and denial-of-service within the subnet. 1559 Malicious nodes within the subnet can take advantage of this 1560 property, and hijack traffic. In addition, an AR Server is 1561 essentially a legitimate man-in-the-middle, which implies that there 1562 is a need to distinguish such proxies from unwanted man-in-the- 1563 middle attackers. This document does not introduce any new 1564 mechanisms for the protection of these AR functions (e.g. 1565 authenticating servers, or defining AR Servers that interoperate 1566 with the SEND protocol [ID-SP-ND]). 1568 9. Acknowledgments 1570 The authors wish to thank the ipdvb WG members for their inputs and 1571 in particular, Rod Walsh, Jun Takei, and Michael Mercurio. The 1572 authors also acknowledge the support of the European Space Agency. 1573 Martin Stiemerling contributed descriptions of scenarios, 1574 configuration, and provided extensive proof reading. Hidetaka 1575 Izumiyama contributed on UDLR and IPv6 issues. A number of issues 1576 discussed in the UDLR working group have also provided valuable 1577 inputs to this document (summarised in draft-ietf-udlr-experiments- 1578 01.txt). 1580 10. References 1582 10.1 Normative References 1584 [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 1585 v1.3.1, European Telecommunications Standards Institute (ETSI), May 1586 2003. 1588 [ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB); Multimedia 1589 Home Platform (MHP) Specification", v1.2.1, European 1590 Telecommunications Standards Institute (ETSI), June 2002. 1592 [ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB); 1593 Specification for Service Information (SI) in DVB systems", v1.7.1, 1594 European Telecommunications Standards Institute (ETSI), December 1595 2005. 1597 [ISO-MPEG2] ISO/IEC IS 13818-1, "Information technology -- Generic 1598 coding of moving pictures and associated audio information -- Part 1599 1: Systems", International Standards Organisation (ISO), 2000. 1601 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 1602 826, IETF, November 1982. 1604 [RFC1112] Deering, S.E., "Host Extensions for IP Multicasting", 1605 RFC1112, (STD05), August 1989. 1607 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1608 Discovery for IP Version 6 (IPv6), RFC 2461, December 1998. 1610 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1611 Networks", RFC 2464, December 1998. 1613 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1614 2131, March 1997. 1616 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 1617 Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", 1618 RFC 3077, March 2001. 1620 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1621 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 1622 (DHCPv6)", RFC 3315, July 2003. 1624 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1625 (DHCP) Service for IPv6", RFC 3736, April 2004. 1627 [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional 1628 Lightweight Encapsulation (ULE) for transmission of IP datagrams 1629 over an MPEG-2 Transport Stream", RFC 4326, December 2005. 1631 10.2 Informative References 1633 [ATSC] A/53C, "ATSC Digital Television Standard", Advanced 1634 Television Systems Committee (ATSC), Doc. A/53C, 2004. 1636 [ATSC-A54A] A/54A, "Guide to the use of the ATSC Digital Television 1637 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 1638 2003. 1640 [ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced Television 1641 Systems Committee (ATSC), Doc. A/90, 2000. 1643 [ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data 1644 Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 1645 2002. 1647 [DOCSIS] "Data-Over-Cable Service Interface Specifications, DOCSIS 1648 2.0, Radio Frequency Interface Specification", CableLabs, document 1649 CM-SP-RFIv2.0-I10-051209, 2005. 1651 [DVB] Digital Video Broadcasting (DVB) Project. http://www.dvb.org 1653 [ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation 1654 of Service Information (SI) codes for DVB systems", European 1655 Telecommunications Standards Institute (ETSI). 1657 [ETSI-RCS] EN 301 790, "Digital Video Broadcasting (DVB); 1658 Interaction channel for satellite distribution Systems", European 1659 Telecommunications Standards Institute (ETSI). 1661 [ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology -- Generic 1662 coding of moving pictures and associated audio information -- Part 1663 6: Extensions for DSM-CC is a full software implementation", 1664 International Standards Organisation (ISO), 2002. 1666 [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, 1667 "Security requirements for the Unidirectional Lightweight 1668 Encapsulation (ULE) protocol", Work in Progress, draft-ietf-ipdvb- 1669 sec-req-xx.txt. 1671 [ID-IAB-LINK] Aboba, B., Davies, E., Thaler, D., "Multiple 1672 Encapsulation Methods Considered Harmful"", Work in Progress, draft- 1673 iab-link-encaps-08.txt. 1675 [ID-SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem 1676 Statement", Work in progress, draft-daley-send-spnd-prob-01.txt, 1677 February 2005. 1679 [802.1D] "IEEE Standard for Local and Metropolitan Area Networks: 1680 Media Access Control (MAC) Bridges", IEEE, 204. 1682 [LLC] ISO/IEC 8802.2, "Information technology; Telecommunications 1683 and information exchange between systems; Local and metropolitan 1684 area networks; Specific requirements; Part 2: Logical Link Control", 1685 International Standards Organisation (ISO), 1998. 1687 [MMT] "SatLabs System Recommendations, Part 1, General 1688 Specifications", Version 2.0, SatLabs Forum, 2006. 1689 http://satlabs.org/pdf/SatLabs_System_Recommendations_v2.0_general.p 1690 df 1692 [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 1693 September 1985. 1695 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1696 2131, March 1997. 1698 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1699 RFC 2365, July 1998. 1701 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 1702 Assignments", RFC 2375, July 1998. 1704 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1705 Autoconfiguration", RFC 2462, December 1998. 1707 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1708 3046, January 2001. 1710 [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable 1711 Service Interface Specifications) Device Class DHCP (Dynamic Host 1712 Configuration Protocol) Relay Agent Information Sub-option", RFC 1713 3256, April 2002. 1715 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1716 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 1717 3376, October 2002. 1719 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 1720 Sooriyabandara, "TCP Performance Implications of Network Path 1721 Asymmetry", BCP 69, RFC 3449, December 2002. 1723 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1724 M., and J. Crowcroft, "Layered Coding Transport (LCT) Building 1725 Block", RFC 3451, December 2002. 1727 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1728 Multicast (SSM)", RFC 3569, July 2003. 1730 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1731 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1733 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1734 Control (WEBRC) Building Block", RFC 3738, April 2004. 1736 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1737 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1739 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1740 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, 1741 "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 1742 2004. 1744 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1745 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1747 [RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D., Collini- 1748 Nocker, B., and H. Linder, "Architecture for IP transport 1749 over MPEG-2 Networks". 1751 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1752 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1754 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1755 Proxies (ND Proxy)", RFC 4389, April 2006. 1757 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1758 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 1759 Specification (Revised)", RFC 4601, August 2006. 1761 [RFC4605] B Fenner, B., He, H., Haberman, B., and H. Sandick, 1762 "Internet Group Management Protocol (IGMP) / Multicast Listener 1763 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 1764 RFC 4605, August 2006. 1766 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 1767 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access 1768 Networks", RFC 4779, January 2007. 1770 [SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6, 1771 March 2002. 1773 11. Authors' Addresses 1775 Godred Fairhurst 1776 Department of Engineering 1777 University of Aberdeen 1778 Aberdeen, AB24 3UE 1779 UK 1780 gorry@erg.abdn.ac.uk 1781 http://www.erg.abdn.ac.uk/users/gorry 1783 Marie-Jose Montpetit 1784 Motorola Connected Home Solutions 1785 Advanced Technology 1786 55 Hayden Avenue , 3rd Floor 1787 Lexington 1788 Massachusetts 1789 02421 1790 USA 1791 mmontpetit@motorola.com 1793 12. IPR Notices 1795 12.1 Intellectual Property Statement 1797 The IETF takes no position regarding the validity or scope of any 1798 Intellectual Property Rights or other rights that might be claimed 1799 to pertain to the implementation or use of the technology described 1800 in this document or the extent to which any license under such 1801 rights might or might not be available; nor does it represent that 1802 it has made any independent effort to identify any such rights. 1803 Information on the procedures with respect to rights in RFC 1804 documents can be found in BCP 78 and BCP 79. 1806 Copies of IPR disclosures made to the IETF Secretariat and any 1807 assurances of licenses to be made available, or the result of an 1808 attempt made to obtain a general license or permission for the use 1809 of such proprietary rights by implementers or users of this 1810 specification can be obtained from the IETF on-line IPR repository 1811 at http://www.ietf.org/ipr. 1813 The IETF invites any interested party to bring to its attention any 1814 copyrights, patents or patent applications, or other proprietary 1815 rights that may cover technology that may be required to implement 1816 this standard. Please address the information to the IETF at ietf- 1817 ipr@ietf.org. 1819 12.2 Disclaimer of Validity 1821 This document and the information contained herein are provided on an 1822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1824 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1825 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1829 13. Copyright Statement 1831 Copyright (C) The IETF Trust (2007). 1833 This document is subject to the rights, licenses and restrictions 1834 contained in BCP 78, and except as set forth therein, the authors 1835 retain all their rights. 1837 14. IANA Considerations 1839 This document does not define a protocol or protocol extension. No 1840 action is required by the IANA. 1842 >>> NOTE to RFC Editor: Please remove this appendix prior to 1843 publication] 1845 Document History 1847 -00 This draft is intended as a study item for proposed future 1848 work by the IETF in this area. 1849 -01 Review of initial content, major edit and refinement of 1850 concepts 1851 -02 fairly important review; took out all new protocol reference; 1852 added one author; added contribution on real implementation 1853 -02 Added content to respond to 61st IETF comments; 1854 refined ID goals; rewrote section 4.2 and 4.3; added cable 1855 information. 1856 -03 Major reorganise to align with Charter, and clearly identify 1857 IP issues. 1858 -04 restructured the draft (major rewrite) and added discussion of 1859 arp and ND related to specific cases for use. 1861 WG -00 1862 Reformatted as WG Draft. 1863 Added inputs from UDLR working group on UDLR, DHCP, etc. 1865 WG-01 1866 This rev. included a number of changes: 1867 * Added the case for large no. of groups/dynamic join to 3.2 1868 * ISO MPEG-2 table requirements added to section 4, following 1869 discussion on the list. 1870 * Added AR Authentication note to security considerations. 1872 WG-02 1873 * Major editorial work to bring this up tro DRAFT RFC format 1874 * Removed duplication of scoping discussion with ipdvb-arch 1875 * Reworded UDLR section to separate protocol issues from UDLR 1876 specifics. 1877 * Added SI security discussion. 1878 * Minor corrections 1879 * Added text from A/92 on scoping. 1880 * Aligned definitions with ipdvb-arch. 1881 * Fixed Reference format 1882 * Removed markers for additional contributions 1883 * No contributions received on PPPoE (removed). 1885 WG-03 1886 * Sections restructured to offer clearer advice on IETF-defined 1887 protocols. 1888 * Section added on bridging v routing cases 1889 * Section added on AR Server and use with arp and ND. 1890 * Section added to collect issues relating to DHCP 1891 * English improved to prepare for WGLC. 1893 WG-04 1894 * Fixed spelling mistake noted by George Kinal 1895 * Comments on various issues received from Rupert Goodrings 1896 * Comments on various issues received from Martin Striemerling 1897 * Comments on DAD and UDLR from Tina Strauf 1898 * Comments on DAD and MAC addresses from Bernhard Collini-Nocker 1899 * English fixed. 1900 * Title change (inserted methods) 1902 WG-05 (following WGLC) 1903 * Fixed security issues noted by George Gross 1904 * Added text on Mobility, topology changes with AR cache. 1906 * To be consistent with RFC4326, NPA = ULA address indicated by the 1907 D-bit, whereas MAC means IEEE-style address. I've reworked the text 1908 to make this clearer. Also made all "NPA/MAC" into "MAC/NPA". 1910 * Added notes on AR caches when used in mobile/ST topology changes. 1912 * Also note a mistake to section (iii) which was confusing about L2 1913 multicast addresses, this now reads: 1915 " (iii) IP and other protocols may view sets of L3 multicast 1916 addresses as link-local. This may produce unexpected results 1917 if frames with the corresponding multicast L2 addresses are 1918 distributed to systems in a different L3 network or 1919 multicast scope (see sections 3.2 and 5.6)" 1921 * Section 2, Added: 1922 MAC Address: A 6 byte link layer address of the format described by 1923 the Ethernet IEEE 802 standard (see also NPA). 1925 * Section 3, Revised bullet into two points: 1926 A scalable architecture that may support large numbers of systems 1927 within the MPEG-2 network [RFC4259]. 1929 A method for transmission of AR information from an AR Server to 1930 clients that minimise the transmission cost (link local multicast, 1931 is preferable to subnet broadcast). 1933 * Section 3, changed *context* to *scope* 1934 * Section 4.3. Revised wording on T Stream v. TS Logical Channel. 1935 * Section 5.4. 2nd para, added *(mapping the IP address to the L2 1936 address)* 1937 * Added: 1938 The default parameters specified in RFC 2461 for the ND protocol can 1939 introduce interoperability problems (e.g. a failure to resolve when 1940 the link RTT exceed 3 seconds) and performance degradation 1941 (duplicate ND messages with a link RTT > 1 second) when used in 1942 networks were the link RTT is significantly larger than experienced 1943 by Ethernet LANs. Tuning of the protocol parameters (e.g. 1944 RTR_SOLICITATION_INTERVAL) is therefore recommended when using 1945 Network links with appreciable delay (Section 6.3.2 of [RFC2461]). 1947 WG-06 (following IESG Discuss) 1949 1) Added text on draft-iab-link-encaps-05, indicating ULE or MPE 1950 must be solely used and highlighting interoperability implications 1951 of this situation. 1953 ------------------------------------------------------- 1954 2) Methods also exist to assign IP addresses to Receivers within a 1955 network (e.g. DHCP [RFC2131], DHC [RFC3736]). 1956 - Replaced by stateless autoconfiguration [RFC2461], DHCP [RFC2131], 1957 DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736]. 1959 ------------------------------------------------------- 1960 3) A method to represent IPv4/IPv6 AR information (including 1961 security associations to authenticate the AR information that will 1962 prevent address masquerading [RFC3756]). 1963 s/associations/mechanisms/. 1965 ------------------------------------------------------- 1966 4) Re-wording to avoid the ambiguity in the text: 1968 The goal of this multicast address resolution is to allow a 1969 Receiver to associate an IPv4 or IPv6 multicast address with 1970 a specific TS Logical Channel and the corresponding TS Multiplex. 1972 ------------------------------------------------------- 1973 5) Re-wording 1974 SEND does not require the configuration of per-host keys and can co- 1975 exist with the use of both SEND and insecure ND on the same link. 1977 ------------------------------------------------------- 1978 6) Updated sections that describe DAD issues to be clearer that this 1979 arises when there is no MAC source address, or the bridge does not 1980 filter based on source addresses. 1982 ------------------------------------------------------- 1983 7) Added text. 1984 >> Since there is no MAC/NPA address in the SNDU, ARP and NDP are 1985 not required. 1986 > 1987 > ND for address resolution is not needed, but it may still be 1988 needed for DAD or NUD. 1990 Added: 1992 The ND Protocol is also used to perform other functions beyond 1993 address resolution, including Router Solicitation / Advertisement, 1994 Duplicate Address Detection (DAD), Neighbor Unreachability Detection 1995 (NUD), Redirect. These functions are useful for hosts, even when 1996 address resolution is not required. 1998 And then in this place: 2000 The ND protocol may still be required to support DAD, and other 2001 network functions. However, since there is no MAC source address, 2002 there is no way for a system to differentiate DAD packets sent by 2003 itself from those that may have been sent by another system with the 2004 same L3 address, DAD therefore can not be used in topologies where 2005 this L2 forwarding may occur (e.g. UDLR). 2007 ------------------------------------------------------- 2008 8) Section 6.1 ULE without a destination MAC/NPA address (D=1) 2009 Added text stating the need to support multicast for RAs. 2010 ------------------------------------------------------- 2011 9) Added that Bridging over MPE/LLC is currently under-specified. 2012 Therefore implementations may vary, and it should NOT be assumed 2013 that frames sent using the Receiver's MAC address are necessarily 2014 delivered to the Receiver's IP stack. 2015 ------------------------------------------------------- 2016 10) Changed Section 3 text to , given that we can not prevent 2018 this, only defend against it. 2019 ------------------------------------------------------ 2020 11) Added citation to Satlabs recommendation, these documents are 2021 now much more complete and provide valuable references to the 2022 method. The latest spec also defines an IPv6 mode. 2023 ------------------------------------------------------ 2024 12) Updated draft referenced with published RFC numbers. 2026 [>>> NOTE to RFC Editor: End of appendix]