tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4947

 
 
 

Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

Part 2 of 2, p. 21 to 41
Prev RFC Part

 


prevText      Top      Up      ToC       Page 21 
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

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
                                           /-----\
                         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

Top      Up      ToC       Page 24 
   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.

Top      Up      ToC       Page 25 
   (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.

Top      Up      ToC       Page 26 
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

Top      Up      ToC       Page 27 
   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].

Top      Up      ToC       Page 28 
   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

Top      Up      ToC       Page 29 
   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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
   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,

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
   [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.

Top      Up      ToC       Page 37 
   [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.

Top      Up      ToC       Page 38 
   [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.

Top      Up      ToC       Page 39 
   [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.

Top      Up      ToC       Page 40 
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

Top      Up      ToC       Page 41 
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.