GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4947

Network Working Group G. Fairhurst Request for Comments: 4947 University of Aberdeen Category: Informational M.-J. Montpetit

                                     Motorola Connected Home Solutions
                                                             July 2007
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 This document describes the process of binding/associating IPv4/IPv6
 addresses with MPEG-2 Transport Streams (TS).  This procedure is
 known as Address Resolution (AR) or Neighbor Discovery (ND).  Such
 address resolution complements the higher-layer resource discovery
 tools that are used to advertise IP sessions.
 In MPEG-2 Networks, an IP address must be associated with a Packet ID
 (PID) value and a specific Transmission Multiplex.  This document
 reviews current methods appropriate to a range of technologies (such
 as DVB (Digital Video Broadcasting), ATSC (Advanced Television
 Systems Committee), DOCSIS (Data-Over-Cable Service Interface
 Specifications), and variants).  It also describes the interaction
 with well-known protocols for address management including DHCP, ARP,
 and the ND protocol.

Fairhurst & Montpetit Informational [Page 1] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

Table of Contents

 1. Introduction ....................................................3
    1.1. Bridging and Routing .......................................4
 2. Conventions Used in This Document ...............................7
 3. Address Resolution Requirements ................................10
    3.1. Unicast Support ...........................................12
    3.2. Multicast Support .........................................12
 4. MPEG-2 Address Resolution ......................................14
    4.1. Static Configuration ......................................15
         4.1.1. MPEG-2 Cable Networks ..............................15
    4.2. MPEG-2 Table-Based Address Resolution .....................16
         4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17
         4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18
         4.2.3. Application Information Table (AIT) and Its Usage ..18
         4.2.4. Address Resolution in ATSC .........................19
         4.2.5. Comparison of SI/PSI Table Approaches ..............19
    4.3. IP-Based Address Resolution for TS Logical Channels .......19
 5. Mapping IP Addresses to MAC/NPA Addresses ......................21
    5.1. Unidirectional Links Supporting Unidirectional
         Connectivity ..............................................22
    5.2. Unidirectional Links with Bidirectional Connectivity ......23
    5.3. Bidirectional Links .......................................25
    5.4. AR Server .................................................26
    5.5. DHCP Tuning ...............................................27
    5.6. IP Multicast AR ...........................................27
         5.6.1. Multicast/Broadcast Addressing for UDLR ............28
 6. Link Layer Support .............................................29
    6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30
    6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31
    6.3. MPE without LLC/SNAP Encapsulation ........................31
    6.4. MPE with LLC/SNAP Encapsulation ...........................31
    6.5. ULE with Bridging Header Extension (D=1) ..................32
    6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32
    6.7. MPE with LLC/SNAP & Bridging ..............................33
 7. Conclusions ....................................................33
 8. Security Considerations ........................................34
 9. Acknowledgments ................................................35
 10. References ....................................................35
    10.1. Normative References .....................................35
    10.2. Informative References ...................................36

Fairhurst & Montpetit Informational [Page 2] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

1. Introduction

 This document describes the process of binding/associating IPv4/IPv6
 addresses with MPEG-2 Transport Streams (TS).  This procedure is
 known as Address Resolution (AR), or Neighbor Discovery (ND).  Such
 address resolution complements the higher layer resource discovery
 tools that are used to advertise IP sessions.  The document reviews
 current methods appropriate to a range of technologies (DVB, ATSC,
 DOCSIS, and variants).  It also describes the interaction with well-
 known protocols for address management including DHCP, ARP, and the
 ND protocol.
 The MPEG-2 TS provides a time-division multiplexed (TDM) stream that
 may contain audio, video, and data information, including
 encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC
 138181 [ISO-MPEG2].  Each Layer 2 (L2) frame, known as a TS Packet,
 contains a 4 byte header and a 184 byte payload.  Each TS Packet is
 associated with a single TS Logical Channel, identified by a 13-bit
 Packet ID (PID) value that is carried in the MPEG-2 TS Packet header.
 The MPEG-2 standard also defines a control plane that may be used to
 transmit control information to Receivers in the form of System
 Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific
 Information (PSI) Tables.
 To utilize the MPEG-2 TS as a L2 link supporting IP, a sender must
 associate an IP address with a particular Transmission Multiplex, and
 within the multiplex, identify the specific PID to be used.  This
 document calls this mapping an AR function.  In some AR schemes, the
 MPEG-2 TS address space is subdivided into logical contexts known as
 Platforms [ETSI-DAT].  Each Platform associates an IP service
 provider with a separate context that shares a common MPEG-2 TS
 (i.e., uses the same PID value).
 MPEG-2 Receivers may use a Network Point of Attachment (NPA)
 [RFC4259] to uniquely identify a L2 node within an MPEG-2
 transmission network.  An example of an NPA is the IEEE Medium Access
 Control (MAC) address.  Where such addresses are used, these must
 also be signalled by the AR procedure.  Finally, address resolution
 could signal the format of the data being transmitted, for example,
 the encapsulation, with any L2 encryption method and any compression
 scheme [RFC4259].
 The numbers of Receivers connected via a single MPEG-2 link may be
 much larger than found in other common LAN technologies (e.g.,
 Ethernet).  This has implications on design/configuration of the
 address resolution mechanisms.  Current routing protocols and some
 multicast application protocols also do not scale to arbitrarily

Fairhurst & Montpetit Informational [Page 3] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 large numbers of participants.  Such networks do not by themselves
 introduce an appreciable subnetwork round trip delay, however many
 practical MPEG-2 transmission networks are built using links that may
 introduce a significant path delay (satellite links, use of dial-up
 modem return, cellular return, etc.).  This higher delay may need to
 be accommodated by address resolution protocols that use this
 service.

1.1. Bridging and Routing

 The following two figures illustrate the use of AR for a routed and a
 bridged subnetwork.  Various other combinations of L2 and L3
 forwarding may also be used over MPEG-2 links (including Receivers
 that are IP end hosts and end hosts directly connected to bridged LAN
 segments).
                         Broadcast Link AR
                         - - - - - - - - -
                         |               |
                         \/
                          1a            2b        2a
                 +--------+              +--------+
             ----+   R1   +----------+---+   R2   +----
                 +--------+ MPEG-2   |   +--------+
                            Link     |
                                     |   +--------+
                                     +---+   R3   +----
                                     |   +--------+
                                     |
                                     |   +--------+
                                     +---+   R4   +----
                                     |   +--------+
                                     |
                                     |
                    Figure 1: A routed MPEG-2 link
 Figure 1 shows a routed MPEG-2 link feeding three downstream routers
 (R2-R4).  AR takes place at the Encapsulator (R1) to identify each
 Receiver at Layer 2 within the IP subnetwork (R2, etc.).
 When considering unicast communication from R1 to R2, several L2
 addresses are involved:
 1a is the L2 (sending) interface address of R1 on the MPEG-2 link.
 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link.
 2a is the L2 (sending) interface address of R2 on the next hop link.

Fairhurst & Montpetit Informational [Page 4] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 AR for the MPEG-2 link allows R1 to determine the L2 address (2b)
 corresponding to the next hop Receiver, router R2.
 Figure 2 shows a bridged MPEG-2 link feeding three downstream bridges
 (B2-B4).  AR takes place at the Encapsulator (B1) to identify each
 Receiver at L2 (B2-B4).  AR also takes place across the IP subnetwork
 allowing the Feed router (R1) to identify the downstream Routers at
 Layer 2 (R2, etc.).  The Encapsulator associates a destination
 MAC/NPA address with each bridged PDU sent on an MPEG-2 link.  Two
 methods are defined by ULE (Unidirectional Lightweight Encapsulation)
 [RFC4326]:
 The simplest method uses the L2 address of the transmitted frame.
 This is the MAC address corresponding to the destination within the
 L2 subnetwork (the next hop router, 2b of R2).  This requires each
 Receiver (B2-B4) to associate the receiving MPEG-2 interface with the
 set of MAC addresses that exist on the L2 subnetworks that it feeds.
 Similar considerations apply when IP-based tunnels support L2
 services (including the use of UDLR (Unidirectional Links)
 [RFC3077]).
 It is also possible for a bridging Encapsulator (B1) to encapsulate a
 PDU with a link-specific header that also contains the MAC/NPA
 address associated with a Receiver L2 interface on the MPEG-2 link
 (Figure 2).  In this case, the destination MAC/NPA address of the
 encapsulated frame is set to the Receiver MAC/NPA address (y), rather
 than the address of the final L2 destination.  At a different level,
 an AR binding is also required for R1 to associate the destination L2
 address 2b with R2.  In a subnetwork using bridging, the systems R1
 and R2 will normally use standard IETF-defined AR mechanisms (e.g.,
 IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor
 Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP
 subnetwork.

Fairhurst & Montpetit Informational [Page 5] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

                              Subnetwork AR
                    - - - - - - - - - - - - - - - -
                    |                             |
                    |        MPEG-2 Link AR       |
                           - - - - - - - - -
                    |      |               |      |
                    \/     \/
                    1a      x              y      2b        2a
           +--------+  +----+              +----+  +--------+
       ----+   R1   +--| B1 +----------+---+ B2 +--+   R2   +----
           +--------+  +----+ MPEG-2   |   +----+  +--------+
                              Link     |
                                       |   +----+
                                       +---+ B3 +--
                                       |   +----+
                                       |
                                       |   +----+
                                       +---+ B4 +--
                                       |   +----+
                                       |
                     Figure 2: A bridged MPEG-2 link
 Methods also exist to assign IP addresses to Receivers within a
 network (e.g., stateless autoconfiguration [RFC2461], DHCP [RFC2131],
 DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]).  Receivers may
 also participate in the remote configuration of the L3 IP addresses
 used in connected equipment (e.g., using DHCP-Relay [RFC3046]).
 The remainder of this document describes current mechanisms and their
 use to associate an IP address with the corresponding TS Multiplex,
 PID value, the MAC/NPA address and/or Platform ID.  A range of
 approaches is described, including Layer 2 mechanisms (using MPEG-2
 SI tables), and protocols at the IP level (including ARP [RFC826] and
 ND [RFC2461]).  Interactions and dependencies between these
 mechanisms and the encapsulation methods are described.  The document
 does not propose or define a new protocol, but does provide guidance
 on issues that would need to be considered to supply IP-based address
 resolution.

Fairhurst & Montpetit Informational [Page 6] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

2. Conventions Used in This Document

 AIT: Application Information Table specified by the Multimedia Home
 Platform (MHP) specifications [ETSI-MHP].  This table may carry
 IPv4/IPv6 to MPEG-2 TS address resolution information.
 ATSC: Advanced Television Systems Committee [ATSC].  A framework and
 a set of associated standards for the transmission of video, audio,
 and data using the ISO MPEG-2 standard [ISO-MPEG2].
 b: bit.  For example, one byte consists of 8-bits.
 B: Byte.  Groups of bytes are represented in Internet byte order.
 DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC].  A
 format for the transmission of data and control information carried
 in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
 DVB: Digital Video Broadcasting [DVB].  A framework and set of
 associated standards published by the European Telecommunications
 Standards Institute (ETSI) for the transmission of video, audio, and
 data, using the ISO MPEG-2 Standard.
 DVB-RCS: Digital Video Broadcast Return Channel via Satellite.  A
 bidirectional IPv4/IPv6 service employing low-cost Receivers
 [ETSI-RCS].
 DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS].
 Encapsulator: A network device that receives PDUs and formats these
 into Payload Units (known here as SNDUs) for output as a stream of TS
 Packets.
 Feed Router: The router delivering the IP service over a
 Unidirectional Link.
 INT: Internet/MAC Notification Table.  A unidirectional address
 resolution mechanism using SI and/or PSI Tables.
 L2: Layer 2, the link layer.
 L3: Layer 3, the IP network layer.
 MAC: Medium Access Control [IEEE-802.3].  A link layer protocol
 defined by the IEEE 802.3 standard (or by Ethernet v2).
 MAC Address: A 6-byte link layer address of the format described by
 the Ethernet IEEE 802 standard (see also NPA).

Fairhurst & Montpetit Informational [Page 7] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 MAC Header: The link layer header of the IEEE 802.3 standard
 [IEEE-802.3] or Ethernet v2.  It consists of a 6-byte destination
 address, 6-byte source address, and 2 byte type field (see also NPA,
 LLC (Logical Link Control)).
 MHP: Multimedia Home Platform.  An integrated MPEG-2 multimedia
 Receiver, that may (in some cases) support IPv4/IPv6 services
 [ETSI-MHP].
 MMT: Multicast Mapping Table (proprietary extension to DVB-RCS
 [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to
 PID values).
 MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90].  A  method
 that encapsulates PDUs, forming a DSM-CC Table Section.  Each Section
 is sent in a series of TS Packets using a single Stream (TS Logical
 Channel).
 MPEG-2: A set of standards specified by the Motion Picture Experts
 Group (MPEG), and standardized by the International Standards
 Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
 NPA: Network Point of Attachment.  A 6-byte destination address
 (resembling an IEEE MAC address) within the MPEG-2 transmission
 network that is used to identify individual Receivers or groups of
 Receivers [RFC4259].
 PAT: Program Association Table.  An MPEG-2 PSI control table.  It
 associates each program with the PID value that is used to send the
 associated PMT (Program Map Table).  The table is sent using the
 well-known PID value of 0x000, and is required for an MPEG-2
 compliant Transport Stream.
 PDU: Protocol Data Unit.  Examples of a PDU include Ethernet frames,
 IPv4 or IPv6 Datagrams, and other network packets.
 PID: Packet Identifier  [ISO-MPEG2].  A 13 bit field carried in the
 header of each TS Packet.  This identifies the TS Logical Channel to
 which a TS Packet belongs [ISO-MPEG2].  The TS Packets that form the
 parts of a Table Section, or other Payload Unit must all carry the
 same PID value.  A PID value of all ones indicates a Null TS Packet
 introduced to maintain a constant bit rate of a TS Multiplex.  There
 is no required relationship between the PID values used for TS
 Logical Channels transmitted using different TS Multiplexes.

Fairhurst & Montpetit Informational [Page 8] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 PMT: Program Map Table.  An MPEG-2 PSI control table that associates
 the PID values used by the set of TS Logical Channels/ Streams that
 comprise a program [ISO-MPEG2].  The PID value used to send the PMT
 for a specific program is defined by an entry in the PAT.
 Private Section: A syntactic structure constructed according to Table
 2-30 of [ISO-MPEG2].  The structure may be used to identify private
 information (i.e., not defined by [ISO-MPEG2]) relating to one or
 more elementary streams, or a specific MPEG-2 program, or the entire
 Transport Stream.  Other Standards bodies, e.g., ETSI and ATSC, have
 defined sets of table structures using the private_section structure.
 A Private Section is transmitted as a sequence of TS Packets using a
 TS Logical Channel.  A TS Logical Channel may carry sections from
 more than one set of tables.
 PSI: Program Specific Information [ISO-MPEG2].  PSI is used to convey
 information about services carried in a TS Multiplex.  It is carried
 in one of four specifically identified Table Section constructs
 [ISO-MPEG2], see also SI Table.
 Receiver: Equipment that processes the signal from a TS Multiplex and
 performs filtering and forwarding of encapsulated PDUs to the
 network-layer service (or bridging module when operating at the link
 layer).
 SI Table: Service Information Table [ISO-MPEG2].  In this document,
 this term describes a table that is been defined by another standards
 body to convey information about the services carried in a TS
 Multiplex.  A Table may consist of one or more Table Sections,
 however, all sections of a particular SI Table must be carried over a
 single TS Logical Channel [ISO-MPEG2].
 SNDU: Subnetwork Data Unit.  An encapsulated PDU sent as an MPEG-2
 Payload Unit.
 Table Section: A Payload Unit carrying all or a part of an SI or PSI
 Table [ISO-MPEG2].
 TS: Transport Stream [ISO-MPEG2], a method of transmission at the
 MPEG-2 level using TS Packets; it represents Layer 2 of the ISO/OSI
 reference model.  See also TS Logical Channel and TS Multiplex.
 TS Logical Channel: Transport Stream Logical Channel.  In this
 document, this term identifies a channel at the MPEG-2 level
 [ISO-MPEG2].  This exists at level 2 of the ISO/OSI reference model.
 All packets sent over a TS Logical Channel carry the same PID value
 (this value is unique within a specific TS Multiplex).  The term
 "Stream" is defined in MPEG-2 [ISO-MPEG2].  This describes the

Fairhurst & Montpetit Informational [Page 9] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 content carried by a specific TS Logical Channel (see ULE Stream).
 Some PID values are reserved (by MPEG-2) for specific signaling.
 Other standards (e.g., ATSC and DVB) also reserve specific PID
 values.
 TS Multiplex: In this document, this term defines a set of MPEG-2 TS
 Logical Channels sent over a single lower layer connection.  This may
 be a common physical link (i.e., a transmission at a specified symbol
 rate, FEC setting, and transmission frequency) or an encapsulation
 provided by another protocol layer (e.g., Ethernet, or RTP over IP).
 The same TS Logical Channel may be repeated over more than one TS
 Multiplex (possibly associated with a different PID value) [RFC4259],
 for example, to redistribute the same multicast content to two
 terrestrial TV transmission cells.
 TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex
 [ISO-MPEG2].  Each TS Packet carries a 4B header.
 UDL: Unidirectional link: A one-way transmission link.  For example,
 and IP over DVB link using a broadcast satellite link.
 ULE: Unidirectional Lightweight Encapsulation.  A scheme that
 encapsulates PDUs, into SNDUs that are sent in a series of TS Packets
 using a single TS Logical Channel [RFC4326].
 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
 encapsulated PDUs.  ULE Streams may be identified by definition of a
 stream_type in SI/PSI [RFC4326, ISO-MPEG2].

3. Address Resolution Requirements

 The MPEG IP address resolution process is independent of the choice
 of encapsulation and needs to support a set of IP over MPEG-2
 encapsulation formats, including Multi-Protocol Encapsulation (MPE)
 ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional
 Lightweight Encapsulation (ULE) [RFC4326].
 The general IP over MPEG-2 AR requirements are summarized below:
  1. A scalable architecture that may support large numbers of

systems within the MPEG-2 Network [RFC4259].

  1. A protocol version, to indicate the specific AR protocol in use

and which may include the supported encapsulation method.

  1. A method (e.g., well-known L2/L3 address/addresses) to identify

the AR Server sourcing the AR information.

Fairhurst & Montpetit Informational [Page 10] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

  1. A method to represent IPv4/IPv6 AR information (including

security mechanisms to authenticate the AR information to

      protect against address masquerading [RFC3756]).
  1. A method to install AR information associated with clients at

the AR Server (registration).

  1. A method for transmission of AR information from an AR Server to

clients that minimize the transmission cost (link-local

      multicast is preferable to subnet broadcast).
  1. Incremental update of the AR information held by clients.
  1. Procedures for purging clients of stale AR information.
 An MPEG-2 transmission network may support multiple IP networks.  If
 this is the case, it is important to recognize the scope within which
 an address is resolved to prevent packets from one addressed scope
 leaking into other scopes [RFC4259].  Examples of overlapping IP
 address assignments include:
    (i)   Private unicast addresses (e.g., in IPv4, 10/8 prefix;
          172.16/12 prefix; and 192.168/16 prefix).  Packets with
          these addresses should be confined to one addressed area.
          IPv6 also defines link-local addresses that must not be
          forwarded beyond the link on which they were first sent.
    (ii)  Local scope multicast addresses.  These are only valid
          within the local area (examples for IPv4 include:
          224.0.0/24; 224.0.1/24).  Similar cases exist for some IPv6
          multicast addresses [RFC2375].
    (iii) Scoped multicast addresses [RFC2365] and [RFC2375].
          Forwarding of these addresses is controlled by the scope
          associated with the address.  The addresses are only valid
          within an addressed area (e.g., the 239/8 [RFC2365]).
 Overlapping address assignments may also occur at L2, where the same
 MAC/NPA address is used to identify multiple Receivers [RFC4259]:
    (i)   An MAC/NPA unicast address must be unique within the
          addressed area.  The IEEE-assigned MAC addresses used in
          Ethernet LANs are globally unique.  If the addresses are not
          globally unique, an address must only be re-used by
          Receivers in different addressed (scoped) areas.

Fairhurst & Montpetit Informational [Page 11] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

    (ii)  The MAC/NPA address broadcast address (a L2 address of all
          ones).  Traffic with this address should be confined to one
          addressed area.
    (iii) IP and other protocols may view sets of L3 multicast
          addresses as link-local.  This may produce unexpected
          results if frames with the corresponding multicast L2
          addresses are distributed to systems in a different L3
          network or multicast scope (Sections 3.2 and 5.6).
 Reception of unicast packets destined for another addressed area will
 lead to an increase in the rate of received packets by systems
 connected via the network.  Reception of the additional network
 traffic may contribute to processing load, but should not lead to
 unexpected protocol behaviour, providing that systems can be uniquely
 addressed at L2.  It does however introduce a potential Denial of
 Service (DoS) opportunity.  When the Receiver operates as an IP
 router, the receipt of such a packet can lead to unexpected protocol
 behaviour.

3.1. Unicast Support

 Unicast address resolution is required at two levels.
 At the lower level, the IP (or MAC) address needs to be associated
 with a specific TS Logical Channel (PID value) and the corresponding
 TS Multiplex (Section 4).  Each Encapsulator within an MPEG-2 Network
 is associated with a set of unique TS Logical Channels (PID values)
 that it sources [ETSI-DAT, RFC4259].  Within a specific scope, the
 same unicast IP address may therefore be associated with more than
 one Stream, and each Stream contributes different content (e.g., when
 several different IP Encapsulators contribute IP flows destined to
 the same Receiver).  MPEG-2 Networks may also replicate IP packets to
 send the same content (Simulcast) to different Receivers or via
 different TS Multiplexes.  The configuration of the MPEG-2 Network
 must prevent a Receiver accepting duplicated copies of the same IP
 packet.
 At the upper level, the AR procedure needs to associate an IP address
 with a specific MAC/NPA address (Section 5).

3.2. Multicast Support

 Multicast is an important application for MPEG-2 transmission
 networks, since it exploits the advantages of native support for link
 broadcast.  Multicast address resolution occurs at the network-level
 in associating a specific L2 address with an IP Group Destination
 Address (Section 5.6).  In IPv4 and IPv6 over Ethernet, this

Fairhurst & Montpetit Informational [Page 12] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 association is normally a direct mapping, and this is the default
 method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].
 Address resolution must also occur at the MPEG-2 level (Section 4).
 The goal of this multicast address resolution is to allow a Receiver
 to associate an IPv4 or IPv6 multicast address with a specific TS
 Logical Channel and the corresponding TS Multiplex [RFC4259].  This
 association needs to permit a large number of active multicast
 groups, and should minimize the processing load at the Receiver when
 filtering and forwarding IP multicast packets (e.g., by distributing
 the multicast traffic over a number of TS Logical Channels).  Schemes
 that allow hardware filtering can be beneficial, since these may
 relieve the drivers and operating systems from discarding unwanted
 multicast traffic.
 There are two specific functions required for address resolution in
 IP multicast over MPEG-2 Networks:
 (i)  Mapping IP multicast groups to the underlying MPEG-2 TS Logical
      Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
 (ii) Provide signalling information to allow a Receiver to locate an
      IP multicast flow within an MPEG-2 TS Multiplex.
 Methods are required to identify the scope of an address when an
 MPEG-2 Network supports several logical IP networks and carries
 groups within different multicast scopes [RFC4259].
 Appropriate procedures need to specify the correct action when the
 same multicast group is available on separate TS Logical Channels.
 This could arise when different Encapsulators contribute IP packets
 with the same IP Group Destination Address in the ASM (Any-Source
 Multicast) address range.  Another case arises when a Receiver could
 receive more than one copy of the same packet (e.g., when packets are
 replicated across different TS Logical Channels or even different TS
 Multiplexes, a method known as Simulcasting [ETSI-DAT]).  At the IP
 level, the host/router may be unaware of this duplication and this
 needs to be detected by other means.
 When the MPEG-2 Network is peered to the multicast-enabled Internet,
 an arbitrarily large number of IP multicast group destination
 addresses may be in use, and the set forwarded on the transmission
 network may be expected to vary significantly with time.  Some uses
 of IP multicast employ a range of addresses to support a single
 application (e.g., ND [RFC2461], Layered Coding Transport (LCT)
 [RFC3451], and Wave and Equation Based Rate Control (WEBRC)
 [RFC3738]).  The current set of active addresses may be determined
 dynamically via a multicast group membership protocol (e.g., Internet

Fairhurst & Montpetit Informational [Page 13] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 Group Management Protocol (IGMP) [RFC3376] and Multicast Listener
 Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol
 Independent Multicast (PIM) [RFC4601]) and/or other means (e.g.,
 [RFC3819] and [RFC4605]), however each active address requires a
 binding by the AR method.  Therefore, there are advantages in using a
 method that does not need to explicitly advertise an AR binding for
 each IP traffic flow, but is able to distribute traffic across a
 number of L2 TS Logical Channels (e.g., using a hash/mapping that
 resembles the mapping from IP addresses to MAC addresses [RFC1112,
 RFC2464]).  Such methods can reduce the volume of AR information that
 needs to be distributed, and reduce the AR processing.
 Section 5.6 describes the binding of IP multicast addresses to
 MAC/NPA addresses.

4. MPEG-2 Address Resolution

 The first part of this section describes the role of MPEG-2
 signalling to identify streams (TS Logical Channels [RFC4259]) within
 the L2 infrastructure.
 At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the
 existence and format of a Stream, using a combination of two PSI
 tables: the Program Association Table (PAT) and entries in the
 program element loop of a Program Map Table (PMT).  PMT Tables are
 sent infrequently and are typically small in size.  The PAT is sent
 using the well-known PID value of 0X000.  This table provides the
 correspondence between a program_number and a PID value.  (The
 program_number is the numeric label associated with a program).  Each
 program in the Table is associated with a specific PID value, used to
 identify a TS Logical Channel (i.e., a TS).  The identified TS is
 used to send the PMT, which associates a set of PID values with the
 individual components of the program.  This approach de-references
 the PID values when the MPEG-2 Network includes multiplexors or re-
 multiplexors that renumber the PID values of the TS Logical Channels
 that they process.
 In addition to signalling the Receiver with the PID value assigned to
 a Stream, PMT entries indicate the presence of Streams using ULE and
 MPE to the variety of devices that may operate in the MPEG-2
 transmission network (multiplexors, remultiplexors, rate shapers,
 advertisement insertion equipment, etc.).
 A multiplexor or remultiplexor may change the PID values associated
 with a Stream during the multiplexing process, the new value being
 reflected in an updated PMT.  TS Packets that carry a PID value that
 is not associated with a PMT entry (an orphan PID), may, and usually
 will be dropped by ISO 13818-1 compliant L2 equipment, resulting in

Fairhurst & Montpetit Informational [Page 14] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 the Stream not being forwarded across the transmission network.  In
 networks that do not employ any intermediate devices (e.g., scenarios
 C,E,F of [RFC4259]), or where devices have other means to determine
 the set of PID values in use, the PMT table may still be sent (but is
 not required for this purpose).
 Although the basic PMT information may be used to identify the
 existence of IP traffic, it does not associate a Stream with an IP
 prefix/address.  The remainder of the section describes IP addresses
 resolution mechanisms relating to MPEG-2.

4.1. Static Configuration

 The static mapping option, where IP addresses or flows are statically
 mapped to specific PIDs is the equivalent to signalling "out-of-
 band".  The application programmer, installing engineer, or user
 receives the mapping via some outside means, not in the MPEG-2 TS.
 This is useful for testing, experimental networks, small subnetworks
 and closed domains.
 A pre-defined set of IP addresses may be used within an MPEG-2
 transmission network.  Prior knowledge of the active set of addresses
 allows appropriate AR records to be constructed for each address, and
 to pre-assign the corresponding PID value (e.g., selected to optimize
 Receiver processing; to group related addresses to the same PID
 value; and/or to reflect a policy for usage of specific ranges of PID
 values).  This presumes that the PID mappings are not modified during
 transmission (Section 4).
 A single "well-known" PID is a specialization of this.  This scheme
 is used by current DOCSIS cable modems [DOCSIS], where all IP traffic
 is placed into the specified TS stream.  MAC filtering (and/or
 Section filtering in MPE) may be used to differentiate subnetworks.

4.1.1. MPEG-2 Cable Networks

 Cable networks use a different transmission scheme for downstream
 (head-end to cable modem) and upstream (cable modem to head-end)
 transmissions.
 IP/Ethernet packets are sent (on the downstream) to the cable
 modem(s) encapsulated in MPEG-2 TS Packets sent on a single well-
 known TS Logical Channel (PID).  There is no use of in-band
 signalling tables.  On the upstream, the common approach is to use
 Ethernet framing, rather than IP/Ethernet over MPEG-2, although other
 proprietary schemes also continue to be used.

Fairhurst & Montpetit Informational [Page 15] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 Until the deployment of DOCSIS and EuroDOCSIS, most address
 resolution schemes for IP traffic in cable networks were proprietary,
 and did not usually employ a table-based address resolution method.
 Proprietary methods continue to be used in some cases where cable
 modems require interaction.  In this case, equipment at the head-end
 may act as gateways between the cable modem and the Internet.  These
 gateways receive L2 information and allocate an IP address.
 DOCSIS uses DHCP for IP client configuration.  The Cable Modem
 Terminal System (CMTS) provides a DHCP Server that allocates IP
 addresses to DOCSIS cable modems.  The MPEG-2 transmission network
 provides a L2 bridged network to the cable modem (Section 1).  This
 usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and
 [RFC3256].  Issues in deployment of IPv6 are described in [RFC4779].

4.2. MPEG-2 Table-Based Address Resolution

 The information about the set of MPEG-2 Transport Streams carried
 over a TS Multiplex can be distributed via SI/PSI Tables.  These
 tables are usually sent periodically (Section 4).  This design
 requires access to and processing of the SI Table information by each
 Receiver [ETSI-SI], [ETSI-SI1].  This scheme reflects the complexity
 of delivering and coordinating the various Transport Streams
 associated with multimedia TV.  A TS Multiplex may provide AR
 information for IP services by integrating additional information
 into the existing control tables or by transmitting additional SI
 Tables that are specific to the IP service.
 Examples of MPEG-2 Table usage that allows an MPEG-2 Receiver to
 identify the appropriate PID and the multiplex associated with a
 specific IP address include:
 (i)   IP/MAC Notification Table (INT) in the DVB Data standard
       [ETSI-DAT].  This provides unidirectional address resolution of
       IPv4/IPv6 multicast addresses to an MPEG-2 TS.
 (ii)  Application Information Table (AIT) in the Multimedia Home
       Platform (MHP) specifications [ETSI-MHP].
 (iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by
       some DVB-RCS systems to provide unidirectional address
       resolution of IPv4 multicast addresses to an MPEG-2 TS.
 The MMT and AIT are used for specific applications, whereas the INT
 [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and
 IPv6 AR when used in combination with the other MPEG-2 tables
 (Section 4).

Fairhurst & Montpetit Informational [Page 16] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

4.2.1. IP/MAC Notification Table (INT) and Its Usage

 The INT provides a set of descriptors to specify addressing in a DVB
 network.  The use of this method is specified for Multiprotocol
 Encapsulation (MPE) [ETSI-DAT].  It provides a method for carrying
 information about the location of IP/L2 flows within a DVB network.
 A Platform_ID identifies the addressing scope for a set of IP/L2
 streams and/or Receivers.  A Platform may span several Transport
 Streams carried by one or multiple TS Multiplexes and represents a
 single IP network with a harmonized address space (scope).  This
 allows for the coexistence of several independent IP/MAC address
 scopes within an MPEG-2 Network.
 The INT allows both fully-specified IP addresses and prefix matching
 to reduce the size of the table (and hence enhance signalling
 efficiency).  An IPv4/IPv6 "subnet mask" may be specified in full
 form or by using a slash notation (e.g., /127).  IP multicast
 addresses can be specified with or without a source (address or
 range), although if a source address is specified, then only the
 slash notation may be used for prefixes.
 In addition, for identification and security descriptors, the
 following descriptors are defined for address binding in INT tables:
 (i)   target_MAC_address_descriptor: A descriptor to describe a
       single or set of MAC addresses (and their mask).
 (ii)  target_MAC_address_range_descriptor: A descriptor that may be
       used to set filters.
 (iii) target_IP_address_descriptor: A descriptor describing a single
       or set of IPv4 unicast or multicast addresses (and their mask).
 (iv)  target_IP_slash_descriptor:  Allows definition and announcement
       of an IPv4 prefix.
 (v)   target_IP_source_slash_descriptor: Uses source and destination
       addresses to target a single or set of systems.
 (vi)  IP/MAC stream_location_descriptor: A descriptor that locates an
       IP/MAC stream in a DVB network.
 The following descriptors provide corresponding functions for IPv6
 addresses:
      target_IPv6_address_descriptor
      target_IPv6_slash_descriptor
      and target_IPv6_source_slash_descriptor

Fairhurst & Montpetit Informational [Page 17] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 The ISP_access_mode_descriptor allows specification of a second
 address descriptor to access an ISP via an alternative non-DVB
 (possibly non-IP) network.
 One key benefit is that the approach employs MPEG-2 signalling
 (Section 4) and is integrated with other signalling information.
 This allows the INT to operate in the presence of (re)multiplexors
 [RFC4259] and to refer to PID values that are carried in different TS
 Multiplexes.  This makes it well-suited to a Broadcast TV Scenario
 [RFC4259].
 The principal drawback is a need for an Encapsulator to introduce
 associated PSI/SI MPEG-2 control information.  This control
 information needs to be processed at a Receiver.  This requires
 access to information below the IP layer.  The position of this
 processing within the protocol stack makes it hard to associate the
 results with IP Policy, management, and security functions.  The use
 of centralized management prevents the implementation of a more
 dynamic scheme.

4.2.2. Multicast Mapping Table (MMT) and Its Usage

 In DVB-RCS, unicast AR is seen as a part of a wider configuration and
 control function and does not employ a specific protocol.
 A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control
 table that associates a set of multicast addresses with the
 corresponding PID values [MMT].  This table allows a DVB-RCS Forward
 Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6
 multicast addresses to PID values within a specific TS Multiplex.
 Receivers (DVB-RCS Return Channel Satellite Terminals (RCSTs)) may
 use this table to determine the PID values associated with an IP
 multicast flow that it requires to receive.  The MMT is specified by
 the SatLabs Forum [MMT] and is not currently a part of the DVB-RCS
 specification.

4.2.3. Application Information Table (AIT) and Its Usage

 The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does
 not define a specific AR function.  However, an Application
 Information Table (AIT) is defined that allows MHP Receivers to
 receive a variety of control information.  The AIT uses an MPEG-2
 signalling table, providing information about data broadcasts, the
 required activation state of applications carried by a broadcast
 stream, etc.  This information allows a broadcaster to request that a
 Receiver change the activation state of an application, and to direct

Fairhurst & Montpetit Informational [Page 18] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 applications to receive specific multicast packet flows (using IPv4
 or IPv6 descriptors).  In MHP, AR is not seen as a specific function,
 but as a part of a wider configuration and control function.

4.2.4. Address Resolution in ATSC

 ATSC [ATSC-A54A] defines a system that allows transmission of IP
 packets within an MPEG-2 Network.  An MPEG-2 Program (defined by the
 PMT) may contain one or more applications [ATSC-A90] that include IP
 multicast streams [ATSC-A92].  IP multicast data are signalled in the
 PMT using a stream_type indicator of value 0x0D.  A MAC address list
 descriptor [SCTE-1] may also be included in the PMT.
 The approach focuses on applications that serve the transmission
 network.  A method is defined that uses MPEG-2 SI Tables to bind the
 IP multicast media streams and the corresponding Session Description
 Protocol (SDP) announcement streams to particular MPEG-2 Program
 Elements.  Each application constitutes an independent network.  The
 MPEG-2 Network boundaries establish the IP addressing scope.

4.2.5. Comparison of SI/PSI Table Approaches

 The MPEG-2 methods based on SI/PSI meet the specified requirements of
 the groups that created them and each has their strength:  the INT in
 terms of flexibility and extensibility, the MMT in its simplicity,
 and the AIT in its extensibility.  However, they exhibit scalability
 constraints, represent technology specific solutions, and do not
 fully adopt IP-centric approaches that would enable easier use of the
 MPEG-2 bearer as a link technology within the wider Internet.

4.3. IP-Based Address Resolution for TS Logical Channels

 As MPEG-2 Networks evolve to become multi-service networks, the use
 of IP protocols is becoming more prevalent.  Most MPEG-2 Networks now
 use some IP protocols for operations and control and data delivery.
 Address resolution information could also be sent using IP transport.
 At the time of writing there is no standards-based IP-level AR
 protocol that supports the MPEG-2 TS.
 There is an opportunity to define an IP-level method that could use
 an IP multicast protocol over a well-known IP multicast address to
 resolve an IP address to a TS Logical Channel (i.e., a Transport
 Stream).  The advantages of using an IP-based address resolution
 include:

Fairhurst & Montpetit Informational [Page 19] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 (i)   Simplicity:
       The AR mechanism does not require interpretation of L2 tables;
       this is an advantage especially in the growing market share for
       home network and audio/video networked entities.
 (ii)  Uniformity:
       An IP-based protocol can provide a common method across
       different network scenarios for both IP to MAC address mappings
       and mapping to TS Logical Channels (PID value associated with a
       Stream).
 (iii) Extensibility:
       IP-based AR mechanisms allow an independent evolution of the AR
       protocol.  This includes dynamic methods to request address
       resolution and the ability to include other L2 information
       (e.g., encryption keys).
 (iv)  Integration:
       The information exchanged by IP-based AR protocols can easily
       be integrated as a part of the IP network layer, simplifying
       support for AAA, policy, Operations and Management (OAM),
       mobility, configuration control, etc., that combine AR with
       security.
 The drawbacks of an IP-based method include:
 (i)   It can not operate over an MPEG-2 Network that uses MPEG-2
       remultiplexors [RFC4259] that modify the PID values associated
       with the TS Logical Channels during the multiplexing operation
       (Section 4).  This makes the method unsuitable for use in
       deployed broadcast TV networks [RFC4259].
 (ii)  IP-based methods can introduce concerns about the integrity of
       the information and authentication of the sender [RFC4259].
       (These concerns are also applicable to MPEG-2 Table methods,
       but in this case the information is confined to the L2 network,
       or parts of the network where gateway devices isolate the
       MPEG-2 devices from the larger Internet creating virtual MPEG-2
       private networks.) IP-based solutions should therefore
       implement security mechanisms that may be used to authenticate
       the sender and verify the integrity of the AR information as a
       part of a larger security framework.
 An IP-level method could use an IP multicast protocol running an AR
 Server (see also Section 5.4) over a well-known (or discovered) IP
 multicast address.  To satisfy the requirement for scalability to
 networks with a large number of systems (Section 1), a single packet
 needs to transport multiple AR records and define the intended scope

Fairhurst & Montpetit Informational [Page 20] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 for each address.  Methods that employ prefix matching are desirable
 (e.g., where a range of source/destination addresses are matched to a
 single entry).  It can also be beneficial to use methods that permit
 a range of IP addresses to be mapped to a set of TS Logical Channels
 (e.g., a hashing technique similar to the mapping of IP Group
 Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464]).

5. Mapping IP Addresses to MAC/NPA Addresses

 This section reviews IETF protocols that may be used to assign and
 manage the mapping of IP addresses to/from MAC/NPA addresses over
 MPEG-2 Networks.
 An IP Encapsulator requires AR information to select an appropriate
 MAC/NPA address in the SNDU header [RFC4259] (Section 6).  The
 information to complete this header may be taken directly from a
 neighbor/ARP cache, or may require the Encapsulator to retrieve the
 information using an AR protocol.  The way in which this information
 is collected will depend upon whether the Encapsulator functions as a
 Router (at L3) or a Bridge (at L2) (Section 1.1).
 Two IETF-defined protocols for mapping IP addresses to MAC/NPA
 addresses are the Address Resolution Protocol, ARP [RFC826], and the
 Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and
 IPv6.  Both protocols are normally used in a bidirectional mode,
 although both also permit unsolicited transmission of mappings.  The
 IPv6 mapping defined in [RFC2464] can result in a large number of
 active MAC multicast addresses (e.g., one for each end host).
 ARP requires support for L2 broadcast packets.  A large number of
 Receivers can lead to a proportional increase in ARP traffic, a
 concern for bandwidth-limited networks.  Transmission delay can also
 impact protocol performance.
 ARP also has a number of security vulnerabilities.  ARP spoofing is
 where a system can be fooled by a rogue device that sends a
 fictitious ARP RESPONSE that includes the IP address of a legitimate
 network system and the MAC of a rogue system.  This causes legitimate
 systems on the network to update their ARP tables with the false
 mapping and then send future packets to the rogue system instead of
 the legitimate system.  Using this method, a rogue system can see
 (and modify) packets sent through the network.
 Secure ARP (SARP) uses a secure tunnel (e.g., between each client and
 a server at a wireless access point or router) [RFC4346].  The router
 ignores any ARP RESPONSEs not associated with clients using the
 secure tunnels.  Therefore, only legitimate ARP RESPONSEs are used

Fairhurst & Montpetit Informational [Page 21] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 for updating ARP tables.  SARP requires the installation of software
 at each client.  It suffers from the same scalability issues as the
 standard ARP.
 The ND protocol uses a set of IP multicast addresses.  In large
 networks, many multicast addresses are used, but each client
 typically only listens to a restricted set of group destination
 addresses and little traffic is usually sent in each group.
 Therefore, Layer 2 AR for MPEG-2 Networks must support this in a
 scalable manner.
 A large number of ND messages may cause a large demand for performing
 asymmetric operations.  The base ND protocol limits the rate at which
 multicast responses to solicitations can be sent.  Configurations may
 need to be tuned when operating with large numbers of Receivers.
 The default parameters specified in the ND protocol [RFC2461] can
 introduce interoperability problems (e.g., a failure to resolve when
 the link RTT (round-trip time) exceed 3 seconds) and performance
 degradation (duplicate ND messages with a link RTT > 1 second) when
 used in networks where the link RTT is significantly larger than
 experienced by Ethernet LANs.  Tuning of the protocol parameters
 (e.g., RTR_SOLICITATION_INTERVAL) is therefore recommended when using
 network links with appreciable delay (Section 6.3.2 of [RFC2461]).
 ND has similar security vulnerabilities to ARP.  The Secure Neighbor
 Discovery (SEND) [RFC3971] was developed to address known security
 vulnerabilities in ND [RFC3756].  It can also reduce the AR traffic
 compared to ND.  In addition, SEND does not require the configuration
 of per-host keys and can coexist with the use of both SEND and
 insecure ND on the same link.
 The ND Protocol is also used by IPv6 systems to perform other
 functions beyond address resolution, including Router Solicitation /
 Advertisement, Duplicate Address Detection (DAD), Neighbor
 Unreachability Detection (NUD), and Redirect.  These functions are
 useful for hosts, even when address resolution is not required.

5.1. Unidirectional Links Supporting Unidirectional Connectivity

 MPEG-2 Networks may provide a Unidirectional Broadcast Link (UDL),
 with no return path.  Such links may be used for unicast applications
 that do not require a return path (e.g., based on UDP), but commonly
 are used for IP multicast content distribution.

Fairhurst & Montpetit Informational [Page 22] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

                                         /-----\
                       MPEG-2 Uplink    /MPEG-2 \
                    ###################( Network )
                    #                   \       /
               +----#------+             \--.--/
               |  Network  |                |
               |  Provider +                v MPEG-2 Downlink
               +-----------+                |
                                      +-----v------+
                                      |   MPEG-2   |
                                      |  Receiver  |
                                      +------------+
              Figure 3: Unidirectional connectivity
 The ARP and ND protocols require bidirectional L2/L3 connectivity.
 They do not provide an appropriate method to resolve the remote
 (destination) address in a unidirectional environment.
 Unidirectional links therefore require a separate out-of-band
 configuration method to establish the appropriate AR information at
 the Encapsulator and Receivers.  ULE [RFC4326] defines a mode in
 which the MAC/NPA address is omitted from the SNDU.  In some
 scenarios, this may relieve an Encapsulator of the need for L2 AR.

5.2. Unidirectional Links with Bidirectional Connectivity

 Bidirectional connectivity may be realized using a unidirectional
 link in combination with another network path.  Common combinations
 are a Feed link using MPEG-2 satellite transmission and a return link
 using terrestrial network infrastructure.  This topology is often
 known as a Hybrid network and has asymmetric network routing.
                                         /-----\
                       MPEG-2 uplink    /MPEG-2 \
                    ###################( Network )
                    #                   \       /
               +----#------+             \--.--/
               |  Network  |                |
               |  Provider +-<-+            v MPEG-2 downlink
               +-----------+   |            |
                               |      +-----v------+
                               +--<<--+   MPEG-2   |
                             Return   |  Receiver  |
                             Path     +------------+
              Figure 4: Bidirectional connectivity

Fairhurst & Montpetit Informational [Page 23] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 The Unidirectional Link Routing (UDLR) [RFC3077] protocol may be used
 to overcome issues associated with asymmetric routing.  The Dynamic
 Tunnel Configuration Protocol (DTCP) enables automatic configuration
 of the return path.  UDLR hides the unidirectional routing from the
 IP and upper layer protocols by providing a L2 tunnelling mechanism
 that emulates a bidirectional broadcast link at L2.  A network using
 UDLR has a topology where a Feed Router and all Receivers form a
 logical Local Area Network.  Encapsulating L2 frames allows them to
 be sent through an Internet Path (i.e., bridging).
 Since many unidirectional links employ wireless technology for the
 forward (Feed) link, there may be an appreciable cost associated with
 forwarding traffic on the Feed link.  Therefore, it is often
 desirable to prevent forwarding unnecessary traffic (e.g., for
 multicast this implies control of which groups are forwarded).  The
 implications of forwarding in the return direction must also be
 considered (e.g., asymmetric capacity and loss [RFC3449]).  This
 suggests a need to minimize the volume and frequency of control
 messages.
 Three different AR cases may be identified (each considers sending an
 IP packet to a next-hop IP address that is not currently cached by
 the sender):
 (i)   A Feed Router needs a Receiver MAC/NPA address.
       This occurs when a Feed Router sends an IP packet using the
       Feed UDL to a Receiver whose MAC/NPA address is unknown.  In
       IPv4, the Feed Router sends an ARP REQUEST with the IP address
       of the Receiver.  The Receiver that recognizes its IP address
       replies with an ARP RESPONSE to the MAC/NPA address of the Feed
       Router (e.g., using a UDLR tunnel).  The Feed Router may then
       address IP packets to the unicast MAC/NPA address associated
       with the Receiver.  The ULE encapsulation format also permits
       packets to be sent without specifying a MAC/NPA address, where
       this is desirable (Section 6.1 and 6.5).
 (ii)  A Receiver needs the Feed Router MAC/NPA address.
       This occurs when a Receiver sends an IP packet to a Feed Router
       whose MAC/NPA address is unknown.  In IPv4, the Receiver sends
       an ARP REQUEST with the IP address of the Feed Router (e.g.,
       using a UDLR tunnel).  The Feed Router replies with an ARP
       RESPONSE using the Feed UDL.  The Receiver may then address IP
       packets to the MAC/NPA address of the recipient.

Fairhurst & Montpetit Informational [Page 24] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 (iii) A Receiver needs another Receiver MAC/NPA address.
       This occurs when a Receiver sends an IP packet to another
       Receiver whose MAC/NPA address is unknown.  In IPv4, the
       Receiver sends an ARP REQUEST with the IP address of the remote
       Receiver (e.g., using a UDLR tunnel to the Feed Router).  The
       request is forwarded over the Feed UDL.  The target Receiver
       replies with an ARP RESPONSE (e.g., using a UDLR tunnel).  The
       Feed Router forwards the response on the UDL.  The Receiver may
       then address IP packets to the MAC/NPA address of the
       recipient.
 These 3 cases allow any system connected to the UDL to obtain the
 MAC/NPA address of any other system.  Similar exchanges may be
 performed using the ND protocol for IPv6.
 A long round trip delay (via the UDL and UDLR tunnel) impacts the
 performance of the reactive address resolution procedures provided by
 ARP, ND, and SEND.  In contrast to Ethernet, during the interval when
 resolution is taking place, many IP packets may be received that are
 addressed to the AR Target address.  The ARP specification allows an
 interface to discard these packets while awaiting the response to the
 resolution request.  An appropriately sized buffer would however
 prevent this loss.
 In case (iii), the time to complete address resolution may be reduced
 by the use of an AR Server at the Feed (Section 5.4).
 Using DHCP requires prior establishment of the L2 connectivity to a
 DHCP Server.  The delay in establishing return connectivity in UDLR
 networks that use DHCP, may make it beneficial to increase the
 frequency of the DTCP HELLO message.  Further information about
 tuning DHCP is provided in Section 5.5.

5.3. Bidirectional Links

 Bidirectional IP networks can be and are constructed by a combination
 of two MPEG-2 transmission links.  One link is usually a broadcast
 link that feeds a set of remote Receivers.  Links are also provided
 from Receivers so that the combined link functions as a full duplex
 interface.  Examples of this use include two-way DVB-S satellite
 links and the DVB-RCS system.

Fairhurst & Montpetit Informational [Page 25] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

5.4. AR Server

 An AR Server can be used to distribute AR information to Receivers in
 an MPEG-2 Network.  In some topologies, this may significantly reduce
 the time taken for Receivers to discover AR information.
 The AR Server can operate as a proxy responding on behalf of
 Receivers to received AR requests.  When an IPv4 AR request is
 received (e.g., Receiver ARP REQUEST), an AR Server responds by
 (proxy) sending an AR response, providing the appropriate IP to
 MAC/NPA binding (mapping the IP address to the L2 address).
 Information may also be sent unsolicited by the AR Server using
 multicast/broadcast to update the ARP/neighbor cache at the Receivers
 without the need for explicit requests.  The unsolicited method can
 improve scaling in large networks.  Scaling could be further improved
 by distributing a single broadcast/multicast AR message that binds
 multiple IP and MAC/NPA addresses.  This reduces the network capacity
 consumed and simplifies client/server processing in networks with
 large numbers of clients.
 An AR Server can be implemented using IETF-defined Protocols by
 configuring the subnetwork so that AR Requests from Receivers are
 intercepted rather than forwarded to the Feed/broadcast link.  The
 intercepted messages are sent to an AR Server.  The AR Server
 maintains a set of MAC/NPA address bindings.  These may be configured
 or may learned by monitoring ARP messages sent by Receivers.
 Currently defined IETF protocols only allow one binding per message
 (i.e., there is no optimization to conserve L2 bandwidth).
 Equivalent methods could provide IPv6 AR.  Procedures for
 intercepting ND messages are defined in [RFC4389].  To perform an AR
 Server function, the AR information must also be cached.  A caching
 AR proxy stores the system state within a middle-box device.  This
 resembles a classic man-in-the-middle security attack; interactions
 with SEND are described in [SP-ND].
 Methods are needed to purge stale AR data from the cache.  The
 consistency of the cache must also be considered when the Receiver
 bindings can change (e.g., IP mobility, network topology changes, or
 intermittent Receiver connectivity).  In these cases, the use of old
 (stale) information can result in IP packets being directed to an
 inappropriate L2 address, with consequent packet loss.
 Current IETF-defined methods provide bindings of IP addresses to
 MAC/NPA, but do not allow the bindings to other L2 information
 pertinent to MPEG-2 Networks, requiring the use of other methods for

Fairhurst & Montpetit Informational [Page 26] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 this function (Section 4).  AR Servers can also be implemented using
 non-IETF AR protocols to provide the AR information required by
 Receivers.

5.5. DHCP Tuning

 DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 Networks
 with bidirectional connectivity.  DHCP consists of two components: a
 protocol for delivering system-specific configuration parameters from
 a DHCP Server to a DHCP Client (e.g., default router, DNS server) and
 a mechanism for the allocation of network addresses to systems.
 The configuration of DHCP Servers and DHCP Clients should take into
 account the local link round trip delay (possibly including the
 additional delay from bridging, e.g., using UDLR).  A large number of
 clients can make it desirable to tune the DHCP lease duration and the
 size of the address pool.  Appropriate timer values should also be
 selected: the DHCP messages retransmission timeout, and the maximum
 delay that a DHCP Server waits before deciding that the absence of an
 ICMP echo response indicates that the relevant address is free.
 DHCP Clients may retransmit DHCP messages if they do not receive a
 response.  Some client implementations specify a timeout for the
 DHCPDISCOVER message that is small (e.g., suited to Ethernet delay,
 rather than appropriate to an MPEG-2 Network) providing insufficient
 time for a DHCP Server to respond to a DHCPDISCOVER retransmission
 before expiry of the check on the lease availability (by an ICMP Echo
 Request), resulting in potential address conflict.  This value may
 need to be tuned for MPEG-2 Networks.

5.6. IP Multicast AR

 Section 3.2 describes the multicast address resolution requirements.
 This section describes L3 address bindings when the destination
 network-layer address is an IP multicast Group Destination Address.
 In MPE [ETSI-DAT], a mapping is specified for the MAC Address based
 on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464].
 (A variant of DVB (DVB-H) uses a modified MAC header [ETSI-DAT]).
 In ULE [RFC4326], the L2 NPA address is optional, and is not
 necessarily required when the Receiver is able to perform efficient
 L3 multicast address filtering.  When present, a mapping is defined
 based on the IP multicast address for IPv4 [RFC1112] and IPv6
 [RFC2464].

Fairhurst & Montpetit Informational [Page 27] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 The L2 group addressing method specified in [RFC1112] and [RFC2464]
 can result in more than one IP destination address being mapped to
 the same L2 address.  In Source-Specific Multicast, SSM [RFC3569],
 multicast groups are identified by the combination of the IP source
 and IP destination addresses.  Therefore, senders may independently
 select an IP group destination address that could map to the same L2
 address if forwarded onto the same L2 link.  The resulting addressing
 overlap at L2 can increase the volume of traffic forwarded to L3,
 where it then needs to be filtered.
 These considerations are the same as for Ethernet LANs, and may not
 be of concern to Receivers that can perform efficient L3 filtering.
 Section 3 noted that an MPEG-2 Network may need to support multiple
 addressing scopes at the network and link layers.  Separation of the
 different groups into different Transport Streams is one remedy (with
 signalling of IP to PID value mappings).  Another approach is to
 employ alternate MAC/NPA mappings to those defined in [RFC1112] and
 [RFC2464], but such mappings need to be consistently bound at the
 Encapsulator and Receiver, using AR procedures in a scalable manner.

5.6.1. Multicast/Broadcast Addressing for UDLR

 UDLR is a Layer 2 solution, in which a Receiver may send
 multicast/broadcast frames that are subsequently forwarded natively
 by a Feed Router (using the topology in Figure 2), and are finally
 received at the Feed interface of the originating Receiver.  This
 multicast forwarding does not include the normal L3 Reverse Path
 Forwarding (RPF) check or L2 spanning tree checks, the processing of
 the IP Time To Live (TTL) field or the filtering of administratively
 scoped multicast addresses.  This raises a need to carefully consider
 multicast support.  To avoid forwarding loops, RFC 3077 notes that a
 Receiver needs to be configured with appropriate filter rules to
 ensure that it discards packets that originate from an attached
 network and are later received over the Feed link.
 When the encapsulation includes an MAC/NPA source address, re-
 broadcast packets may be filtered at the link layer using a filter
 that discards L2 addresses that are local to the Receiver.  In some
 circumstances, systems can send packets with an unknown (all-zero)
 MAC source address (e.g., IGMP Proxy Queriers [RFC4605]), where the
 source at L2 can not be determined at the Receiver.  These packets
 need to be silently discarded, which may prevent running the
 associated services on the Receiver.
 Some encapsulation formats also do not include an MAC/NPA source
 address (Table 1).  Multicast packets may therefore alternatively be
 discarded at the IP layer if their IP source address matches a local
 IP address (or address range).  Systems can send packets with an

Fairhurst & Montpetit Informational [Page 28] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 all-zero IP source address (e.g., BOOTP (bootstrap protocol)
 [RFC951], DHCP [RFC2131] and ND [RFC2461]), where the source at L3
 can not be determined at the Receiver these packets need to be
 silently discarded.  This may prevent running the associated services
 at a Receiver, e.g., participation in IPv6 Duplicate Address
 Detection or running a DHCP server.

6. Link Layer Support

 This section considers link layer (L2) support for address resolution
 in MPEG-2 Networks.  It considers two issues: The code-point used at
 L2 and the efficiency of encapsulation for transmission required to
 support the AR method.  The table below summarizes the options for
 both MPE ([ETSI-DAT], [ATSC-A90]) and ULE [RFC4326] encapsulations.
 [RFC4840] describes issues and concerns that may arise when a link
 can support multiple encapsulations.  In particular, it identifies
 problems that arise when end hosts that belong to the same IP network
 employ different incompatible encapsulation methods.  An Encapsulator
 must therefore use only one method (e.g., ULE or MPE) to support a
 single IP network (i.e., set of IPv4 systems sharing the same subnet
 broadcast address or same IPv6 prefix).  All Receivers in an IP
 network must receive all IP packets that use a broadcast (directed to
 all systems in the IP network) or a local-scope multicast address
 (Section 3).  Packets with these addresses are used by many IP-based
 protocols including service discovery, IP AR, and routing protocols.
 Systems that fail to receive these packets can suffer connectivity
 failure or incorrect behaviour (e.g., they may be unable to
 participate in IP-based discovery, configuration, routing, and
 announcement protocols).  Consistent delivery can be ensured by
 transmitting link-local multicast or broadcast packets using the same
 Stream that is used for unicast packets directed to this network.  A
 Receiver could simultaneously use more than one L2 AR mechanism.
 This presents a potential conflict when the Receiver receives two
 different bindings for the same identifier.  When multiple systems
 advertise AR bindings for the same identifiers (e.g., Encapsulators),
 they must ensure that the advertised information is consistent.
 Conflicts may also arise when L2 protocols duplicate the functions of
 IP-based AR mechanisms.
 In ULE, the bridging format may be used in combination with the
 normal mode to address packets to a Receiver (all ULE Receivers are
 required to implement both methods).  Frames carrying IP packets
 using the ULE Bridging mode, that have a destination address
 corresponding to the MAC address of the Receiver and have an IP
 address corresponding to a Receiver interface, will be delivered to
 the IP stack of the Receiver.  All bridged IP multicast and broadcast
 frames will also be copied to the IP stack of the Receiver.

Fairhurst & Montpetit Informational [Page 29] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 Receivers must filter (discard) frames that are received with a
 source address that matches an address of the Receiver itself
 [802.1D].  It must also prevent forwarding frames already sent on a
 connected network.  For each network interface, it must therefore
 filter received frames where the frame source address matches a
 unicast destination address associated with a different network
 interface [802.1D].
 +-------------------------------+--------+----------------------+
 |                               | PDU    |L2 Frame Header Fields|
 | L2 Encapsulation              |overhead+----------------------+
 |                               |[bytes] |src mac|dst mac| type |
 +-------------------------------+--------+-------+-------+------+
 |6.1 ULE without dst MAC address| 8      |   -   |  -    | x    |
 |6.2 ULE with dst MAC address   | 14     |   -   |  x    | x    |
 |6.3 MPE without LLC/SNAP       | 16     |   -   |  x    | -    |
 |6.4 MPE with LLC/SNAP          | 24     |   -   |  x    | x    |
 |6.5 ULE with Bridging extension| 22     |   x   |  x    | x    |
 |6.6 ULE with Bridging & NPA    | 28     |   x   |  x    | x    |
 |6.7 MPE with LLC/SNAP&Bridging | 38     |   x   |  x    | x    |
 +-------------------------------+--------+-------+-------+------+
 Table 1: L2 Support and Overhead (x =supported, - =not supported)
 The remainder of the section describes IETF-specified AR methods for
 use with these encapsulation formats.  Most of these methods rely on
 bidirectional communications (see Sections 5.1, 5.2, and 5.3 for a
 discussion of this).

6.1. ULE without a Destination MAC/NPA Address (D=1)

 The ULE encapsulation supports a mode (D=1) where the MAC/NPA address
 is not present in the encapsulated frame.  This mode may be used with
 both IPv4 and IPv6.  When used, the Receiver is expected to perform
 L3 filtering of packets based on their IP destination address
 [RFC4326].  This requires careful consideration of the network
 topology when a Receiver is an IP router, or delivers data to an IP
 router (a simple case where this is permitted arises in the
 connection of stub networks at a Receiver that have no connectivity
 to other networks).  Since there is no MAC/NPA address in the SNDU,
 ARP and the ND protocol are not required for AR.
 IPv6 systems can automatically configure their IPv6 network address
 based upon a local MAC address [RFC2462].  To use auto-configuration,
 the IP driver at the Receiver may need to access the MAC/NPA address
 of the receiving interface, even though this value is not being used
 to filter received SNDUs.

Fairhurst & Montpetit Informational [Page 30] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 Even when not used for AR, the ND protocol may still be required to
 support DAD, and other IPv6 network-layer functions.  This protocol
 uses a block of IPv6 multicast addresses, which need to be carried by
 the L2 network.  However, since this encapsulation format does not
 provide a MAC source address, there are topologies (e.g., Section
 5.6.1) where a system can not differentiate DAD packets that were
 originally sent by itself and were re-broadcast, from those that may
 have been sent by another system with the same L3 address.
 Therefore, DAD can not be used with this encapsulation format in
 topologies where this L2 forwarding may occur.

6.2. ULE with a Destination MAC/NPA Address (D=0)

 The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by
 an IEEE EtherType and may be used over ULE [RFC4326].  Although no
 MAC source address is present in the ULE SNDU, the ARP protocol still
 communicates the source MAC (hardware) address in the ARP record
 payload of any query messages that it generates.
 The IPv6 ND protocol is supported.  The protocol uses a block of IPv6
 multicast addresses, which need to be carried by the L2 network.  The
 protocol uses a block of IPv6 multicast addresses, which need to be
 carried by the L2 network.  However, since this encapsulation format
 does not provide a MAC source address, there are topologies (e.g.,
 Section 5.6.1) where a system can not differentiate DAD packets that
 were originally sent by itself and were re-broadcast, from those that
 may have been sent by another system with the same L3 address.
 Therefore, DAD can not be used with this encapsulation format in
 topologies where this L2 forwarding may occur.

6.3. MPE without LLC/SNAP Encapsulation

 This is the default (and sometimes only) mode specified by most MPE
 Encapsulators.  MPE does not provide an EtherType field and therefore
 can not support the Address Resolution Protocol (ARP) [RFC826].
 IPv6 is not supported in this encapsulation format, and therefore it
 is not appropriate to consider the ND protocol.

6.4. MPE with LLC/SNAP Encapsulation

 The LLC/SNAP (Sub-Network Access Protocol) format of MPE provides an
 EtherType field and therefore may support ARP [RFC826].  There is no
 specification to define how this is performed.  No MAC source address
 is present in the SNDU, although the protocol communicates the source
 MAC address in the ARP record payload of any query messages that it
 generates.

Fairhurst & Montpetit Informational [Page 31] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 The IPv6 ND protocol is supported using The LLC/SNAP format of MPE.
 This requires specific multicast addresses to be carried by the L2
 network.  The IPv6 ND protocol is supported.  The protocol uses a
 block of IPv6 multicast addresses, which need to be carried by the L2
 network.  However, since this encapsulation format does not provide a
 MAC source address, there are topologies (e.g., Section 5.6.1) where
 a system can not differentiate DAD packets that were originally sent
 by itself and were re-broadcast, from those that may have been sent
 by another system with the same L3 address.  Therefore, DAD can not
 be used with this encapsulation format in topologies where this L2
 forwarding may occur.

6.5. ULE with Bridging Header Extension (D=1)

 The ULE encapsulation supports a bridging extension header that
 supplies both a source and destination MAC address.  This can be used
 without an NPA address (D=1).  When no other Extension Headers
 precede this Extension, the MAC destination address has the same
 position in the ULE SNDU as that used for an NPA destination address.
 The Receiver may optionally be configured so that the MAC destination
 address value is identical to a Receiver NPA address.
 At the Encapsulator, the ULE MAC/NPA destination address is
 determined by a L2 forwarding decision.  Received frames may be
 forwarded or may be addressed to the Receiver itself.  As in other L2
 LANs, the Receiver may choose to filter received frames based on a
 configured MAC destination address filter.  ARP and ND messages may
 be carried within a PDU that is bridged by this encapsulation format.
 Where the topology may result in subsequent reception of re-
 broadcast copies of multicast frames that were originally sent by a
 Receiver (e.g., Section 5.6.1), the system must discard frames that
 are received with a source address that it used in frames sent from
 the same interface [802.1D].  This prevents duplication on the
 bridged network (e.g., this would otherwise invoke DAD).

6.6. ULE with Bridging Header Extension and NPA Address (D=0)

 The combination of an NPA address (D=0) and a bridging extension
 header are allowed in ULE.  This SNDU format supplies both a source
 and destination MAC address and a NPA destination address (i.e.,
 Receiver MAC/NPA address).
 At the Encapsulator, the value of the ULE MAC/NPA destination address
 is determined by a L2 forwarding decision.  At the Receiver, frames
 may be forwarded or may be addressed to the Receiver itself.  As in
 other L2 LANs, the Receiver may choose to filter received frames
 based on a configured MAC destination address filter.  ARP and ND
 messages may be carried within a PDU that is bridged by this

Fairhurst & Montpetit Informational [Page 32] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 encapsulation format.  Where the topology may result in the
 subsequent reception of re-broadcast copies of multicast frames, that
 were originally sent by a Receiver (e.g., Section 5.6.1), the system
 must discard frames that are received with a source address that it
 used in frames sent from the same interface [802.1D].  This prevents
 duplication on the bridged network (e.g., this would otherwise invoke
 DAD).

6.7. MPE with LLC/SNAP & Bridging

 The LLC/SNAP format MPE frames may optionally support an IEEE
 bridging header [LLC].  This header supplies both a source and
 destination MAC address, at the expense of larger encapsulation
 overhead.  The format defines two MAC destination addresses, one
 associated with the MPE SNDU (i.e., Receiver MAC address) and one
 with the bridged MAC frame (i.e., the MAC address of the intended
 recipient in the remote LAN).
 At the Encapsulator, the MPE MAC destination address is determined by
 a L2 forwarding decision.  There is currently no formal description
 of the Receiver processing for this encapsulation format.  A Receiver
 may forward frames or they may be addressed to the Receiver itself.
 As in other L2 LANs, the Receiver may choose to filter received
 frames based on a configured MAC destination address filter.  ARP and
 ND messages may be carried within a PDU that is bridged by this
 encapsulation format.  The MPE MAC destination address is determined
 by a L2 forwarding decision.  Where the topology may result in a
 subsequent reception of re-broadcast copies of multicast frames, that
 were originally sent by a Receiver (e.g., Section 5.6.1), the system
 must discard frames that are received with a source address that it
 used in frames sent from the same interface [802.1D].  This prevents
 duplication on the bridged network (e.g., this would otherwise invoke
 DAD).

7. Conclusions

 This document describes addressing and address resolution issues for
 IP protocols over MPEG-2 transmission networks using both wired and
 wireless technologies.  A number of specific IETF protocols are
 discussed along with their expected behaviour over MPEG-2
 transmission networks.  Recommendations for their usage are provided.
 There is no single common approach used in all MPEG-2 Networks.  A
 static binding may be configured for IP addresses and PIDs (as in
 some cable networks).  In broadcast networks, this information is
 normally provided by the Encapsulator/Multiplexor and carried in
 signalling tables (e.g., AIT in MHP, the IP Notification Table, INT,

Fairhurst & Montpetit Informational [Page 33] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 of DVB and the DVB-RCS Multicast Mapping Table, and MMT).  This
 document has reviewed the status of these current address resolution
 mechanisms in MPEG-2 transmission networks and defined their usage.
 The document also considers a unified IP-based method for AR that
 could be independent of the physical layer, but does not define a new
 protocol.  It examines the design criteria for a method, with
 recommendations to ensure scalability and improve support for the IP
 protocol stack.

8. Security Considerations

 The normal security issues relating to the use of wireless links for
 transmission of Internet traffic should be considered.
 L2 signalling in MPEG-2 transmission networks is currently provided
 by (periodic) broadcasting of information in the control plane using
 PSI/SI tables (Section 4).  A loss or modification of the SI
 information may result in an inability to identify the TS Logical
 Channel (PID) that is used for a service.  This will prevent
 reception of the intended IP packet stream.
 There are known security issues relating to the use of unsecured
 address resolution [RFC3756].  Readers are also referred to the known
 security issues when mapping IP addresses to MAC/NPA addresses using
 ARP [RFC826] and ND [RFC2461].  It is recommended that AR protocols
 support authentication of the source of AR messages and the integrity
 of the AR information, this avoids known security vulnerabilities
 resulting from insertion of unauthorized AR messages within a L2
 infrastructure.  For IPv6, the SEND protocol [RFC3971] may be used in
 place of ND.  This defines security mechanisms that can protect AR.
 AR protocols can also be protected by the use of L2 security methods
 (e.g., Encryption of the ULE SNDU [IPDVB-SEC]).  When these methods
 are used, the security of ARP and ND can be comparable to that of a
 private LAN: A Receiver will only accept ARP or ND transmissions from
 the set of peer senders that share a common group encryption and
 common group authentication key provided by the L2 key management.
 AR Servers (Section 5.4) are susceptible to the same kind of security
 issues as end hosts using unsecured AR.  These issues include
 hijacking traffic and denial-of-service within the subnet.  Malicious
 nodes within the subnet can take advantage of this property, and
 hijack traffic.  In addition, an AR Server is essentially a
 legitimate man-in-the-middle, which implies that there is a need to
 distinguish such proxies from unwanted man-in-the-middle attackers.
 This document does not introduce any new mechanisms for the

Fairhurst & Montpetit Informational [Page 34] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 protection of these AR functions (e.g., authenticating servers, or
 defining AR Servers that interoperate with the SEND protocol
 [SP-ND]).

9. Acknowledgments

 The authors wish to thank the IPDVB WG members for their inputs and
 in particular, Rod Walsh, Jun Takei, and Michael Mercurio.  The
 authors also acknowledge the support of the European Space Agency.
 Martin Stiemerling contributed descriptions of scenarios,
 configuration, and provided extensive proof reading.  Hidetaka
 Izumiyama contributed on UDLR and IPv6 issues.  A number of issues
 discussed in the UDLR working group have also provided valuable
 inputs to this document (summarized in "Experiments with RFC 3077",
 July 2003).

10. References

10.1. Normative References

 [ETSI-DAT]    EN 301 192, "Specifications for Data Broadcasting",
               v1.3.1, European Telecommunications Standards Institute
               (ETSI), May 2003.
 [ETSI-MHP]    TS 101 812, "Digital Video Broadcasting (DVB);
               Multimedia Home Platform (MHP) Specification", v1.2.1,
               European Telecommunications Standards Institute (ETSI),
               June 2002.
 [ETSI-SI]     EN 300 468, "Digital Video Broadcasting (DVB);
               Specification for Service Information (SI) in DVB
               systems", v1.7.1, European Telecommunications Standards
               Institute (ETSI), December 2005.
 [ISO-MPEG2]   ISO/IEC IS 13818-1, "Information technology -- Generic
               coding of moving pictures and associated audio
               information -- Part 1: Systems", International
               Standards Organization (ISO), 2000.
 [RFC826]      Plummer, D., "Ethernet Address Resolution Protocol: Or
               Converting Network Protocol Addresses to 48.bit
               Ethernet Address for Transmission on Ethernet
               Hardware", STD 37, RFC 826, November 1982.
 [RFC1112]     Deering, S., "Host extensions for IP multicasting", STD
               5, RFC 1112, August 1989.

Fairhurst & Montpetit Informational [Page 35] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 [RFC2461]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
               Discovery for IP Version 6 (IPv6)", RFC 2461, December
               1998.
 [RFC2464]     Crawford, M., "Transmission of IPv6 Packets over
               Ethernet Networks", RFC 2464, December 1998.
 [RFC2131]     Droms, R., "Dynamic Host Configuration Protocol", RFC
               2131, March 1997.
 [RFC3077]     Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
               Y. Zhang, "A Link-Layer Tunneling Mechanism for
               Unidirectional Links", RFC 3077, March 2001.
 [RFC3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
               and M. Carney, "Dynamic Host Configuration Protocol for
               IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC3736]     Droms, R., "Stateless Dynamic Host Configuration
               Protocol (DHCP) Service for IPv6", RFC 3736, April
               2004.
 [RFC4326]     Fairhurst, G. and B. Collini-Nocker, "Unidirectional
               Lightweight Encapsulation (ULE) for Transmission of IP
               Datagrams over an MPEG-2 Transport Stream (TS)", RFC
               4326, December 2005.

10.2. Informative References

 [802.1D]      IEEE 802.1D, "IEEE Standard for Local and Metropolitan
               Area Networks:  Media Access Control (MAC) Bridges",
               IEEE, 2004.
 [802.3]       IEEE 802.3, "Local and metropolitan area networks-
               Specific requirements Part 3: Carrier sense multiple
               access with collision detection (CSMA/CD) access method
               and physical layer specifications", IEEE Computer
               Society, (also ISO/IEC 8802-3), 2002.
 [ATSC]        A/53C, "ATSC Digital Television Standard", Advanced
               Television Systems Committee (ATSC), Doc. A/53C, 2004.
 [ATSC-A54A]   A/54A, "Guide to the use of the ATSC Digital Television
               Standard", Advanced Television Systems Committee
               (ATSC), Doc. A/54A, 2003.
 [ATSC-A90]    A/90, "ATSC Data Broadcast Standard", Advanced
               Television Systems Committee (ATSC), Doc. A/90, 2000.

Fairhurst & Montpetit Informational [Page 36] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 [ATSC-A92]    A/92,  "Delivery of IP Multicast Sessions over ATSC
               Data Broadcast", Advanced Television Systems Committee
               (ATSC), Doc. A/92, 2002.
 [DOCSIS]      "Data-Over-Cable Service Interface Specifications,
               DOCSIS 2.0, Radio Frequency Interface Specification",
               CableLabs, document CM-SP-RFIv2.0-I10-051209, 2005.
 [DVB]         Digital Video Broadcasting (DVB) Project.
               http://www.dvb.org.
 [ETSI-DVBS]   EN 301 421,"Digital Video Broadcasting (DVB);
               Modulation and Coding for DBS satellite systems at
               11/12 GHz", European Telecommunications Standards
               Institute (ETSI).
 [ETSI-RCS]    EN 301 790, "Digital Video Broadcasting (DVB);
               Interaction channel for satellite distribution
               Systems", European Telecommunications Standards
               Institute (ETSI).
 [ETSI-SI1]    TR 101 162, "Digital Video Broadcasting (DVB);
               Allocation of Service Information (SI) codes for DVB
               systems", European Telecommunications Standards
               Institute (ETSI).
 [IPDVB-SEC]   H. Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai,
               "Security requirements for the Unidirectional
               Lightweight Encapsulation (ULE) protocol", Work in
               Progress, May 2007.
 [ISO-DSMCC]   ISO/IEC IS 13818-6, "Information technology -- Generic
               coding of moving pictures and associated audio
               information -- Part 6: Extensions for DSM-CC is a full
               software implementation", International Standards
               Organization (ISO), 2002.
 [LLC]         ISO/IEC 8802.2, "Information technology;
               Telecommunications and information exchange between
               systems; Local and metropolitan area networks; Specific
               requirements; Part 2: Logical Link Control",
               International Standards Organization (ISO), 1998.
 [MMT]         "SatLabs System Recommendations, Part 1, General
               Specifications", Version 2.0, SatLabs Forum, 2006.
               http://satlabs.org/pdf/
               SatLabs_System_Recommendations_v2.0_general.pdf.

Fairhurst & Montpetit Informational [Page 37] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 [RFC951]      Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC
               951, September 1985.
 [RFC2365]     Meyer, D., "Administratively Scoped IP Multicast", BCP
               23, RFC 2365, July 1998.
 [RFC2375]     Hinden, R. and S. Deering, "IPv6 Multicast Address
               Assignments", RFC 2375, July 1998.
 [RFC2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
               Autoconfiguration", RFC 2462, December 1998.
 [RFC3046]     Patrick, M., "DHCP Relay Agent Information Option", RFC
               3046, January 2001.
 [RFC3256]     Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable
               Service Interface Specifications) Device Class DHCP
               (Dynamic Host Configuration Protocol) Relay Agent
               Information Sub-option", RFC 3256, April 2002.
 [RFC3376]     Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
               Thyagarajan, "Internet Group Management Protocol,
               Version 3", RFC 3376, October 2002.
 [RFC3449]     Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and
               M. Sooriyabandara, "TCP Performance Implications of
               Network Path Asymmetry", BCP 69, RFC 3449, December
               2002.
 [RFC3451]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
               Handley, M., and J. Crowcroft, "Layered Coding
               Transport (LCT) Building Block", RFC 3451, December
               2002.
 [RFC3569]     Bhattacharyya, S., "An Overview of Source-Specific
               Multicast (SSM)", RFC 3569, July 2003.
 [RFC3756]     Nikander, P., Kempf, J., and E. Nordmark, "IPv6
               Neighbor Discovery (ND) Trust Models and Threats", RFC
               3756, May 2004.
 [RFC3738]     Luby, M. and V. Goyal, "Wave and Equation Based Rate
               Control (WEBRC) Building Block", RFC 3738, April 2004.
 [RFC3810]     Vida, R. and L. Costa, "Multicast Listener Discovery
               Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

Fairhurst & Montpetit Informational [Page 38] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

 [RFC3819]     Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
               Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
               L. Wood, "Advice for Internet Subnetwork Designers",
               BCP 89, RFC 3819, July 2004.
 [RFC3971]     Arkko, J., Kempf, J., Zill, B., and P. Nikander,
               "SEcure Neighbor Discovery (SEND)", RFC 3971, March
               2005.
 [RFC4259]     Weis, B., "The Use of RSA/SHA-1 Signatures within
               Encapsulating Security Payload (ESP) and Authentication
               Header (AH)", RFC 4359, January 2006.
 [RFC4346]     Dierks, T. and E. Rescorla, "The Transport Layer
               Security (TLS) Protocol Version 1.1", RFC 4346, April
               2006.
 [RFC4389]     Thaler, D., Talwar, M., and C. Patel, "Neighbor
               Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
 [RFC4601]     Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", RFC 4601, August
               2006.
 [RFC4605]     Fenner, B., He, H., Haberman, B., and H. Sandick,
               "Internet Group Management Protocol (IGMP) / Multicast
               Listener Discovery (MLD)-Based Multicast Forwarding
               ("IGMP/MLD Proxying")", RFC 4605, August 2006.
 [RFC4779]     Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P.,
               and J. Palet, "ISP IPv6 Deployment Scenarios in
               Broadband Access Networks", RFC 4779, January 2007.
 [RFC4840]     Aboba, B., Davies, E., and D. Thaler, "Multiple
               Encapsulation Methods Considered Harmful", RFC 4840,
               April 2007.
 [SCTE-1]      "IP Multicast for Digital MPEG Networks", SCTE DVS
               311r6, March 2002.
 [SP-ND]       Daley, G., "Securing Proxy Neighbour Discovery Problem
               Statement", Work in Progress, February 2005.

Fairhurst & Montpetit Informational [Page 39] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

Authors' Addresses

 Godred Fairhurst
 Department of Engineering
 University of Aberdeen
 Aberdeen, AB24 3UE
 UK
 EMail: gorry@erg.abdn.ac.uk
 URL: http://www.erg.abdn.ac.uk/users/gorry
 Marie-Jose Montpetit
 Motorola Connected Home Solutions
 Advanced Technology
 55 Hayden Avenue, 3rd Floor
 Lexington, Massachusetts  02421
 USA
 EMail: mmontpetit@motorola.com

Fairhurst & Montpetit Informational [Page 40] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Fairhurst & Montpetit Informational [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4947.txt · Last modified: 2007/07/13 23:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki