why do we require pppoe when ppp is there

[cheeku]

hi,....can anybody plz.help me in knowing why pppoe or pppoa is
required when ppp is there.what are the advantages that pppoe offers
compared to ppp.how is pppoe different from ppp.kindly suggest me some
web resources regarding these topics.
thank you

[James Carlson]

Post by cheeku
hi,....can anybody plz.help me in knowing why pppoe or pppoa is
required when ppp is there.what are the advantages that pppoe offers
compared to ppp.how is pppoe different from ppp.

They're not.

PPPoE is a method for running PPP over Ethernet. PPPoA is a method
for running PPP over ATM. RFC 1662 includes methods for running PPP
over simple point-to-point media, such as synchronous and asynchronous
interfaces.

There are other methods available for running PPP over various
point-to-point media, such as Frame Relay circuits and tunnels.

Of these, PPPoE is a bit of an odd duck. It was invented outside the
IETF (in the DSL Forum) as a way to provide user management and
authentication to xDSL deployments that typically use Ethernet bridged
over ATM. In my opinion, it has no excuse for existing. The right
solutions would be one of these:

- Just use plain IP over Ethernet. Add authentication to DHCP if
you really think you must do that. I doubt that you really need
it, though. (Note that cable deployments run plain old IP over
Ethernet with DHCP and haven't had any need for separate
authentication.)

- Go one better, and rip out the unnecessary use of encapsulated
Ethernet+ATM. Run PPP over HDLC on the low-level DSL link, and
route IP via the CPE equipment. This would be much lower overhead
and simpler.

In any event, there's no way to answer your questions. One doesn't
(and can't) choose between PPPoE and PPP -- they're used _together_.

Post by cheeku
kindly suggest me some
web resources regarding these topics.

www.google.com is a good way to find resources.

PPP is defined in RFC 1661. If you look around a bit, you might find
a book that describes how these protocols work. (Hint: using my name
and 'PPP' as keywords in an amazon.com search might work. ;-})

[Pascal Hambourg]

Hello,

Post by James Carlson
Of these, PPPoE is a bit of an odd duck. It was invented outside the
IETF (in the DSL Forum) as a way to provide user management and
authentication to xDSL deployments that typically use Ethernet bridged
over ATM. In my opinion, it has no excuse for existing.

You are harsh. The only real problem with PPPoE is that it violates the
PPP RFC by not supporting an MTU of at least 1500.

Post by James Carlson
- Just use plain IP over Ethernet.

But you lose lose the routing benefits of a point-to-point link.

Post by James Carlson
Add authentication to DHCP if you really think you must do that.

Do all common DHCP client implementations support authentication ?

Post by James Carlson
I doubt that you really need
it, though. (Note that cable deployments run plain old IP over
Ethernet with DHCP and haven't had any need for separate
authentication.)

Not all cable deployments use IP over ethernet, some use PPPoE.

Post by James Carlson
- Go one better, and rip out the unnecessary use of encapsulated
Ethernet+ATM.

You can also keep the ATM layer and use PPPoA or routed IP over AAL5 (IPoA).

Post by James Carlson
Run PPP over HDLC on the low-level DSL link, and
route IP via the CPE equipment. This would be much lower overhead
and simpler.

But it lacks flexibility. The ethernet layer has the advantage of
compatibility with most equipments, including simple bridging DSL
modems, SOHO routers and personal computers, and independence with the
layer 3 protocols (IPv4, IPv6, whatever).

[James Carlson]

Post by Pascal Hambourg

Post by James Carlson
Of these, PPPoE is a bit of an odd duck. It was invented outside the
IETF (in the DSL Forum) as a way to provide user management and
authentication to xDSL deployments that typically use Ethernet bridged
over ATM. In my opinion, it has no excuse for existing.

You are harsh.

Deliberately so. Inventing new extensions to Internet infrastructure
protocols outside of the IETF is definitely something that should be
avoided.

Post by Pascal Hambourg
The only real problem with PPPoE is that it violates
the PPP RFC by not supporting an MTU of at least 1500.

The only problem?

How about its complete lack of security? How about the asymmetric
(and broken) session ID assignment mechanism? How about the
functional overlap with L2TP?

The MTU issue is certainly a very important one, and one that greatly
(and unfortunately) affects users who are stuck on those damaged
links. It's not the only flaw, though.

Post by Pascal Hambourg

Post by James Carlson
- Just use plain IP over Ethernet.

But you lose lose the routing benefits of a point-to-point link.

What benefits would those be?

Perhaps you mean "lack of broadcast support" or "forcing all local
traffic through the central site." I would suggest that any system
that relies on such a thing for security is fatally flawed. If end
users are relying on this -- well, I guess they get what they ask for.

Post by Pascal Hambourg

Post by James Carlson
Add authentication to DHCP if you really think you must do that.

Do all common DHCP client implementations support authentication ?

No. But before PPPoE was invented and forced onto consumers, nobody
supported PPPoE either. So, in a fair discussion about whether PPPoE
should have been created, I think it's important to look at the actual
problem being solved. If that in fact was intended to be peer
authentication, then something like Proposed Standard RFC 3118 should
have been considered.

Deploying new DHCP code should be no easier or harder than deploying
new PPP tunneling mechanisms.

Solving the problem in the right place, though, means that you end up
with a reusable solution that helps in other areas. (Wouldn't it be
nice to have a hotel access solution that didn't involve hacks such as
redirecting HTTP traffic or yet more protocols?)

Post by Pascal Hambourg

Post by James Carlson
I doubt that you really need
it, though. (Note that cable deployments run plain old IP over
Ethernet with DHCP and haven't had any need for separate
authentication.)

Not all cable deployments use IP over ethernet, some use PPPoE.

Yes, I know. Again, it's mostly pointless, as it's just unnecessary.

Post by Pascal Hambourg

Post by James Carlson
- Go one better, and rip out the unnecessary use of encapsulated
Ethernet+ATM.

You can also keep the ATM layer and use PPPoA or routed IP over AAL5 (IPoA).

Indeed. However, that's still higher overhead (and lower performance)
than plain old HDLC.

Post by Pascal Hambourg

Post by James Carlson
Run PPP over HDLC on the low-level DSL link, and
route IP via the CPE equipment. This would be much lower overhead
and simpler.

But it lacks flexibility. The ethernet layer has the advantage of
compatibility with most equipments, including simple bridging DSL
modems, SOHO routers and personal computers, and independence with the
layer 3 protocols (IPv4, IPv6, whatever).

I think that misses the point I was trying to make.

The link between DSLAM and CPE device is *not* Ethernet. It's nothing
like it. Instead, it's a synchronous bit stream (or, rather, a pair
of them).

Two good choices for a point-to-point synchronous link are HDLC and
ATM. Of those, HDLC has much lower overhead, and is cheaper and
easier to implement. With such a link in place, you can run PPP from
DSLAM to CPE.

How exactly you connect the CPE device to local computers is a
separate matter. You can reasonably choose to use Ethernet for that
application and _route_ between the two links.

Bridging Ethernet all the way through the DSL link is not at all a
requirement of operation in this sort of environment. It's what the
telcos have chosen to do.

The claimed benefit here seems to be the ability to run non-IP
protocols. But, frankly, who cares? Is there any ISP out there
providing access to the SNA web?

(If you really, really need to run strange non-IP protocols over that
link, PPP already supports them. You can even bridge the others with
BCP.)

[vangelis angelakos]

This is becoming an interesting point of discussion!



I agree that DSL link should be thought as simple (in

concept, not implementation) point-to-point bitstream.


Implementing ATM above that, would make sence
if a decade old equipment was trying to mix voice-data
in fair chance over the interface. Today's CPEs are
quite capable on priorizing traffic that could justify
avoid paying:
-Segmentation And Reassembly (SAR) costs,
-Poor support of IP design concepts (variable
length packets, routed .vs. switched datagrams etc),
-Layering multiple data-link layer protocols on
top of each other in order to get the job done (overhead
and conceptual problem).

Telcos needed to use ATM infrastructure probably forced
(in a way) ATM on DSL technologies, and caused strange
ideas to be introduced (BRAS's). What Mr. Carlson suggests
is the future. Switching DLAMs to (default route) Routers,
with HDLC over DSL is the best an IP network would
hope for.

note:
some would say BRAS is not a strange idea... Please
reconsider the centralization and load you have to
put on a network point in order to get:
a. Authentication which can be done in more efficient ways,
already suggested, or not doing it at all (LLU)!!
b. IP address distribution. Purely ISP financial trick to my
opinion.. why not giving a static ip per DSL user? It is
simple, easy and to-the-point.

vangelis

[James Carlson]

Post by vangelis angelakos
Implementing ATM above that, would make sence
if a decade old equipment was trying to mix voice-data
in fair chance over the interface.

That ATM-to-the-desktop dream died a long time ago.

Post by vangelis angelakos
Telcos needed to use ATM infrastructure probably forced
(in a way) ATM on DSL technologies,

I wouldn't say it was "forced." From what I saw (I was in access
equipment before coming to Sun), it looked like a combination of savvy
marketing on the part of equipment vendors, a "comfort zone" for
telcos, and perhaps a bit of misguided hope that QoS would one day
matter.

Post by vangelis angelakos
some would say BRAS is not a strange idea... Please
reconsider the centralization and load you have to
a. Authentication which can be done in more efficient ways,
already suggested, or not doing it at all (LLU)!!

Indeed. If you have a physical wire running to a customer site, it's
hard to have more authentication than that. What's the threat model
that requires something more secure?

In fact, I think the problem here is broken business models. Folks
coming from the dial-up market sometimes want to continue to charge by
"connect time," even when it no longer makes any sense.

Post by vangelis angelakos
b. IP address distribution. Purely ISP financial trick to my
opinion.. why not giving a static ip per DSL user? It is
simple, easy and to-the-point.

This one is a bit more complex, I think.

During early deployment of any large-scale network, it can be hard to
predict exactly where (and when) you'll be consuming addresses -- it
depends on an unpredictable consumer base. Because addresses are a
scarce resource, and because you generally want to take advantage of
aggregation (lest routing get out of hand), this means you sometimes
end up having to renumber existing users.

The pattern I'd expect to see is frequent renumberings early in the
roll-out, and then less frequent over time as the market saturates and
matures. How quickly that happens depends on how many extra addresses
are available and how clever the ISP is in planning.

If you're going to have to renumber at some point, then DHCP is a fair
choice to make sure you have some automated control over those nodes.
Static addresses would be nice, but you can get awfully close if you
have a DHCP-provided address that just 'never' changes.

[vangelis angelakos]

Post by James Carlson
This one is a bit more complex, I think.
During early deployment of any large-scale network, it can be hard to
predict exactly where (and when) you'll be consuming addresses -- it
depends on an unpredictable consumer base. Because addresses are a
scarce resource, and because you generally want to take advantage of
aggregation (lest routing get out of hand), this means you sometimes
end up having to renumber existing users.
The pattern I'd expect to see is frequent renumberings early in the
roll-out, and then less frequent over time as the market saturates and
matures. How quickly that happens depends on how many extra addresses
are available and how clever the ISP is in planning.
If you're going to have to renumber at some point, then DHCP is a fair
choice to make sure you have some automated control over those nodes.
Static addresses would be nice, but you can get awfully close if you
have a DHCP-provided address that just 'never' changes.

I also do like the DHCP solution since it automates the process making
it less prone to configuration error. However DSL customers are expected
to stay constantly online so you save no address space on active ports
(you do save on inactive ones but again it is a question of what you
gain and what you loose, deciding if you are going to implement DHCP
or not).
I think properly subnetting and taking into account that typically providers
build a collapsed network (DSLAMs -> Switches -> Router) for their DSL
customers, could help route aggregation and minimize the losses of static
addressing.

vangelis

[Ignatios Souvatzis]

Post by James Carlson
The claimed benefit here seems to be the ability to run non-IP
protocols. But, frankly, who cares?

Me.

Post by James Carlson
Is there any ISP out there providing access to the SNA web?

Well, not SNA. But there are at least 4 ISPs offering access via
T-elekom's T-DSL who offer IPv6 in addition to IPv4, or alone...

Post by James Carlson
(If you really, really need to run strange non-IP protocols over that
link, PPP already supports them.

This is correct, and this is what they do for IPv6, so it would work
with PPP over HDLC, too.

Regards,
-is

[James Carlson]

Post by Ignatios Souvatzis

Post by James Carlson
The claimed benefit here seems to be the ability to run non-IP
protocols. But, frankly, who cares?

Me.

Really? What non-IP protocols matter to you?

Post by Ignatios Souvatzis

Post by James Carlson
Is there any ISP out there providing access to the SNA web?

Well, not SNA. But there are at least 4 ISPs offering access via
T-elekom's T-DSL who offer IPv6 in addition to IPv4, or alone...

IPv6 *is* IP. I was specifically asking about non-IP protocols.

The original issue was the sort of limitations that you'd have to deal
with if the CPE box were involved in the equation, rather than just
being a dumb bridge. In truth, that box could run BCP (and do
bridging over PPP), so the point is actually moot, but even in the
extreme, where you're forced to have the CPE device routing for you,
this means that you need to support the extant protocols. That's
basically just IP. With a very short list, and fairly rapid turnover
in the end user device market, it shouldn't have been a crucial design
decision.