RFC 4947
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
Pages: 41
Informational
Informational
Part 2 of 2 – Pages 21 to 41
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
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.
/-----\ 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
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.
(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.
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
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].
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
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.
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.
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.
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
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,
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
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.
[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.
[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.
[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.
[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.
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
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.