RFC 3422
Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)
RFC 3422: Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) 🦋
okay bestie, let's get into this one 💅 It's from the Network Working Group, dated November 2002, and it's Informational category, so it's not a standards track thing 🌸 The authors are O. Okamoto and M. Maruyama from NTT Laboratories, plus T. Sajima from Sun Microsystems ✨ The title block doesn't list anything it obsoletes or updates.
Status of this Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💖
Copyright Notice 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved.
IESG Note 🙈
this memo is about tunneling Ethernet frames over MAPOS networks 🫶 It is NOT the product of an IETF working group, and it's not a standards track document either. It hasn't necessarily gotten the big, in-depth community review that standards track docs get, so keep that in mind 😭
Abstract 🌈
this memo explains a way to forward media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS). The payoff is that it lets the MAPOS network and MAC-based Local Area Network (LAN) environments work together as one unified thing 🔥
1. Network Model ✨
so in the network model this memo assumes, MAC-based LAN traffic gets forwarded by a MAPOS switched network 🧚 This means distant LANs can be connected to form a single LAN segment, which is giving total main character energy. Transparent LAN Service (TLS) happens by wrapping MAC frames inside MAPOS frames and by mapping MAC addresses to MAPOS addresses 💜
The "MAPOS network" is made of MAPOS switches, SONET/SDH leased lines and optical fiber cables 🦋 A LAN hooks up to a MAPOS network through a Network Adapter (NA), which has a MAPOS interface and an ethernet interface. Each NA gets its own unique MAPOS address, assigned by NSP (Node-Switch Protocol) [2] 🌸
Here's the model in figure 1, bestie 👑
+-----------+
MAC-based LAN N1 +---+ | MAPOS | +---+ MAC-based LAN N2
---------------| |----| network |----| |---------------
| +---+ | | +---+ |
+-----+ Network | N0 | Network +-----+
| | adapter +-----------+ adapter | |
+-----+ B1 B2 +-----+
Host H1 Host H2
Figure 1. VPN network service model with LANs N1 and N2Host H1 in LAN N1 and host H2 in LAN N2 are on separate MAC-based LANs 🥹 The transparent LAN service works because MAPOS network N0 swaps MAC frames between Host H1 and Host H2 🫶
Using this setup, you can build a single VLAN segment out of multiple LANs that might be geographically really far apart from each other 🌍✨
The memo says a switched technology is recommended for building a MAC-based LAN 💅 Sometimes, though, it becomes a requirement 🔥 A likely example is a MAC-based LAN with two network adapters, both attached to the same MAPOS network, for redundancy 🎀 If that LAN is built with shared (non-switched) technology, this loop setup is bound to get stormed by incessant broadcast traffic 😭 The only way around it is switched technology that supports broadcast spanning tree [7] 🙈
2. Forwarding a MAC Frame 🧚
this section covers the MAC frame forwarding mechanism in the MAPOS network 🌸
2.1. Outline 💖
In figure 2, LANs N1 and N2 communicate through MAPOS network N0 ✨ NAs B1 and B2 are the gateways into Network N0, and each one has a MAPOS interface and an ethernet interface 🦋
+------------+
|MAPOS header|
+-----------+ +------------+ +-----------+
| MAC header| encapsulate | MAC header| decapsulate | MAC header|
+-----------+ ----------> +------------+ ----------> +-----------+
|information| | information| |information|
+-----------+ +------------+ +-----------+
MAC frame Bridged MAPOS frame MAC frame
+------------+
LAN N1 +---+ | MAPOS | +---+ LAN N2
---------------| |----| network |----| |---------------
| +---+ | | +---+ |
+-----+ B1 | N0 | B2 +-----+
| | +------------+ | |
+-----+ +-----+
Host H1 Host H2
Figure 2. Forwarding a MAC frame from H1 to H2 over the VPN🫶 The whole process of transparently forwarding a MAC frame from host H1 to host H2 is also shown in figure 2 🧚 NA B1 wraps up a MAC frame from host H1 and forwards it to MAPOS network N0 ✨ Then NA B2 unwraps the MAPOS frame and passes the MAC frame along to host H2 💅
2.2. MAPOS encapsulation format ✨
okay so, to send a MAC frame into a MAPOS network, the NA wraps it up like a little present 🎁 The format is based on Bridged LAN Traffic for PPP [4], so I'm only going to call out the fields that have MAPOS-specific meaning. Everything goes out left to right, bestie 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0xFE | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (reserved) | Source MAPOS Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS (16/32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3. 802.3 Frame format (IEEE 802 Un-tagged Frame)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0xFE | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (reserved) | Source MAPOS Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional Data Link Layer padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS (16/32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4. 802.4/802.5/FDDI Frame format (IEEE 802 Un-tagged Frame)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0xFE | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (reserved) | Source MAPOS Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | Destination MAC address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | 0x81 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS (16/32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5. 802.3 Frame format (IEEE 802 Tagged Frame)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0xFE | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (reserved) | Source MAPOS Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional Data Link Layer padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS (16/32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6. 802.4/802.5/FDDI Frame format (IEEE 802 Tagged Frame)
Address and Control 🎀
these fields hold the destination HDLC address, as defined by MAPOS Version 1 [1] and MAPOS 16 [3] 💅
Protocol Field 🔥
the protocol field is 0xFE31 for bridged LAN traffic for MAPOS. the NA should only accept NSP (0xFE03) and bridged MAPOS frames (0xFE31) frames, and anything else should be silently discarded 🙈
Source MAPOS address 🦋
this contains the MAPOS address of the sending NA. for MAPOS version 1 [1], the 8-bit HDLC address goes in the least significant place of the 16-bit field, and the upper eight bits must be zero ✨
3. Determination of the Destination MAPOS Address 🧚
okay so this is the part where the bridge figures out where a MAC frame is headed 🗺️ the destination MAPOS address for a MAC frame that's about to be bridged is found by searching the address table, which holds entries shaped like this:
{destination MAC address, destination MAPOS address}the search happens during the encapsulation phase 💜
for example, in figure 2, when a MAC frame meant for host H2 gets encapsulated, the destination MAPOS address for NA B2 is the one that gets used 🌸
so how do we pick the destination for a unicast frame? that's covered in 3.1. broadcast and multicast frames get their own forwarding method in 3.2, and the methods for filling up the address table are explained in 3.3 🍓
3.1. Destination MAPOS address for forwarding a MAC unicast frame 💖
inside the NA, the address table holds entries of the form
{destination MAC address, destination MAPOS address}when a MAC frame comes in on the ethernet interface, the NA searches the address table using the destination MAC address as the key 🔍 if it finds a matching entry, the MAPOS address in that entry becomes the destination MAPOS address. if there's no matching entry, MAC broadcast forwarding (3.2) is used instead 🫶
3.2. Forwarding a MAC broadcast or multicast frame 📣
okay bestie, so every MAC broadcast or multicast frame MUST get duplicated for transmission (via MAPOS unicast) to each of the peer network adapters in the same VLAN as the sending network adapter. nobody gets left on read 💅
Let's look at figure 7, where six LANs N1 through N6 are connected to the MAPOS network via network adapters B1 through B6. 🦋
+------------+
LAN N1 +---+ | | +---+ LAN N2
---------------| |----| |----| |---------------
| +---+ | | +---+ |
+-----+ Network | | Network +-----+
| | adapter | | adapter | |
+-----+ B1 | | B2 +-----+
Host H1 | | Host H2
| |
| |
| |
LAN N3 +---+ | MAPOS | +---+ LAN N4
---------------| |----| network |----| |---------------
| +---+ | | +---+ |
+-----+ Network | N0 | Network +-----+
| | Adapter | | adapter | |
+-----+ B3 | | B4 +-----+
Host H3 | | Host H4
| |
| |
| |
LAN N5 +---+ | | +---+ LAN N6
---------------| |----| |----| |---------------
| +---+ | | +---+ |
+-----+ Network | | Network +-----+
| | adapter +------------+ adapter | |
+-----+ B5 B6 +-----+
Host H5 Host H6Figure 7. Six networks connected to the MAPOS network
So say a VLAN is set up with LANs N1, N2, and N3. A MAC broadcast or multicast frame coming from LAN N1 MUST NOT be forwarded to LAN N4, N5, or N6. It only goes to LANs N1, N2, and N3. It gets duplicated twice for encapsulation and delivery to B2 and B3 via MAPOS unicast. no drama, just the right squad 🫶
A set of network adapters that belongs to the same VLAN defines the broadcast scope of the VLAN. Before a VLAN is put to use, each NA in the VLAN MUST be configured with the MAPOS addresses of its peer NAs. A NA SHOULD silently discard bridged MAPOS frames with a MAPOS source address that is not among the peers that the NA knows about. 🙈
The use of MAPOS multicast for forwarding MAC broadcast frames is under further study. 🔮
3.3. Methods for configuring the address table 🗂️
This section describes two methods for setting up an address table: static and dynamic. The NA MUST implement the static method described in 3.3.1. The dynamic method (3.3.2) is OPTIONAL, but an implementation MUST provide an option to disable this feature. ✨
3.3.1. Static setup of address table 📌
The address table can be set up statically. Before using a VLAN, address table entries for each NA in the VLAN MUST be populated manually.
These entries are considered permanent until they are manually removed. They MUST NOT be "aged" or overwritten by the dynamic procedure described in 3.3.2. permanent means permanent, bestie 💜
3.3.2. Dynamic setup of address table 🌸
The address table can also be set up dynamically. A NA discovers entries for its address table from incoming encapsulated MAPOS frames.
The NA adds the pair
{source MAC address, source MAPOS address}to its address table when it receives an encapsulated MAPOS frame.
Entries discovered this way are subject to an aging timer (which SHOULD be configurable, with a default of 300 seconds). Once the timer for an entry expires, the entry is removed from the address table. The timer gets reset each time an encapsulated MAPOS frame with the same source MAC address is received. ⏰
There MUST be at most one entry for a source MAC address. If a discovered MAPOS address for a MAC address differs from the previously discovered address, the new one takes precedence and the address table entry MUST be overwritten. Under no circumstance MAY a discovered entry overwrite a statically created entry (3.3.1). the static entries are the main character here 👑
Next up is the discovery process using ARP [6] packets between host H1 (the MAC address is h1) in LAN N1 and host H2 (the MAC address is h2) in LAN N2. Here's how it goes down, shown below. 🎀
The MAPOS addresses of NAs B1, B2, B3 are b1, b2, b3 respectively.
+-----------+
LAN N1 +---+ | |
-------------| |----| |
| +---+ | |
+-----+ Network | |
| | adapter | MAPOS | +---+ LAN N2
+-----+ B1 | network |----| |------------
Host H1 | | +---+ |
(ARP request) | N0 | Network +-----+
| | adapter | |
| | B2 +-----+
LAN N3 +---+ | | Host H2
-------------| |----| | (ARP reply)
| +---+ | |
+-----+ Network +-----------+
| | adapter
+-----+ B3
Host H3
Figure 8. Three networks connected to the MAPOS network- Host H1 transmits an ARP request frame. An ARP request frame is a MAC broadcast Frame. 📢
- At NA B1, the ARP request frame is received and encapsulated. Because the VPN is composed of LANs N1, N2, and N3, the NA B1 MUST send a MAPOS frame that has destination MAPOS address b2 and another MAPOS frame that has destination MAPOS address b3. MAPOS address b1 is stored in the source MAPOS address field of each frame. 📦
- The bridged MAPOS frame arrives at NAs B2 and B3 from the MAPOS network. 🛬
- NAs B2 and B3 receive the bridged MAPOS frame, and the pair
{h1, b1}is added to their address tables. 📝 - In NA B2, the received MAPOS frame is decapsulated, and the MAC frame is forwarded to LAN N2. Similarly, in NA B3, the received MAPOS frame is decapsulated, and the MAC frame is forwarded to LAN N3. 🔓
- At host H2, which exists in LAN N2, an ARP reply frame is transmitted to host H1. 💬
- Via the ethernet interface on NA B2, the ARP reply frame is received, and MAPOS encapsulation is done. Because the entry
{h1, b1}is registered in the address table, b1 is determined to be the destination MAPOS address. The bridged frame is forwarded to the MAPOS network. 🧠 - The MAPOS network delivers the bridged MAPOS frame to NA B1. 🚚
- NA B1 decapsulates the bridged MAPOS frame, and forwards the MAC frame to LAN N1. At the same time, the entry
{h2 , b2}is registered into NA B1 address table. 🥳 - Host H1 receives the ARP reply frame. it's a full circle moment 🔁
4. Connecting a MAPOS Host to the VLAN 🧚
In order for a native MAPOS host to connect to a VLAN, it MUST have its own unique MAC address and implement all the features of a network adapter appropriate for the MAC framing that it wishes to use. no shortcuts, babe 💅
5. Security Considerations 🔐
This section discusses some of the security factors that need to be considered when planning a transparent LAN service described in section 1, "Network Model." this part is seriously important, so pay attention 👀
5.1 Management boundaries 🧱
In a large network, different parts of the network are managed by different organizations, and it is essential to clearly define the boundaries of management responsibilities.
A probable scenario is that a common carrier provides transparent LAN service to a variety of customers. Each customer is a distinct organization, expecting virtual private network service. In such a case, the common carrier SHOULD take management responsibility for the MAPOS network, the optical cables to customer sites, and the network adapters that reside in customer premises.
+----+
MAPOS Net +-------- ... --------+ NA +---- MAC-based LAN
+----+
Common Carrier Responsibility --->|<-- Customer ResponsibilityIn essence, the customer is allowed to do no more than connect the cable from their MAC-based LAN to the network adapters. The common carrier SHOULD be very careful to monitor and protect their assets, including SONET/SDH connections and network adapters. In particular, network adapters serve as the primary line of defense against attacks and SHOULD be closely guarded. 🛡️
5.2 Risks ⚠️
Privacy of every customer connected to the carrier's MAPOS network may be compromised. 😳
5.3 Attack against network adapters 🕵️
A network adapter SHOULD be a dedicated device. This makes the device simple and easier to harden against break-in attempts. In the worst case, the device may crash, causing a network outage that only affects the customer that the failed network adapter serves. At this point, the privacy of other customers is still safe. 🫧
A more meaningful attack would be to replace a network adapter with some other intelligent agent that knows how network adapters work. This is possible because network adapters are customer premise equipment. Using such a device, an attacker can infiltrate the networks of other customers. Filtering based on source MAPOS address in bridging traffic is ineffective because this field is filled-in by network adapters -- MAPOS networks do not forward source addresses. this is the scary plot twist, no cap 💀
5.4 Filtering at network adapters and MAPOS switches 🧹
Network adapters SHOULD have the following frame filtering functions.
- Each NA in a VLAN is configured with the MAPOS addresses of its peer NAs that belongs to the same VLAN. A NA SHOULD only accept bridged MAPOS frames with a source MAPOS address of one of its VLAN peers.
- A NA SHOULD never import discovered address table entries with a MAPOS address that is not the address of one of its VLAN peers.
- If a NA detects that the amount of broadcast traffic from a host on MAC-base LAN exceeds a predefined threshold, the NA SHOULD stop forwarding traffic from that host. 🚫
By default, frame filtering by MAPOS switches is OPTIONAL. It is desirable for a MAPOS switch to implement the following filtering features. 🎯
- A line interface of a MAPOS switch is made aware of the MAPOS addresses in the VLAN to which the interface participates. The interface discards all incoming bridged traffic (from the NA) that is destined to addresses outside of the VLAN's set.
- MAPOS switch assigns a MAPOS address to a NA using NSP. The switch discards all incoming bridged traffic (from the NA) with the source MAPOS address different from the one that is assigned by NSP. 🧼
5.5 Additional protection measures ✨
okay so bestie, a common carrier can add some extra protective measures on top of everything we've covered, and here are the big ones 🛡️💖
- SONET/SDH connection is closely monitored. Once a network adapter is detected to have gone down, later attempts to reconnect to the MAPOS network get refused until someone manually re-enables it. 🙅♀️
- Above method is effective against real attacks, but it also hinders timely recovery from accidents such as power outages. Honestly, that's the catch 😭 A reasonable trade-off is an authentication mechanism between the MAPOS network and network adapters, much like Challenge Handshake Authentication Protocol (CHAP) [8] used in PPP connections. Something similar may be implemented by defining additional message types to NSP.
6. References 📚
- [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1", RFC 2171, June 1997.
- [2] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Node-Switch Protocol", RFC 2173, June 1997.
- [3] Murakami, K. and M. Maruyama, "MAPOS16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June 1997.
- [4] Higashiyama, M. and F.Baker, "PPP Bridging Control Protocol (BCP)", RFC 2878, July 2000.
- [5] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
- [6] Plummer, D.C., "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.
- [7] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges," ISO/IEC 15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition, July 1993.
- [8] Simpson, W., "PPP Challenge Handshake Authentication Protocols", RFC 1994, August 1996.
7. Acknowledgements 🫶
The authors would like to acknowledge the contributions and thoughtful suggestions of Naohisa Takahashi, Tetsuo Kawano and Tsuyoshi Ogura. Iconic shout-out to these legends 👑
Appendix - Validation of the MAC Frame Forwarding Mechanism 🧪
This appendix describes the configuration and procedure used to validate the soundness of the mechanism described in this document. The key points are:
- MAC frames are correctly forwarded by MAPOS network, and
- Even if a network contains loops, broadcast packets do not storm the network. MAC-based networks must use broadcast spanning tree technology in order for this to work.
(1) Verification of MAC frame forwarding on MAPOS network 🦋
Hosts H1 and H2, Ethernet switches S1 and S2, network adapters B1 and B2, and a MAPOS switch are connected as shown below. An ethernet protocol analyzer is placed between S1 and B1 for traffic monitoring.
In the diagrams that follow, the hosts are x86 PC running FreeBSD 4.4-RELEASE, ethernet switches are Extreme Summit5i, network adapters are OKI Electric MA-1, and the MAPOS switch is CSR CoreSwitch80.
+--------------+
+------+ MAPOS SWITCH + ------+
| +--------------+ |
+---+---+ +---+---+
| NA B1 | | NA B2 |
+---+---+ +---+---+
+----------+ | |
| Protocol |____| |
| Analyzer | | |
+----------+ | |
| (P1) (P1) |
+------+ +----+----+ +----+----+ +------+
| Host |___| EtherSW | | EtherSW |___| Host |
| H1 | | S1 | | S2 | | H2 |
+------+ +---------+ +---------+ +------+Correct forwarding of unicast MAC frames (ping) are observed between H1 and H2 through path (P1). ✅
(2) Verification of spanning tree operation 🌳
- Enable spanning tree on S1 and S2.
- Connect S1 and S2 via path (P2) for redundancy.
+--------------+
+------+ MAPOS SWITCH + ------+
| +--------------+ |
+---+---+ +---+---+
| NA B1 | | NA B2 |
+---+---+ +---+---+
+----------+ | |
| Protocol |____| |
| Analyzer | | |
+----------+ | |
| (P1) (P1) |
+------+ +----+----+ +----+----+ +------+
| Host |___| EtherSW | | EtherSW |___| Host |
| H1 | | S1 | | S2 | | H2 |
+------+ +----+----+ +----+----+ +------+
(P2)| |(P2)
+-----------------------------+It is observed that broadcast packets are correctly exchanged between S1 and S2, and that broadcast forwarding loop does not exist. 🔁🚫
(3) Verification of spanning tree fail over 💥
- H1 and H2 communication takes place through path (P1). Spanning tree is configured such that Path (P2) is blocked.
It is observed that severing the link at any point along path (P1) makes the spanning tree configure itself to use path (P2).
It is also observed that restoring path (P1) makes the spanning tree configures itself to use path (P1). 🙌
Authors' Addresses 💌
Osamu Okamoto NTT Network Service System Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan
EMail: okamoto.osamu@lab.ntt.co.jp
Mitsuru Maruyama NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan
EMail: mitsuru@core.ecl.net
Takahiro Sajima Sun Microsystems, K.K. 4-10-1, Yoga Setagaya-ku Tokyo 158-8633, Japan
EMail: tjs@sun.com
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc3422 2002-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms