farblog

When I switched ISP to Be Unlimited earlier this year, I wanted to use my existing ADSL router rather than the ‘Be Box’ they supplied, so I followed the instructions Be provide for using a 3^rd party modem. While mostly straightforward, they do include two rather obscure requirements:

Googling for ‘IPoEoATM’ returned no useful results. In contrast, the Be forums were full of useful suggestions about ‘bridging’ and ‘bridge mode’, but it didn’t seem like anyone was really sure what Be were asking for. I managed to get my router to work anyway, but I don’t like mysteries, so I did some research. In summary:

• ‘IPoEoATM’, while not a common term, is one of the standard protocols supported by every DSL modem. It’s not the same as PPPoE or PPPoA (as there’s no username/password), and it’s not the same as IPoA (that’s something else). On my router (a Netgear DG834N), it’s selected by first telling the router that it doesn’t need to login, and then choosing ‘use static IP’ instead of ‘use IPoA’.
• In this context, ‘bridging’ can refer to two separate-but-related concepts. One is about turning your modem/router into a modem/bridge; the other is about the form of packets on the (DSL) wire, and Be is definitely asking for the latter. It turns out (per the DSL spec) that this is just another way of saying that they want you to use IPoEoATM rather than IPoA.

If you’re not interested in network geekery, you can stop reading now (if you haven’t already :-)), because I’m going to go into a little bit more detail than is probably healthy.

ADSL bridging should be enabled (as per RFC 1483)

Bridging first. For DSL routers, ‘bridge mode’ commonly refers to switching off the router part of your combined DSL-modem-and-router, leaving it as a DSL-modem-and-bridge. That is, converting it from a layer 3 router to a layer 2 switch, albeit one that’s got a single ‘DSL’ port in addition to the others.

For this to work, you need to assign externally routable addresses to your internal hosts and set each of them to use a specified (remote) IP address as their gateway, as your modem/switch will no longer being doing any kind of NAT. You probably also want to make sure you have some kind of stateful firewall between them and the outside world, since generally you’ll have been getting that ‘for free’ with NAT.

In my case, since I have more internal IP addresses than I have external IPs allocated to me, I really didn’t want to do this if I didn’t have to. Fun fact: you can switch a DG834N into bridge mode by going to the hidden URL /mode.htm; bridge mode is called “Modem (modem only)”.

However, that ‘bridge mode’ isn’t the same thing as RFC 1483 bridging at all.

RFC 1483 (and RFC 2684, which obsoletes it) describes two multiplexing methods for packets traveling over ATM (ATM being the typical network infrastructure employed on the other side of the DSLAM at the end of your phone line). One method, LLC encapsulation, can carry multiple protocols (IPv4, IPv6, ARP, IPX, Ethernet, etc) per ATM virtual circuit, while the other, VC multiplexing, uses a separate ATM VC for each protocol.

LLC encapsulation is more flexible, while VC multiplexing is more efficient. (In particular, since VC multiplexing relies on out-of-band setup to provide some of the information about the packets, the overhead in some — common — cases can be zero.) RFC 2684 discusses some of the trade-offs:

My previous ISP used DSLAMs owned by BT, and BT (as far as I know) exclusively uses VC multiplexing. Be owns their own DSLAMs, and has chosen to use LLC encapsulation, which seems like an odd choice given that I assume they’re only routing one protocol (IPv4) at present. Perhaps they’re giving themselves space for more, who knows?

Anyway, each of LLC encapsulation and VC multiplexing can be used to send packets containing either routed or bridged protocols, and each of these four combinations uses a slightly different packet format.

Be is asking for LLC-bridged, which means they want to you to send Ethernet frames rather than IPv4 packets. (Obviously, the Ethernet frames will contain IPv4 packets; I’m just talking about the outermost protocol here.)

How does this relate to whether you put your DSL router into ‘bridge mode’? A little. The two concepts are almost orthogonal: the choice of whether the DSL frame payloads sent by your modem include a host’s source address or the address of your router’s external interface is, in one sense, entirely separate from the choice of whether those payloads are Ethernet frames or IP packets.

There’s one obvious way they’re related in practice, though: if your modem is a layer 2 switch, it’s only looking at the Ethernet frame headers, not the IP packets, so — with the exception of the (rather unlikely) case in which you were able to configure a point-to-point connection between a specified internal host and the remote gateway — you would need to use Ethernet frames rather than IP packets so that your modem can switch incoming DSL payloads to the correct host.

Connection type is IPoEoATM

Onto the somewhat nebulous “IPoEoATM” term. The only official definition I found for this term comes from a technical report by the DSL Forum called “TR-101: Migration to Ethernet-Based DSL Aggregation”. It seems to primarily be about changing parts of an ISPs internal infrastructure from ATM to Ethernet, but includes a diagram of the seven (!) standardised network stacks in use on the end-user side of an ADSL DSLAM (what was that quote again? “The good thing about standards…”).

Anyway, three of these seven stacks describe various encapsulations of Ethernet frames directly within DSL frames, which I’ve not seen supported anywhere yet, while the other four deal with more typical ATM-in-DSL frames. These four were originally specified in an earlier document, TR-043: Protocols at the U Interface, where they are named as: “IP/Eth (commonly called ‘1483’)”, PPPoE, PPPoA, and IPoA. However, TR-101 gives an alternate name for the first: IPoEoATM.

Since I’ve come this far, here’s how the four DSL/ATM protocol stacks mentioned in TR-101 stack up (hah):

• IPoEoATM: (DSL (ATM (AAL5 (RFC 2684 bridged (Ethernet (IP))))))
• PPPoE: (DSL (ATM (AAL5 (RFC 2684 bridged (Ethernet (PPPoE (PPP (IP))))))))
• IPoA: (DSL (ATM (AAL5 (RFC 2684 routed (IP)))))
• PPPoA: (DSL (ATM (AAL5 (RFC 2684 routed (PPP (IP))))))

(You can see how Be’s request for “ADSL [sic] bridging per RFC 1483” is already covered by their earlier request for IPoEoATM.)

Notes: I didn’t mention AAL5 above; it’s an encapsulation allowing variable-length payloads to be carried by one or more (fixed-size) ATM cells (i.e. it’s the ATM version of TCP fragmentation). Also, PPPoA actually doesn’t use RFC 2684: it uses RFC 2364, but as far as I can see, the net effect is (bitwise and deliberately) identical to as if it were defined in terms of RFC 2684, with PPP treated as a routed protocol.

Finally, with all this encapsulation going on, you might be assuming (as I was) that a noticeable proportion of your DSL traffic is taken up with encapsulation overhead. It turns out that it’s not actually too bad (depending on IP payload size; see the appendices at the end of TR-043 for the gory details), but there’s a lot more complexity in this DSL thing than I previously realised!