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-ha.... 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 NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
-- Don Stokes, don(a)nz.net mailto:don(a)nz.net, 021 796 072