Using /31 for router links

Robert Glover robertg at
Sat Jan 23 13:47:55 CST 2010

[Michael Sokolov said:]

but 99.999% of all ATM'd xDSL
lines out there carry a single PVC at 0*35 or 0*38.  So what then is the point of running ATM?!?!

We've got several ADSL and SDSL circuits that carry two PVC's: 0/35 and 0/36.  

Covad has a product called "Voice Optimized Access".  I won't go into the gory details of the underlying technology, but the second PVC is utilized for voice.  Essentially two separate IP networks over one physical network, one with guaranteed bandwidth (by way of vbr-rt)  and QoS through Covad's network.

Bobby Glover
Director of Information Services
South Valley Internet
-----Original Message-----
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Sat, 23 Jan 2010 18:52:51 
To: <nanog at>
Subject: Re: Using /31 for router links

Mark Smith <nanog at> wrote:

> What about NAT, ATM cell tax, unnecessary addressing fields in PTP
> protocols (including your beloved HDLC), SSAP, DSAP fields not being big
> enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1
> through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far
> worse sins in my opinion.


PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP.
If all those xDSL users were willing to stick V.35 cards in their PCs
and use "modems" that put out V.35 instead of Ethernet, the whole PPPoE
kludge with all of its attendant MTU issues would have been completely
unnecessary.  Want PPP for authentication etc?  Just run straight PPP
(RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU
unlike Ethernet (jogging my memory, all HDLC controllers which I recall
working with allowed maximum frame size up to just a little under 2^16
octets or so), and one can thus have the standard MTU of 1500 octets on
that PPP link!

Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35
instead of goddamn Ethernet would be a true modem: a modulator/demodulator
that modulates/demodulates the bits at the electrical level without
caring about what's in those bits.  What everyone else in this fubared
world calls an xDSL "modem" (a black box that puts Ethernet out) is not
a modem at all (i.e., total misappropriation of the term), it is
actually a bastardized router!  These boxes forward packets between two
network interfaces: the presented Ethernet interface and the internal
(often horrendously non-standard and proprietary) HDLC or ATM interface
on the actual line.  A device that forwards packets between two
different network interfaces is by definition a router, hence what
everyone calls a "modem" is actually a bastardized router - bastardized
because its routing (packet forwarding) function is something
incomprehensible.  The Ethernet-to-Ethernet NAT boxes that everyone else
calls "routers" should be called "NATters" or something like that,
anything but a router!  A true router is a box with a few AUIs and a few
V.35 ports sticking out of it, running some very capable, flexible and
totally user-configurable packet forwarding software stack that supports
all networking models: IP routing, MAC bridging, VC cross-connect.

As for ATM...  The part that totally baffles me about the use of ATM on
xDSL lines is that I have never, ever, ever seen an xDSL line carrying
more than one ATM VC.  OK, there may be someone out there who has set up
a configuration like that just for fun, but 99.999% of all ATM'd xDSL
lines out there carry a single PVC at 0*35 or 0*38.  So what then is the
point of running ATM?!?!  All the hyped benefits of ATM (a little cell
can squeeze in the middle of a big packet without waiting for it to
finish, yadda yadda yadda) are contingent upon having more than one
VPI/VCI going across the interface!  If every single non-idle cell going
across that ATM interface is 0*35 or 0*38, the interface will never
carry anything other a direct succession of cells making up an AAL5
packet, strictly in sequence and without interruption.  So what's the
point of ATM then?  Why chop that packet up into cells only to transmit
those cells in direct sequence one after another?  Why not simply send
that same packet in plain HDLC over the same copper pairs/fiber?  OK,
the backhaul network upstream of the DSLAM may be ATM and that one does
have many VCs, so ATM *might* be of use there, but even in that case why
not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul,
sending HDLC down the copper pairs?

<off the soapbox for the moment>


More information about the NANOG mailing list