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 http://dslforum.org 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:
PPP
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 freshmeat.net.
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 assigned.
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) allow.
-----
-- 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:15 EST