Re: Dialup over Ethernet

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 
<http://www.don.nz.net/wordpress/broadcast-interface-addressing-considered-harmful/>. 
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] <mailto:[email protected]>, 021 796 072

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