This page has been created in order to make sure that we are in agreement with regard to terminology. For our purposes a bridged DSL circuit is one that carries encapsulated Ethernet packets across the wire, including ARP and IP wrapped in Ethernet encapsulation complete with 48-bit MAC addresses. A routed DSL circuit OTOH carries only IP across the wire, no ARP and no MAC addresses. Bridged and routed circuits thus differ in the type of packets that go across the wire, not in whether one has a bridge or a router at each end (there can be neither). RFC 1483 and RFC 1490 are the two primary standards defining packet encapsulations for WAN links, and both RFCs define different encapsulation formats for bridged and routed packets. The two RFCs also use the terminology exactly like we do.
Here is an illustration of how this difference manifests practically. Suppose that an ISP issues you a netblock of 10.10.5.0/24 (this is just for the sake of illustration, in the real world they would give you a globally routable netblock, but I don't want to use real IP addresses in general presentations) served to you with a bridged DSL circuit. What will happen in this case is that the ISP will create a logical Ethernet segment, bridge it across the DSL link, assign the whole /24 to this bridged Ethernet segment, attach their backhaul router to this virtual Ethernet segment and pick one of the IP addresses out of your /24 for their backhaul router. Suppose that they pick 10.10.5.1 — the .1 is the usual choice. You'll set 10.10.5.1 as the default gateway on the hosts attached to the Ethernet handoff on your side.
What will now happen is that every time one of your hosts wants to send a packet out to the big Internet, it'll first realise via its routing table that it wants to send to 10.10.5.1. But then it will send an ARP packet out as a broadcast on the local Ethernet asking for the MAC address of 10.10.5.1, and this ARP packet will go all the way across the DSL link and across the DSL backhaul network (an ATM cloud usually) to the ISP's backhaul router. Only the ISP's backhaul router will be able to answer this ARP request and send an ARP response back to your workstation with its MAC address. Your little workstation would thus get the MAC address of a backhaul router that might be thousands of km away and then send outgoing IP packets to that MAC address. The IP packets will travel across the DSL link and across the ATM cloud as they do on an Ethernet LAN, complete with MAC addresses.
The same process will happen in the other direction. Suppose some script kiddie out on the big Internet keeps trying to ping 10.10.5.42, an IP address in your assigned netblock you aren't using. Suppose you also have an analyser hooked up to your DSL line which dumps all received packets while the kiddie is pinging your unused IP address. Are you going to see ping packets pouring out of your line with the IP destination address set to 10.10.5.42? No, you are going to see Ethernet packets encapsulated per RFC 1483 or RFC 1490 containing broadcast ARP queries for that IP address. The ISP's backhaul router won't send you any IP packets until it gets an ARP response with the MAC address it should send to.
Two key observations can thus be made about bridged DSL circuits:
modem.
Now contrast with a routed DSL circuit. Suppose that an ISP gives you the same netblock 10.10.5.0/24, but configures the DSL circuit as routed. In this configuration the ISP's backhaul router no longer cares what you do with any of the IP addresses in your assigned netblock. Your netblock is no longer assigned onto your DSL link, but is merely routed to it. You can even have multiple netblocks routed to your link, it wouldn't matter from the standpoint of the backhaul router or the architecture of the link itself.
There are no more ARP packets or MAC addresses going across the wire. Any time there is an IP packet addressed to one of the IP addresses which belong to you and are routed down your line, the ISP's backhaul router will simply send the packet down your line and you will then decide yourself where it's going based on the destination address field of the IP header. Most likely you will still have an Ethernet LAN at your site, you'll still have 10.10.5.1 as the default gateway address and your workstations will still send ARP queries for 10.10.5.1 any time they need to send a packet out to the big Internet, but the critical difference is that now all this ARP traffic and MAC address information is confined to your site. It will be the DSL router at your site rather than the ISP's backhaul router 1000 km away that will decide whether the gateway address is 10.10.5.1, 10.10.5.2, 10.10.5.30 or whatever. In other words, all this stuff is confined to your site and can be under your total control with a routed circuit, whereas a bridged circuit exposes it all to the ISP.
The Open SDSL Connectivity Project is mainly concerned with connecting to routed SDSL circuits using a router of one's own choice instead of the crap provided by ISPs.
It is also possible to have a router behind a bridge
arrangement.
This arrangement essentially consists of a bridged circuit with an
Ethernet-to-Ethernet router connected to the bridged Ethernet.
As explained here,
this arrangement requires the ISP to give you two separate IP netblocks
instead of just one.
One would think that this would be a very weird and unnatural scenario
and that ISPs would rightfully object to the waste of IP address space,
and this indeed has been our experience, yet strangely enough some DSL
routers like the Netopia R-series
have explicit support for this configuration.
Are there really ISPs that use this configuration on a regular basis
and not just as a very special request for kooks like me?