[lkml]   [2000]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DSL Modem?
Can't believe how long this thread is lasting...DSL devices
are not working specifically on IP -- they run at lower levels:

I think Alan mentioned this was cells like ATM -- though anyone
can feel free to check or the ITU for more
info on the low level details.

As for how IP is transported across the DSL links -- the three
most common methods I see as a SysAdmin who works and sells DSL
services are:

ATM-Ethernet bridging (RFC1483)
PPPoE (as an additional layer on top of the bridging)

The direct PPP connections are perhaps rare these days with ISPs
as this is usually used with a direct CPE - COE pair of boxes rather
than coming through a DSLAM on the service provider or telco.

The bridging, is more oftenly used and often is left to be part of
the DSL 'modem'. I'm not current on the state of the kernel, but
I don't think this type of bridging is in the linux kernel though
so you would still need the external device to support this.

Finally, PPPoE got quite a bit of attention on this list from
August to October last year. 2.3.X introduced it to the kernelspace
and there are user space apps out there if you search

I suppose this only leaves 3 issues that are valid for the list
topic however:

rfc1483 bridging support in the kernel?
PPPoE support in kernelspace...
support for various DSL chipsets.


As for 'saving IPs' -- someone has mentioned proxy arp, which could
be useful in the bridging scenario -- but alas, this also means no
internal card at this point I believe.

In the other scenarious, where you are transporting the IP information
not acrossed the bridged ethernet segment -- but rather over a PPP
session (whether native to the line or built on top of the bridged
ethernet) -- chances are you're stuck with the range of IPs you've been

An A.B.C.D/29 network is going to leave you with 5 'usable' IPs for
other machines unless you use NAT. Even with PPP Unnumbered, one
IP is still used -- Unnumbered saves you an IP on the WAN side, not
the LAN side.

Moreover, the comments about prohibiting NAT are policy only. As
far as I know -- there is no way to determine if a person is using
NAT from the other side of a connection without having some sort
of access to their equipment. Personally, unless I'm paying a
provider to service my equipment, configure, maintain, etc -- I
don't want them to touch it.

If you're using a device that works in the bridging mode -- good
luck on anyone figuring out if you're using IPMasq (or todays
equivalent) from the other side -- your usage of such methods will
of course be more regulated by your principles. -- Though I tend
to alternate between chuckling and pulling hair at all the management
types who think NAT is such a big worry that the consumer will pull
more bandwidth -- despite the fact that they are paying for this amount
of traffic and no matter if they're using NAT or not -- they won't
consume more bandwidth than their link (and access rates on the routers)


Robert G. Fisher NEOCOM Microspecialists Inc.
System Administrator/Programmer (540) 666-9533 x 116

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.079 / U:0.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site