Re: Dialup over Ethernet

On 13/09/2017 6:38 p.m., Peter Lambrechtsen wrote:

I'm firmly in the PPPoE is the only way to run a fixed broadband
network.

Well said

The Internet has done very well using Point to Point links from
provider to CPE since the days of SLIP.

DHCP is for wireless and keeps us in a job :)

Cheers

BG

You can change customers IP addresses easily by just kicking them
and they come back in worst case 90 seconds (or 5 mins if it's a
EUBA connection for the session to timeout). Can't do that on IPoE
unless you have stupid low lease times.

RemoteID and CircuitID are inserted in the PPPoE payload so you
can auth them without requiring credentials. Much like you use
option 82 on IPoE.

No support for username and password so if your friendly LFC has
screwed up the provisioning so you can't auth them on RID/CID you
can't ask your customer to put in "heyfindme" in their username on
the router and they magically appear in the radius logs and then
tell the LFC to sort it.

All LFCs support 1508 MTU so if your router and BNG does it then
you can get a full 1500 sized packets which you can on Spark.

Routed networks are easy you just allocate a subnet to sit behind
the router.

You don't need to waste a /31 per customer and thus 2 public IPs
per subscriber or have some dirty flat routed networks across all
your customers when each customer is a separate layer 2 network so
you have a /22 or something and have a dedicated default route per
subnet. PPPoE you only need a single real IP allocated to the
interface and then only 2 IPs per subnet being broadcast and
network rather than a routed IP too thus losing another ip per
range.

Using VLAN 10 means you can use .1q tagging from the CPE and have
real working QoS over the link. If you don't need QoS then no need
for VLAN 10. But once you've gone down the tagged route it's hard
to move back as then you have a customer config nightmare.

Find arguments against the above and I may listen. But until then
I am completely sold on PPPoE vs IPoE.

Sent from my phone so excuse the brevity.

-------- Original Message --------

Subject: Re: [nznog] Dialup over Ethernet

From: Don Stokes

To: [email protected]

CC:

I'm firmly in the PPP Must Die
camp.

As far as I can make out, PPPoE is a thing because ISPs built
PPP & Radius infrastructure for dial-up, used it to for
ADSL (because that was the only way Telecom would let you do
it), and continue to use the same back-end stuff to drive
PPPoE for ADSL, VDSL, UFB and anything else they can get to
speak it.

It has the advantage that IP address management with PPPoE
& friends is fairly straightforward, and you don't go
wasting IP addresses, given that everything speaking native IP
over Ethernet expects to see a subnet with a network,
broadcast and gateway address in a /30 or bigger subnet, an
issue I addressed here .
This is important, because UFB is VLAN-per-circuit; you can't
just lump a bunch of clients into a single IP subnet, a la
Citylink in the old days.

UFB has PPPoE brains that allows the PPPoE handshake to inform
the ISP what service a PPPoE packet, independent of the VLAN
tags, which in turn can be fed to a Radius server to identify
a customer. (There's also DHCP brains to do the same for DHCP
requests. Both are service-order-time options.) I don't
believe anyone is actually using usernames/passwords to
identify customers any more, but I won't be surprised if I'm
wrong. It's not like dial-up where the customer could be
coming from anywhere.

Note that PPPoE in most configurations has an MTU of 1492, not
1500 (because there's an 8-byte PPPoE/PPP header between the
MAC header and the IP payload). Which is another reason PPPoE
needs to be killed. I'm not sure if 1500 MTU PPPoE (i.e. 1508+
MTU Ethernet) is supported by either ISPs or UFB. I believe
UFB circuits are happy to take the larger frames, but since
I've not tried to work with it, I can't say for sure.

-- don

On 09/13/2017 05:53 PM, Ewen McNeill wrote:

A client had a (business) customer
switch over to UFB and needed assistance reconfiguring the
(Mikrotik) router being attached to the ONT -- it turned out
whoever first set up the Mikrotik (sensibly) assumed it'd be
seeing IP packets over VLAN 10, but actually the ISP required
IP packets over PPPoE over VLAN 10 in order for it to work.

Looking around it appears this client's customer's ISP isn't
the only one that is requiring PPPoE over VLAN tagging over
Ethernet for their UFB connections. Is there a reason other
than "let's make everything look like 1990s dialup so it works
with our legacy equipment" for the bit/CPE CPU overhead of
PPPoE on UFB, including imposing the lowered usable MTU and
PMTU discovery headaches on the end user?

The only one that really comes to mind is "user/password
authentication" (rather than needing to collect CPE MAC
addresses which seems to happen with, eg, Vodafone
cable/FibreX). But it's not clear to me why, eg, 802.1X isn't
used for the user/password authentication in that case; or
DHCP with some extension to pass a "secret" identifier.
20-bytes-per-packet-forever seems a large overhead to pay for
user/password authentication at CPE power on.... (Maybe in the
beginning there's "lack of CPE support" -- but we're a few
years into the UFB rollout, and lots of ISPs seem to be
supplying their own ISP-badged CPEs anyway, which could
presumably implement whatever was needed.)

Ewen

_______________________________________________

NZNOG mailing list

[email protected]

https://list.waikato.ac.nz/mailman/listinfo/nznog

--

Don Stokes, [email protected] , 021 796 072

This communication, including any attachments, is confidential.
If you are not the intended recipient, you should not read it -
please contact me immediately, destroy it, and do not copy or
use any part of this communication or disclose anything about
it. Thank you. Please note that this communication does not
designate an information system for the purposes of the
Electronic Transactions Act 2002.

----------

This e-mail message has passed virus
scanning by Outersite Technology.

_______________________________________________
NZNOG mailing list
[email protected]
https://list.waikato.ac.nz/mailman/listinfo/nznog

_____________________________________________________________________
This e-mail message has passed virus scanning by Outersite Technology.

----------

This e-mail message has passed virus scanning by
Outersite Technology.

_______________________________________________
NZNOG mailing list
[email protected]
https://list.waikato.ac.nz/mailman/listinfo/nznog