lkml.org 
[lkml]   [2000]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:1.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site