RFC 4947
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
RFC 4947: Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks ✨
okay bestie, let's get the vibes check out of the way first 💖 This is RFC 4947, an Informational doc dated July 2007. It came out of the Network Working Group 🎀 The authors are G. Fairhurst from the University of Aberdeen and M.-J. Montpetit from Motorola Connected Home Solutions. This title block doesn't list any RFCs that it obsoletes or updates, so it's a standalone vibe 🦋
Status of This Memo
this memo is giving information for the Internet community 🌸 It does not specify an Internet standard of any kind, so nobody is forced to implement anything here. Distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice
the legal bit 🧚 Copyright (C) The IETF Trust (2007).
Abstract ✨
so this document describes how you bind or associate IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND) 🦋 Address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions, so they work as a team 🫶
In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex 🔥 This document reviews current methods that fit a range of technologies, like DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants 📺 It also covers how all of this talks to well-known address management protocols, including DHCP, ARP, and the ND protocol 💜
Table of Contents 📚
1. Introduction ....................................................3
1.1. Bridging and Routing .......................................4
2. Conventions Used in This Document ...............................7
3. Address Resolution Requirements ................................10
3.1. Unicast Support ...........................................12
3.2. Multicast Support .........................................12
4. MPEG-2 Address Resolution ......................................14
4.1. Static Configuration ......................................15
4.1.1. MPEG-2 Cable Networks ..............................15
4.2. MPEG-2 Table-Based Address Resolution .....................16
4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17
4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18
4.2.3. Application Information Table (AIT) and Its Usage ..18
4.2.4. Address Resolution in ATSC .........................19
4.2.5. Comparison of SI/PSI Table Approaches ..............19
4.3. IP-Based Address Resolution for TS Logical Channels .......19
5. Mapping IP Addresses to MAC/NPA Addresses ......................21
5.1. Unidirectional Links Supporting Unidirectional
Connectivity ..............................................22
5.2. Unidirectional Links with Bidirectional Connectivity ......23
5.3. Bidirectional Links .......................................25
5.4. AR Server .................................................26
5.5. DHCP Tuning ...............................................27
5.6. IP Multicast AR ...........................................27
5.6.1. Multicast/Broadcast Addressing for UDLR ............28
6. Link Layer Support .............................................29
6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30
6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31
6.3. MPE without LLC/SNAP Encapsulation ........................31
6.4. MPE with LLC/SNAP Encapsulation ...........................31
6.5. ULE with Bridging Header Extension (D=1) ..................32
6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32
6.7. MPE with LLC/SNAP & Bridging ..............................33
7. Conclusions ....................................................33
8. Security Considerations ........................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................361. Introduction ✨
okay so this section repeats the big idea 💖 It describes how you bind or associate IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbor Discovery (ND) 🦋 Address resolution works alongside the higher-layer resource discovery tools that advertise IP sessions. The document reviews current methods that fit a range of technologies (DVB, ATSC, DOCSIS, and variants), and it also covers how these methods interact with well-known protocols for address management, including DHCP, ARP, and the ND protocol 🫶
The MPEG-2 TS is a time-division multiplexed (TDM) stream that can carry audio, video, and data, including encapsulated IP Datagrams [RFC4259], which are defined in specification ISO/IEC 138181 [ISO-MPEG2] 🎀 Each Layer 2 (L2) frame, known as a TS Packet, has a 4 byte header and a 184 byte payload 🍓 Every TS Packet belongs to a single TS Logical Channel, which is identified by a 13-bit Packet ID (PID) value carried in the MPEG-2 TS Packet header. iconic design, honestly 😭
The MPEG-2 standard also defines a control plane. It can send control information to Receivers in the form of System Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific Information (PSI) Tables 🧚
So here's the thing 👑 To use the MPEG-2 TS as an L2 link that supports IP, a sender has to associate an IP address with a particular Transmission Multiplex, and then identify the specific PID to use inside that multiplex. This document calls that mapping an AR function. In some AR schemes, the MPEG-2 TS address space is split into logical contexts called Platforms [ETSI-DAT]. Each Platform links an IP service provider to its own separate context that shares a common MPEG-2 TS (i.e., it uses the same PID value) 💅
MPEG-2 Receivers may use a Network Point of Attachment (NPA) [RFC4259] to uniquely identify an L2 node within an MPEG-2 transmission network. An example of an NPA is the IEEE Medium Access Control (MAC) address. When these addresses are used, they must also be signalled by the AR procedure. Finally, address resolution could signal the format of the data being sent, such as the encapsulation, along with any L2 encryption method and any compression scheme [RFC4259] 🌈
The number of Receivers on a single MPEG-2 link can be much larger than what you'd see in other common LAN technologies (e.g., Ethernet). That has implications for how the address resolution mechanisms get designed and configured 🌸 Current routing protocols and some multicast application protocols also don't scale to arbitrarily large numbers of participants 😭 These networks don't add much subnetwork round trip delay on their own. However, many practical MPEG-2 transmission networks are built from links that can add a significant path delay, like satellite links, dial-up modem return, cellular return, and so on 🛰️ That higher delay may need to be handled by the address resolution protocols that use this service, so keep that in mind, bestie ⭐
1.1. Bridging and Routing ✨
okay so this bit is where we get to see AR (address resolution) actually in action 🦋 there are two pictures, one for a routed setup and one for a bridged one. ngl they look intimidating but they're giving very clear vibes once you read the words around them 💅 and yes, other mixes of L2 and L3 forwarding can run over MPEG-2 links too, like when the Receivers are IP end hosts or end hosts plugged straight into bridged LAN segments 🌸
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|Figure 1: A routed MPEG-2 link
so Figure 1 is a routed MPEG-2 link feeding three downstream routers, R2 through R4 🧚 AR happens at the Encapsulator (R1), and its whole job is to figure out each Receiver at Layer 2 inside the IP subnetwork (R2, etc.) 💖
when R1 wants to unicast to R2, there are a few L2 addresses floating around:
1ais the L2 (sending) interface address of R1 on the MPEG-2 link.2bis the L2 (receiving) interface address of R2 on the MPEG-2 link.2ais the L2 (sending) interface address of R2 on the next hop link.
AR on the MPEG-2 link lets R1 work out the L2 address (2b) that goes with the next hop Receiver, which is router R2 🫶
now Figure 2 is the bridged version: one MPEG-2 link feeding three downstream bridges, B2 through B4 🍓 AR happens at the Encapsulator (B1) to pin down each Receiver at L2 (B2-B4). AR also happens across the IP subnetwork, so the Feed router (R1) can find the downstream Routers at Layer 2 (R2, etc.). the Encapsulator attaches a destination MAC/NPA address to every bridged PDU it sends on an MPEG-2 link. ULE (Unidirectional Lightweight Encapsulation) [RFC4326] defines two methods for this, and the first one is the simplest:
the simplest method just uses the L2 address of the transmitted frame 🌈 that's the MAC address for the destination inside the L2 subnetwork, which is the next hop router (2b of R2). the catch is that each Receiver (B2-B4) has to link the receiving MPEG-2 interface with the set of MAC addresses on the L2 subnetworks it feeds 🙈 similar stuff applies when IP-based tunnels carry L2 services, including when you use UDLR (Unidirectional Links) [RFC3077].
the second method is for a bridging Encapsulator (B1) to wrap a PDU in a link-specific header that also holds the MAC/NPA address tied to a Receiver's L2 interface on the MPEG-2 link (Figure 2). in that case the destination MAC/NPA address of the encapsulated frame is set to the Receiver's MAC/NPA address (y), not the address of the final L2 destination ✨ there's also a separate AR binding needed so R1 can link the destination L2 address 2b with R2. in a bridged subnetwork, R1 and R2 will normally use standard IETF-defined AR mechanisms (for example, IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP subnetwork 👑
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|Figure 2: A bridged MPEG-2 link
there are also ways to hand out IP addresses to Receivers inside a network 🎀 think stateless autoconfiguration [RFC2461], DHCP [RFC2131], DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]. Receivers can even help remotely configure the L3 IP addresses on equipment connected to them, for example using DHCP-Relay [RFC3046] 🦋
the rest of this doc covers the current mechanisms and how to use them to link an IP address with the matching TS Multiplex, PID value, MAC/NPA address and/or Platform ID 🌸 it looks at a bunch of approaches, including Layer 2 mechanisms that use MPEG-2 SI tables, plus IP-level protocols like ARP [RFC826] and ND [RFC2461]. it also explains how these mechanisms and the encapsulation methods depend on and interact with each other. and to be clear, the document doesn't propose or define a new protocol 🙌 what it does do is give guidance on the things you'd need to think about if you wanted to supply IP-based address resolution 💜
2. Conventions Used in This Document ✨
Okay bestie, this is the glossary, and it's basically the name-tag section 🎀 Every acronym gets introduced here so nobody gets lost later 💅
AIT: The Application Information Table, specified by the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. This table may carry IPv4/IPv6 to MPEG-2 TS address resolution information. 🌸
ATSC: The Advanced Television Systems Committee [ATSC]. It's a framework plus a set of associated standards for sending video, audio, and data using the ISO MPEG-2 standard [ISO-MPEG2]. Iconic 📺
b: bit. Like, one byte is 8-bits 🧚
B: Byte. Groups of bytes are represented in Internet byte order 🫶
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. It's a format for sending data and control information carried in an MPEG-2 Private Section, as defined by the ISO MPEG-2 standard 💜
DVB: Digital Video Broadcasting [DVB]. It's a framework and a set of associated standards published by the European Telecommunications Standards Institute (ETSI) for sending video, audio, and data using the ISO MPEG-2 Standard. The way this one is everywhere in Europe 🌈
DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bidirectional IPv4/IPv6 service that uses low-cost Receivers [ETSI-RCS]. Lowkey the return path bestie we needed ✨
DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS] 🛰️
Encapsulator: A network device that receives PDUs and formats them into Payload Units (known here as SNDUs) for output as a stream of TS Packets. It's the packer 📦
Feed Router: The router that delivers the IP service over a Unidirectional Link 🦋
INT: Internet/MAC Notification Table. It's a unidirectional address resolution mechanism that uses SI and/or PSI Tables 🌸
L2: Layer 2, the link layer.
L3: Layer 3, the IP network layer.
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2). Okay so this is the classic one 🔥
MAC Address: A 6-byte link layer address in the format described by the Ethernet IEEE 802 standard (see also NPA). 💖
MAC Header: The link layer header from the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2. It's made up of a 6-byte destination address, a 6-byte source address, and a 2 byte type field (see also NPA, LLC (Logical Link Control)). Main character header energy 👑
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia Receiver that may (in some cases) support IPv4/IPv6 services [ETSI-MHP]. 🎀
MMT: Multicast Mapping Table. It's a proprietary extension to DVB-RCS [ETSI-RCS] that defines an AR table mapping IPv4 multicast addresses to PID values. Not standard, but very iconic 🙈
MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90]. A method that encapsulates PDUs into a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single Stream (TS Logical Channel) 🧚
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), standardized by the International Standards Organization (ISO/IEC 113818-1) [ISO-MPEG2], and by ITU-T (in H.220). The OG standard family 🎬
NPA: Network Point of Attachment. A 6-byte destination address (which looks a lot like an IEEE MAC address) within the MPEG-2 transmission network. It's used to identify individual Receivers or groups of Receivers [RFC4259]. 🦋
PAT: Program Association Table. An MPEG-2 PSI control table. It associates each program with the PID value used to send the associated PMT (Program Map Table). The table is sent using the well-known PID value of 0x000, and it is required for an MPEG-2 compliant Transport Stream. Non-negotiable 💅
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets. 📨
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the header of each TS Packet. It identifies the TS Logical Channel that a TS Packet belongs to [ISO-MPEG2]. The TS Packets that form the parts of a Table Section, or of another Payload Unit, must all carry the same PID value. A PID value of all ones marks a Null TS Packet, which is introduced to keep a constant bit rate for a TS Multiplex. There's no required relationship between the PID values used for TS Logical Channels sent over different TS Multiplexes. 🔥
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/Streams that make up a program [ISO-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT. 🌈
Private Section: A syntactic structure built according to Table 2-30 of [ISO-MPEG2]. It can be used to identify private information (i.e., information not defined by [ISO-MPEG2]) related to one or more elementary streams, a specific MPEG-2 program, or the entire Transport Stream. Other standards bodies, such as ETSI and ATSC, have defined sets of table structures using the private_section structure. A Private Section is sent as a sequence of TS Packets over a TS Logical Channel, and one TS Logical Channel may carry sections from more than one set of tables. 🫶
PSI: Program Specific Information [ISO-MPEG2]. PSI conveys information about the services carried in a TS Multiplex. It's carried in one of four specifically identified Table Section constructs [ISO-MPEG2]. See also SI Table. 🌸
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or to the bridging module when operating at the link layer). The gatekeeper 🚪
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that has been defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections, but all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2]. 💜
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit. 📦
Table Section: A Payload Unit carrying all or part of an SI or PSI Table [ISO-MPEG2]. 🎀
TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level that uses TS Packets. It represents Layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex. 🦋
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value, and that value is unique within a specific TS Multiplex. The term "Stream" is defined in MPEG-2 [ISO-MPEG2] and describes the content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved by MPEG-2 for specific signaling, and other standards (e.g., ATSC and DVB) also reserve specific PID values. 🧚
TS Multiplex: In this document, this term means a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. That connection may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly with a different PID value) [RFC4259]. For example, it might be used to redistribute the same multicast content to two terrestrial TV transmission cells. 📡
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header. Small but mighty 💖
UDL: Unidirectional link: a one-way transmission link. For example, an IP over DVB link using a broadcast satellite link. 🛰️
ULE: Unidirectional Lightweight Encapsulation. A scheme that encapsulates PDUs into SNDUs, which are sent in a series of TS Packets using a single TS Logical Channel [RFC4326]. 🌈
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by a stream_type definition in SI/PSI [RFC4326, ISO-MPEG2]. ✨
3. Address Resolution Requirements ✨
Okay bestie, so the MPEG IP address resolution process doesn't care which encapsulation you pick 💅 It has to support a whole set of IP over MPEG-2 formats, including Multi-Protocol Encapsulation (MPE) ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional Lightweight Encapsulation (ULE) [RFC4326].
The general IP over MPEG-2 AR requirements are basically a checklist 🎀
- A scalable architecture that may support large numbers of systems within the MPEG-2 Network [RFC4259].
- A protocol version, to indicate the specific AR protocol in use and which may include the supported encapsulation method.
- A method (e.g., well-known L2/L3 address/addresses) to identify the AR Server sourcing the AR information.
- A method to represent IPv4/IPv6 AR information (including security mechanisms to authenticate the AR information to protect against address masquerading [RFC3756]).
- A method to install AR information associated with clients at the AR Server (registration).
- A method for transmission of AR information from an AR Server to clients that minimize the transmission cost (link-local multicast is preferable to subnet broadcast).
- Incremental update of the AR information held by clients.
- Procedures for purging clients of stale AR information.
An MPEG-2 transmission network may support multiple IP networks 🌈 If that's the case, it's super important to recognize the scope where an address gets resolved, so packets from one addressed scope don't leak into other scopes [RFC4259]. Overlapping IP address assignments can show up in a few main ways:
- (i) Private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; and 192.168/16 prefix). Packets with these addresses should be confined to one addressed area. IPv6 also defines link-local addresses that must not be forwarded beyond the link on which they were first sent.
- (ii) Local scope multicast addresses. These are only valid within the local area (examples for IPv4 include: 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses [RFC2375].
- (iii) Scoped multicast addresses [RFC2365] and [RFC2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid within an addressed area (e.g., the 239/8 [RFC2365]).
Overlapping address assignments can also happen at L2, where the same MAC/NPA address is used to identify multiple Receivers [RFC4259] 👀
- (i) A MAC/NPA unicast address must be unique within the addressed area. The IEEE-assigned MAC addresses used in Ethernet LANs are globally unique. If the addresses are not globally unique, an address must only be re-used by Receivers in different addressed (scoped) areas.
- (ii) The MAC/NPA address broadcast address (a L2 address of all ones). Traffic with this address should be confined to one addressed area.
- (iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (Sections 3.2 and 5.6).
Reception of unicast packets destined for another addressed area will increase the rate of received packets for systems connected via the network 😭 That extra traffic may add to processing load, but it should not lead to unexpected protocol behaviour, as long as systems can be uniquely addressed at L2. It does however open up a potential Denial of Service (DoS) opportunity 💀 When the Receiver operates as an IP router, receiving such a packet can lead to unexpected protocol behaviour.
3.1. Unicast Support
Unicast address resolution is required at two levels 🦋
At the lower level, the IP (or MAC) address needs to be associated with a specific TS Logical Channel (PID value) and the corresponding TS Multiplex (Section 4). Each Encapsulator within an MPEG-2 Network is associated with a set of unique TS Logical Channels (PID values) that it sources [ETSI-DAT, RFC4259]. Within a specific scope, the same unicast IP address may therefore be associated with more than one Stream, and each Stream contributes different content (e.g., when several different IP Encapsulators contribute IP flows destined to the same Receiver). MPEG-2 Networks may also replicate IP packets to send the same content (Simulcast) to different Receivers or via different TS Multiplexes. The configuration of the MPEG-2 Network must prevent a Receiver from accepting duplicated copies of the same IP packet 🙈
At the upper level, the AR procedure needs to associate an IP address with a specific MAC/NPA address (Section 5).
3.2. Multicast Support
Multicast is a big deal for MPEG-2 transmission networks 🔥 since it makes the most of native support for link broadcast. Multicast address resolution happens at the network level, associating a specific L2 address with an IP Group Destination Address (Section 5.6). In IPv4 and IPv6 over Ethernet, this association is normally a direct mapping, and this is the default method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].
Address resolution must also happen at the MPEG-2 level (Section 4). The goal of this multicast address resolution is to let a Receiver associate an IPv4 or IPv6 multicast address with a specific TS Logical Channel and the corresponding TS Multiplex [RFC4259]. This association needs to permit a large number of active multicast groups, and it should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets (e.g., by distributing the multicast traffic over a number of TS Logical Channels). Schemes that allow hardware filtering can be beneficial, since they may relieve the drivers and operating systems from discarding unwanted multicast traffic 🧚
There are two specific functions required for address resolution in IP multicast over MPEG-2 Networks ✨
- (i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
- (ii) Provide signalling information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
Methods are required to identify the scope of an address when an MPEG-2 Network supports several logical IP networks and carries groups within different multicast scopes [RFC4259].
Appropriate procedures need to specify the correct action when the same multicast group is available on separate TS Logical Channels. This could happen when different Encapsulators contribute IP packets with the same IP Group Destination Address in the ASM (Any-Source Multicast) address range. Another case is when a Receiver could receive more than one copy of the same packet (e.g., when packets are replicated across different TS Logical Channels or even different TS Multiplexes, a method known as Simulcasting [ETSI-DAT]). At the IP level, the host/router may be unaware of this duplication, so it needs to be detected by other means 🕵️♀️
When the MPEG-2 Network is peered to the multicast-enabled Internet, an arbitrarily large number of IP multicast group destination addresses may be in use, and the set forwarded on the transmission network may be expected to vary significantly with time 🌸 Some uses of IP multicast employ a range of addresses to support a single application (e.g., ND [RFC2461], Layered Coding Transport (LCT) [RFC3451], and Wave and Equation Based Rate Control (WEBRC) [RFC3738]). The current set of active addresses may be determined dynamically via a multicast group membership protocol (e.g., Internet Group Management Protocol (IGMP) [RFC3376] and Multicast Listener Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol Independent Multicast (PIM) [RFC4601]) and/or other means (e.g., [RFC3819] and [RFC4605]). However, each active address requires a binding by the AR method. Therefore, there are advantages in using a method that does not need to explicitly advertise an AR binding for each IP traffic flow, but is able to distribute traffic across a number of L2 TS Logical Channels (e.g., using a hash/mapping that resembles the mapping from IP addresses to MAC addresses [RFC1112, RFC2464]). Such methods can reduce the volume of AR information that needs to be distributed, and reduce the AR processing 🙌
Section 5.6 describes the binding of IP multicast addresses to MAC/NPA addresses.
4. MPEG-2 Address Resolution 🎀
The first part of this section describes the role of MPEG-2 signalling in identifying streams (TS Logical Channels [RFC4259]) within the L2 infrastructure.
At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the existence and format of a Stream, using a combination of two PSI tables: the Program Association Table (PAT) and entries in the program element loop of a Program Map Table (PMT). PMT Tables are sent infrequently and are typically small in size. The PAT is sent using the well-known PID value of 0X000. This table provides the correspondence between a program_number and a PID value. (The program_number is the numeric label associated with a program.) Each program in the Table is associated with a specific PID value, used to identify a TS Logical Channel (i.e., a TS). The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the program. This approach de-references the PID values when the MPEG-2 Network includes multiplexors or re-multiplexors that renumber the PID values of the TS Logical Channels that they process 🧠
In addition to signalling the Receiver with the PID value assigned to a Stream, PMT entries indicate the presence of Streams using ULE and MPE to the variety of devices that may operate in the MPEG-2 transmission network (multiplexors, remultiplexors, rate shapers, advertisement insertion equipment, etc.) 💅
A multiplexor or remultiplexor may change the PID values associated with a Stream during the multiplexing process, with the new value reflected in an updated PMT. TS Packets that carry a PID value that is not associated with a PMT entry (an orphan PID) may, and usually will, be dropped by ISO 13818-1 compliant L2 equipment, which means the Stream is not forwarded across the transmission network 😭 In networks that do not employ any intermediate devices (e.g., scenarios C,E,F of [RFC4259]), or where devices have other means to determine the set of PID values in use, the PMT table may still be sent (but it is not required for this purpose).
Although the basic PMT information may be used to identify the existence of IP traffic, it does not associate a Stream with an IP prefix/address. The remainder of the section describes IP address resolution mechanisms relating to MPEG-2 ✨
4.1. Static Configuration ✨
okay bestie, static configuration is basically the "out-of-band" option 🧚 The static mapping option is where IP addresses or flows get statically mapped to specific PIDs. The application programmer, the installing engineer, or the user gets that mapping through some outside means, not in the MPEG-2 TS 🎀 It's giving testing, experimental networks, small subnetworks, and closed domains, so it's super useful there 🦋
so picture a pre-defined set of IP addresses being used within an MPEG-2 transmission network 🌸 If you already know which addresses are active, you can build appropriate AR records for each one and pre-assign the matching PID value. You might do that to optimize Receiver processing, group related addresses onto the same PID value, and/or follow a policy for using specific ranges of PID values 💜 Just know this assumes the PID mappings are not modified during transmission (Section 4) ✨
a single "well-known" PID is a specialized version of this 👑 Current DOCSIS cable modems [DOCSIS] use this scheme, where all IP traffic is placed into the specified TS stream. MAC filtering (and/or Section filtering in MPE) may be used to differentiate subnetworks 🙈
4.1.1. MPEG-2 Cable Networks 🍓
Cable networks use a different transmission scheme for downstream (head-end to cable modem) and upstream (cable modem to head-end) transmissions 🌈
IP/Ethernet packets get sent downstream to the cable modem(s), encapsulated in MPEG-2 TS Packets sent on a single well-known TS Logical Channel (PID) 💅 There is no use of in-band signalling tables. Upstream, the common approach is to use Ethernet framing, rather than IP/Ethernet over MPEG-2, although other proprietary schemes also continue to be used 🫶
until the deployment of DOCSIS and EuroDOCSIS, most address resolution schemes for IP traffic in cable networks were proprietary, and they didn't usually employ a table-based address resolution method 😭 Proprietary methods still get used in some cases where cable modems require interaction. In this case, equipment at the head-end may act as gateways between the cable modem and the Internet. These gateways receive L2 information and allocate an IP address ✨
DOCSIS uses DHCP for IP client configuration. The Cable Modem Terminal System (CMTS) provides a DHCP Server that allocates IP addresses to DOCSIS cable modems. The MPEG-2 transmission network provides a L2 bridged network to the cable modem (Section 1). This usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and [RFC3256]. Issues in deployment of IPv6 are described in [RFC4779] 🦋
4.2. MPEG-2 Table-Based Address Resolution 📋
the information about the set of MPEG-2 Transport Streams carried over a TS Multiplex can be distributed via SI/PSI Tables 💖 These tables are usually sent periodically (Section 4). This design requires access to and processing of the SI Table information by each Receiver [ETSI-SI], [ETSI-SI1]. It reflects the complexity of delivering and coordinating the various Transport Streams associated with multimedia TV 📺 A TS Multiplex may provide AR information for IP services by integrating additional information into the existing control tables, or by transmitting additional SI Tables that are specific to the IP service 🌸
examples of MPEG-2 Table usage that let an MPEG-2 Receiver identify the appropriate PID and the multiplex associated with a specific IP address include:
- (i) IP/MAC Notification Table (INT) in the DVB Data standard [ETSI-DAT]. This provides unidirectional address resolution of IPv4/IPv6 multicast addresses to an MPEG-2 TS.
- (ii) Application Information Table (AIT) in the Multimedia Home Platform (MHP) specifications [ETSI-MHP].
- (iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by some DVB-RCS systems to provide unidirectional address resolution of IPv4 multicast addresses to an MPEG-2 TS.
the MMT and AIT are used for specific applications, whereas the INT [ETSI-DAT] is a more general DVB method 👑 It supports MAC, IPv4, and IPv6 AR when used in combination with the other MPEG-2 tables (Section 4) 💜
4.2.1. IP/MAC Notification Table (INT) and Its Usage 🧚
The INT provides a set of descriptors to specify addressing in a DVB network. The use of this method is specified for Multiprotocol Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying information about the location of IP/L2 flows within a DVB network 🌈 A Platform_ID identifies the addressing scope for a set of IP/L2 streams and/or Receivers. A Platform may span several Transport Streams carried by one or multiple TS Multiplexes, and it represents a single IP network with a harmonized address space (scope). This allows for the coexistence of several independent IP/MAC address scopes within an MPEG-2 Network 🫶
The INT allows both fully-specified IP addresses and prefix matching to reduce the size of the table (and hence enhance signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified in full form or by using a slash notation (e.g., /127). IP multicast addresses can be specified with or without a source (address or range), although if a source address is specified, then only the slash notation may be used for prefixes 🍓
In addition, for identification and security descriptors, the following descriptors are defined for address binding in INT tables:
- (i)
target_MAC_address_descriptor: A descriptor to describe a single or set of MAC addresses (and their mask). - (ii)
target_MAC_address_range_descriptor: A descriptor that may be used to set filters. - (iii)
target_IP_address_descriptor: A descriptor describing a single or set of IPv4 unicast or multicast addresses (and their mask). - (iv)
target_IP_slash_descriptor: Allows definition and announcement of an IPv4 prefix. - (v)
target_IP_source_slash_descriptor: Uses source and destination addresses to target a single or set of systems. - (vi)
IP/MAC stream_location_descriptor: A descriptor that locates an IP/MAC stream in a DVB network.
The following descriptors provide corresponding functions for IPv6 addresses:
target_IPv6_address_descriptor
target_IPv6_slash_descriptor
and target_IPv6_source_slash_descriptorThe ISP_access_mode_descriptor allows specification of a second address descriptor to access an ISP via an alternative non-DVB (possibly non-IP) network 🌸
One key benefit is that the approach employs MPEG-2 signalling (Section 4) and is integrated with other signalling information. This allows the INT to operate in the presence of (re)multiplexors [RFC4259] and to refer to PID values that are carried in different TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario [RFC4259] 🎀
The principal drawback is a need for an Encapsulator to introduce associated PSI/SI MPEG-2 control information. This control information needs to be processed at a Receiver, and that requires access to information below the IP layer 😬 The position of this processing within the protocol stack makes it hard to associate the results with IP Policy, management, and security functions. The use of centralized management prevents the implementation of a more dynamic scheme 💀
4.2.2. Multicast Mapping Table (MMT) and Its Usage 🦋
In DVB-RCS, unicast AR is seen as a part of a wider configuration and control function, and it does not employ a specific protocol ✨
A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control table that associates a set of multicast addresses with the corresponding PID values [MMT]. This table allows a DVB-RCS Forward Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 multicast addresses to PID values within a specific TS Multiplex. Receivers (DVB-RCS Return Channel Satellite Terminals (RCSTs)) may use this table to determine the PID values associated with an IP multicast flow that they require to receive. The MMT is specified by the SatLabs Forum [MMT] and is not currently a part of the DVB-RCS specification 💜
4.2.3. Application Information Table (AIT) and Its Usage 📱
The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does not define a specific AR function. However, an Application Information Table (AIT) is defined that allows MHP Receivers to receive a variety of control information 🌈 The AIT uses an MPEG-2 signalling table, providing information about data broadcasts, the required activation state of applications carried by a broadcast stream, etc. This information allows a broadcaster to request that a Receiver change the activation state of an application, and to direct applications to receive specific multicast packet flows (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a specific function, but as a part of a wider configuration and control function 🫶
4.2.4. Address Resolution in ATSC 📡
ATSC [ATSC-A54A] defines a system that allows transmission of IP packets within an MPEG-2 Network. An MPEG-2 Program (defined by the PMT) may contain one or more applications [ATSC-A90] that include IP multicast streams [ATSC-A92]. IP multicast data are signalled in the PMT using a stream_type indicator of value 0x0D. A MAC address list descriptor [SCTE-1] may also be included in the PMT 💖
The approach focuses on applications that serve the transmission network. A method is defined that uses MPEG-2 SI Tables to bind the IP multicast media streams and the corresponding Session Description Protocol (SDP) announcement streams to particular MPEG-2 Program Elements. Each application constitutes an independent network, and the MPEG-2 Network boundaries establish the IP addressing scope 🌸
4.2.5. Comparison of SI/PSI Table Approaches 🏆
The MPEG-2 methods based on SI/PSI meet the specified requirements of the groups that created them, and each has its strengths: the INT in terms of flexibility and extensibility, the MMT in its simplicity, and the AIT in its extensibility 🌟 However, they exhibit scalability constraints, represent technology specific solutions, and do not fully adopt IP-centric approaches that would enable easier use of the MPEG-2 bearer as a link technology within the wider Internet 🥺
4.3. IP-Based Address Resolution for TS Logical Channels ✨
okay so bestie, MPEG-2 Networks are glowing up into multi-service networks 🌈, and IP is everywhere now. Most of them already use IP for operations, control, and data delivery 💅. Address resolution info could ride over IP transport too, but ngl, there's no standards-based IP-level AR protocol that supports the MPEG-2 TS yet 💀. Lowkey a gap, highkey an opportunity 🦋.
The opportunity is an IP-level method that uses an IP multicast protocol on a well-known IP multicast address to resolve an IP address to a TS Logical Channel (i.e., a Transport Stream) 🧚. The perks of IP-based address resolution are:
- Simplicity: The AR mechanism does not require interpretation of L2 tables 🎀. This is a big deal especially as home networks and audio/video networked entities keep growing their market share 📺.
- Uniformity: An IP-based protocol can provide a common method across different network scenarios 🌸. It covers both IP to MAC address mappings and mappings to TS Logical Channels (the PID value associated with a Stream) 💜.
- Extensibility: IP-based AR mechanisms can evolve independently of the rest of the stack ✨. That includes dynamic methods to request address resolution, plus the ability to carry other L2 information (e.g., encryption keys) 🔑.
- Integration: The info exchanged by IP-based AR protocols can slot right into the IP network layer 👑. That makes it easier to support AAA, policy, Operations and Management (OAM), mobility, configuration control, etc., which combine AR with security 🫶.
But it's not all rainbows, okay? The drawbacks of an IP-based method are:
- It can not operate over an MPEG-2 Network that uses MPEG-2 remultiplexors [RFC4259] that modify the PID values associated with the TS Logical Channels during the multiplexing operation (Section 4) 😭. That makes the method unsuitable for use in deployed broadcast TV networks [RFC4259] 💀.
- IP-based methods can introduce concerns about the integrity of the information and authentication of the sender [RFC4259] 🙈. (These concerns also apply to MPEG-2 Table methods, but there the information is confined to the L2 network, or to parts of the network where gateway devices isolate the MPEG-2 devices from the larger Internet, creating virtual MPEG-2 private networks 🏰.) So IP-based solutions should implement security mechanisms that may be used to authenticate the sender and verify the integrity of the AR information, as a part of a larger security framework 🔐.
An IP-level method could use an IP multicast protocol running an AR Server (see also Section 5.4) on a well-known (or discovered) IP multicast address 🌟. To hit the scalability goal for networks with a large number of systems (Section 1), a single packet needs to carry multiple AR records and define the intended scope for each address 📦. Methods that use prefix matching are desirable, e.g., where a range of source/destination addresses is matched to a single entry 🍓. It can also be beneficial to use methods that let a range of IP addresses map to a set of TS Logical Channels, e.g., a hashing technique similar to the mapping of IP Group Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464] 🧮.
5. Mapping IP Addresses to MAC/NPA Addresses 💖
this section looks at the IETF protocols that can be used to assign and manage the mapping of IP addresses to/from MAC/NPA addresses over MPEG-2 Networks 🗺️.
An IP Encapsulator needs AR info to pick the right MAC/NPA address in the SNDU header [RFC4259] (Section 6) 🎯. That info might come straight from a neighbor/ARP cache, or the Encapsulator might have to fetch it with an AR protocol 🔍. How this info gets collected depends on whether the Encapsulator works as a Router (at L3) or a Bridge (at L2) (Section 1.1) 🌉.
Two IETF-defined protocols map IP addresses to MAC/NPA addresses: the Address Resolution Protocol, ARP [RFC826], and the Neighbor Discovery protocol, ND [RFC2461], for IPv4 and IPv6 respectively 🧩. Both are normally used in a bidirectional mode, although both also allow unsolicited transmission of mappings 🔁. The IPv6 mapping defined in [RFC2464] can end up with a large number of active MAC multicast addresses (e.g., one for each end host) 😵💫.
ARP needs support for L2 broadcast packets 📢. A large number of Receivers can mean a proportional jump in ARP traffic, which is a real concern for bandwidth-limited networks 📉. Transmission delay can also hurt protocol performance 🐢.
ARP also has a number of security vulnerabilities 🚨. In ARP spoofing, a system gets fooled by a rogue device that sends a fictitious ARP RESPONSE containing the IP address of a legitimate network system and the MAC of a rogue system 👀. Legitimate systems on the network then update their ARP tables with the false mapping and send future packets to the rogue system instead of the legitimate one 😱. With this trick, 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, so only legitimate ARP RESPONSEs get used to update ARP tables ✅. SARP requires installing software at each client 💻. It suffers from the same scalability issues as standard ARP 🥲.
The ND protocol uses a set of IP multicast addresses 🎶. In large networks, many multicast addresses are in use, but each client usually only listens to a restricted set of group destination addresses, and little traffic is sent in each group 🤏. So Layer 2 AR for MPEG-2 Networks has to support this in a scalable manner 📈.
A large number of ND messages can cause a big demand for asymmetric operations 😤. The base ND protocol limits the rate at which multicast responses to solicitations can be sent 🚦. Configurations may need tuning when operating with large numbers of Receivers 🛠️.
The default parameters in the ND protocol [RFC2461] can cause interoperability problems (e.g., a failure to resolve when the link RTT (round-trip time) exceeds 3 seconds) and performance degradation (duplicate ND messages with a link RTT > 1 second) when used in networks where the link RTT is much larger than on Ethernet LANs 🐌. So tuning the protocol parameters (e.g., RTR_SOLICITATION_INTERVAL) is recommended when using network links with noticeable 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 📉. On top of that, SEND doesn't require configuring per-host keys, and it can coexist with both SEND and insecure ND on the same link 🤝.
The ND Protocol is also used by IPv6 systems for 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 isn't required 🙌.
5.1. Unidirectional Links Supporting Unidirectional Connectivity
MPEG-2 Networks may provide a Unidirectional Broadcast Link (UDL) with no return path 📡. These links may be used for unicast applications that don't need a return path (e.g., ones based on UDP), but they're commonly 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 connectivityThe ARP and ND protocols require bidirectional L2/L3 connectivity 🔄. They don't provide an appropriate way to resolve the remote (destination) address in a unidirectional environment 🙅♀️.
So unidirectional links need a separate out-of-band configuration method to set up the right AR info at the Encapsulator and Receivers 🗝️. ULE [RFC4326] defines a mode in which the MAC/NPA address is left out of the SNDU 🪄. In some scenarios, this may spare an Encapsulator from needing L2 AR at all 💜.
5.2. Unidirectional Links with Bidirectional Connectivity 🦋
okay so bidirectional connectivity can totally be made using a unidirectional link paired with another network path 🌈 The usual combo is a Feed link over MPEG-2 satellite plus a return link over terrestrial network infrastructure. This setup is often called a Hybrid network, and it has asymmetric network routing. so chaotic but make it make sense 💅
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
Figure 4: Bidirectional connectivitybestie, the Unidirectional Link Routing (UDLR) [RFC3077] protocol can be used to deal with the issues that come with asymmetric routing 🫶 The Dynamic Tunnel Configuration Protocol (DTCP) handles automatic configuration of the return path ✨ UDLR hides the unidirectional routing from IP and the upper layer protocols by giving them an L2 tunnelling mechanism that acts like a bidirectional broadcast link at L2. 🎀 A network using UDLR has a topology where a Feed Router and all Receivers form one logical Local Area Network. Encapsulating L2 frames lets them be sent through an Internet Path (i.e., bridging). iconic, honestly 👑
ngl, a lot of unidirectional links use wireless tech for the forward (Feed) link, so forwarding traffic on the Feed link can cost a lot 😭 That makes it usually worth preventing the forwarding of unnecessary traffic (e.g., for multicast this means controlling which groups get forwarded) 🍓 Forwarding in the return direction matters too (e.g., asymmetric capacity and loss [RFC3449]). So the takeaway is that we need to keep the volume and frequency of control messages as low as possible 🧚
Three different AR cases can be identified. Each one looks at sending an IP packet to a next-hop IP address that the sender doesn't have cached right now 💜
(i) A Feed Router needs a Receiver MAC/NPA address.
This happens when a Feed Router sends an IP packet over the Feed UDL to a Receiver whose MAC/NPA address it doesn't know yet. 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). After that, the Feed Router may address IP packets to the unicast MAC/NPA address associated with the Receiver. The ULE encapsulation format also allows packets to be sent without specifying a MAC/NPA address, where that's desirable (Section 6.1 and 6.5). 🌸
(ii) A Receiver needs the Feed Router MAC/NPA address.
This happens 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 over 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 happens 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 mean that any system connected to the UDL can get the MAC/NPA address of any other system ✨ Similar exchanges can be done using the ND protocol for IPv6 💖
A long round trip delay (via the UDL and UDLR tunnel) affects how well the reactive address resolution procedures from ARP, ND, and SEND perform 😭 Unlike Ethernet, during the time resolution is happening, lots of IP packets might arrive that are addressed to the AR Target address. The ARP specification lets an interface discard these packets while it waits for the response to the resolution request. An appropriately sized buffer would, however, prevent that loss 🫶
In case (iii), the time to complete address resolution can be reduced by using an AR Server at the Feed (Section 5.4). 🧚
Using DHCP requires L2 connectivity to a DHCP Server to be set up first. The delay in getting return connectivity in UDLR networks that use DHCP might make it helpful to increase how often the DTCP HELLO message is sent. More information about tuning DHCP is in Section 5.5. 💅
5.3. Bidirectional Links 🎀
Bidirectional IP networks can be, and are, built by combining two MPEG-2 transmission links 🌸 One link is usually a broadcast link that feeds a set of remote Receivers. Links also run from the Receivers, so the combined link works as a full duplex interface. Two-way DVB-S satellite links and the DVB-RCS system are examples of this 🛰️✨
5.4. AR Server 🧚
An AR Server can be used to pass AR information out to Receivers in an MPEG-2 Network 💜 In some topologies, this can significantly cut down the time Receivers take to find AR information 💖
The AR Server can work as a proxy, answering on behalf of Receivers for AR requests it receives. When an IPv4 AR request comes in (e.g., a Receiver ARP REQUEST), the AR Server answers by (proxy) sending an AR response with the right IP to MAC/NPA binding (mapping the IP address to the L2 address) 🌈
The AR Server can also send information unsolicited, using multicast/broadcast, to update the ARP/neighbor cache at the Receivers without anyone asking first ⭐ This unsolicited method can help scaling in large networks. Scaling can get even better by sending a single broadcast/multicast AR message that binds multiple IP and MAC/NPA addresses. That cuts the network capacity used and makes client/server processing simpler in networks with lots of clients 👑
An AR Server can be built with IETF-defined protocols by setting up the subnetwork so that AR Requests from Receivers get intercepted instead of forwarded to the Feed/broadcast link 🦋 The intercepted messages go to an AR Server. The AR Server keeps a set of MAC/NPA address bindings. These can be configured, or they can be learned by watching the ARP messages sent by Receivers. Right now, IETF-defined protocols only allow one binding per message (i.e., there's no optimization to save L2 bandwidth) 😭
Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [RFC4389]. To do the AR Server job, the AR information also has to be cached. A caching AR proxy stores the system state inside a middle-box device. This looks a lot like a classic man-in-the-middle security attack, so interactions with SEND are described in [SP-ND]. 🙈
We need ways to clear out stale AR data from the cache 🧹 The cache's consistency also has to be considered when Receiver bindings can change (e.g., IP mobility, network topology changes, or intermittent Receiver connectivity). In these cases, using old (stale) information can send IP packets to an inappropriate L2 address, which causes packet loss 💀
Current IETF-defined methods provide bindings of IP addresses to MAC/NPA, but they don't let bindings include other L2 information that matters for MPEG-2 Networks. That means other methods are needed for this function (Section 4). AR Servers can also be built with non-IETF AR protocols to supply the AR information Receivers need 🫶
5.5. DHCP Tuning 💅
DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 Networks with bidirectional connectivity 🌸 DHCP has two parts: 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 allocating network addresses to systems ✨
The DHCP Servers and DHCP Clients should be configured with the local link round trip delay in mind (possibly including the extra delay from bridging, e.g., using UDLR) 🧚 A large number of clients can make it worth tuning the DHCP lease duration and the size of the address pool 🍓 The right timer values should be picked too: the DHCP message retransmission timeout, and the maximum delay a DHCP Server waits before deciding that the absence of an ICMP echo response means the relevant address is free 🔥
DHCP Clients may retransmit DHCP messages if they don't get a response 🙈 Some client implementations set a timeout for the DHCPDISCOVER message that is small (e.g., suited to Ethernet delay, rather than appropriate to an MPEG-2 Network). That leaves insufficient time for a DHCP Server to respond to a DHCPDISCOVER retransmission before the lease availability check (by an ICMP Echo Request) expires, which can lead to a potential address conflict 😭 This value may need to be tuned for MPEG-2 Networks 💜
5.6. IP Multicast AR 🦋
okay so Section 3.2 is where the multicast address resolution requirements live, and this section is the part that covers what the L3 address bindings look like when the destination network-layer address is an IP multicast Group Destination Address 💜
For MPE [ETSI-DAT], the MAC Address gets mapped from the IP multicast address, and that mapping is defined for IPv4 [RFC1112] and IPv6 [RFC2464]. (DVB-H, a variant of DVB, uses a modified MAC header [ETSI-DAT] 🎀)
For ULE [RFC4326], the L2 NPA address is optional, and it isn't necessarily needed when the Receiver can do efficient L3 multicast address filtering ✨ When it is present, the mapping is again based on the IP multicast address, for IPv4 [RFC1112] and IPv6 [RFC2464].
Here's the tea 🍵 The L2 group addressing method in [RFC1112] and [RFC2464] can end up with more than one IP destination address mapping to the same L2 address. With Source-Specific Multicast (SSM) [RFC3569], multicast groups are identified by the combination of the IP source and IP destination addresses, so senders can independently pick an IP group destination address that would map to the same L2 address if it got forwarded onto the same L2 link. That overlap at L2 can bump up the amount of traffic forwarded up to L3, where it then has to be filtered out 😭
These considerations are the same as for Ethernet LANs, and they may not be a big deal for Receivers that can do efficient L3 filtering 💅 Section 3 pointed out that an MPEG-2 Network may need to support multiple addressing scopes at the network and link layers. One fix is to separate the different groups into different Transport Streams (with signalling of IP to PID value mappings) 🧚 Another option is to use alternate MAC/NPA mappings instead of the ones defined in [RFC1112] and [RFC2464]. Those mappings do 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. A Receiver can send multicast/broadcast frames, which a Feed Router then forwards natively (using the topology in Figure 2), and they finally arrive at the Feed interface of the Receiver that sent them 🛸 This multicast forwarding skips the normal L3 Reverse Path Forwarding (RPF) check, the L2 spanning tree checks, the processing of the IP Time To Live (TTL) field, and the filtering of administratively scoped multicast addresses. So you really have to think carefully about multicast support 🙈 To avoid forwarding loops, RFC 3077 notes that a Receiver needs to be configured with appropriate filter rules so it discards packets that originate from an attached network and are later received over the Feed link.
When the encapsulation includes a MAC/NPA source address, re-broadcast packets can be filtered at the link layer, using a filter that discards L2 addresses that are local to the Receiver. In some situations, systems can send packets with an unknown (all-zero) MAC source address (for example, IGMP Proxy Queriers [RFC4605]), and then the source at L2 can't be determined at the Receiver. Those packets need to be silently discarded, which may stop the associated services from running on the Receiver 🥺
Some encapsulation formats also don't include a MAC/NPA source address (Table 1). So multicast packets may alternatively be discarded at the IP layer if their IP source address matches a local IP address (or address range) 💖 Systems can also send packets with an all-zero IP source address (for example, BOOTP (bootstrap protocol) [RFC951], DHCP [RFC2131] and ND [RFC2461]). When the source at L3 can't be determined at the Receiver, these packets need to be silently discarded. This may stop the associated services from running at a Receiver, such as taking part in IPv6 Duplicate Address Detection or running a DHCP server 💀
6. Link Layer Support 🌸
This section looks at link layer (L2) support for address resolution in MPEG-2 Networks, and it covers two issues: the code-point used at L2, and how efficient the encapsulation is for the transmission needed to support the AR method. The table below sums up the options for both MPE ([ETSI-DAT], [ATSC-A90]) and ULE [RFC4326] encapsulations 🍓
[RFC4840] describes issues and concerns that can come up when a link supports multiple encapsulations. In particular, it points out problems that show up when end hosts in the same IP network use different, incompatible encapsulation methods. So an Encapsulator must use only one method (for example, ULE or MPE) to support a single IP network (meaning a set of IPv4 systems sharing the same subnet broadcast address or the same IPv6 prefix) 👑 All Receivers in an IP network must receive all IP packets that use a broadcast address (directed to all systems in the IP network) or a local-scope multicast address (Section 3). Lots of IP-based protocols depend on these packets, including service discovery, IP AR, and routing protocols. Systems that miss these packets can run into connectivity failure or incorrect behaviour (for example, they may be unable to take part in IP-based discovery, configuration, routing, and announcement protocols) 😭 Consistent delivery can be ensured by sending link-local multicast or broadcast packets over the same Stream that's used for unicast packets directed to this network. A Receiver could use more than one L2 AR mechanism at the same time, which creates a potential conflict when the Receiver gets two different bindings for the same identifier. When multiple systems advertise AR bindings for the same identifiers (for example, Encapsulators), they must make sure the advertised information is consistent. Conflicts may also come up when L2 protocols duplicate the functions of IP-based AR mechanisms 🔥
In ULE, the bridging format may be used together with the normal mode to address packets to a Receiver (all ULE Receivers are required to implement both methods). Frames carrying IP packets that use the ULE Bridging mode, with a destination address matching the MAC address of the Receiver and an IP address matching 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 received with a source address that matches an address of the Receiver itself [802.1D]. They must also stop forwarding frames that were already sent on a connected network. So for each network interface, a Receiver must 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 rest 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 isn't present in the encapsulated frame. This mode can be used with both IPv4 and IPv6. When it's used, the Receiver is expected to do L3 filtering of packets based on their IP destination address [RFC4326]. This needs careful thought about the network topology when a Receiver is an IP router, or delivers data to an IP router (one simple case where this is allowed is connecting stub networks at a Receiver that have no connectivity to other networks) 🧠 Since there's no MAC/NPA address in the SNDU, ARP and the ND protocol aren't required for AR.
IPv6 systems can automatically configure their IPv6 network address based on 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 isn't being used to filter received SNDUs 🌸
Even when it isn't 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 doesn't provide a MAC source address, there are topologies (for example, Section 5.6.1) where a system can't tell apart DAD packets that it originally sent and that were re-broadcast, from ones that may have been sent by another system with the same L3 address 😱 So DAD can't be used with this encapsulation format in topologies where this L2 forwarding may happen 🚫
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]. Even though 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 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 doesn't provide a MAC source address, there are topologies (for example, Section 5.6.1) where a system can't tell apart DAD packets that it originally sent and that were re-broadcast, from ones that may have been sent by another system with the same L3 address 🙈 So DAD can't be used with this encapsulation format in topologies where this L2 forwarding may happen 🫶
6.3. MPE without LLC/SNAP Encapsulation 🌈
This is the default (and sometimes the only) mode specified by most MPE Encapsulators. MPE doesn't provide an EtherType field, so it can't support the Address Resolution Protocol (ARP) [RFC826] 🦋
IPv6 isn't supported in this encapsulation format, so it isn't appropriate to consider the ND protocol 💀
6.4. MPE with LLC/SNAP Encapsulation 🎀
okay so the LLC/SNAP flavour of MPE has an EtherType field, which means it may support ARP [RFC826] ✨ There is no specification that defines 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 the one 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 is allowed in ULE, no cap ✨ This SNDU format supplies both a source and destination MAC address and an 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, so don't expect one 🙈 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, as 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 📚
Okay, the reference list is where things get a little chaotic, bestie, so I've kept every entry exactly as written. 🫶
[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 🫶
Here are our two lovely authors and how to reach them, no cap. 💖
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.comFull Copyright Statement 💅
Okay, the legal bit, but make it cute. ✨ The IETF Trust owns the copyright here, and it's dated 2007. 🎀 This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 says, the authors keep all their rights. 🦋
The document and everything in it are provided AS IS, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any promise that using the information won't infringe anyone's rights, and any implied warranties of merchantability or fitness for a particular purpose. 💀
Intellectual Property 🔥
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) claimed to cover the technology in this document are valid, or how far they reach. It also doesn't say whether licenses for them are available, and it hasn't independently checked for any such rights. 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79. 🌈
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that have been offered, and the results of any attempt to get a general license or permission for implementers or users. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr. 🧚
The IETF also invites anyone to flag any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org. 👑
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're iconic. ⭐
📦 where this page comes from
- ietf: rfc4947 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms