Openreach FTTP migration PPPoE to DHCP

I have recently migrated ISP, both using Openreach. Previous ISP used PPPoE to authenticate to obtain a static IP (business line), I migrate to a residential service also using Openreach, but the ISP uses DHCP (Sky).

I was expecting I would have to reconfigure the WAN port when the service went down, however I was pleasantly surprised to find the connection was migrated around 01:30am with no noticeable downtime, just the line reconnecting straight away.

I was curious how the WAN port was able to obtain a Sky IP address, and connect OK, even though the WAN port was still configured for PPPoE with previous ISP details? WAN port was configured for IPv4 only, IPv6 was disabled with previous ISP.

Has there been a change in how the Openreach FTTP service authenticates, ie its ignored on residential service?

This would make sense for consumers who have not replaced there routers when the line is migrated.

No real knowledge, but I suspect it is at least in part due to your router being content to do DHCP even though it is set to use PPPoE. I may be wrong, but I seem to have read that Sky does not actually need authentication.

Openreach doesn't care what form of authentication your ISP uses, they provide an (almost transparent) VLAN between the ONT and the ISP and it is up to your ISP what authentication, if any is used.

Lots of ISPs use PPP because they can route PPP connections together onto the same VLAN whilst still keeping them logically separate, making their network design easier.

If the ISP equipment that handles termination of customers connections can handle VLANs as effectively as PPP tunnels then there is nothing stopping the ISP from doing that - they don't even need to offer DHCP, if they wanted to be really bare bones they could just ask their customers to configure their router with the correct addresses (although that wouldn't allow dynamic IP allocation).

Of course it is not quite that simple, the Openreach channel isn't completely transparent and messes with PPP and DHCP packets (in the PPP case, this gives the ISP a circuit identifier so if they extract the link from its VLAN, they still have an identifier). Of course, this means that you can't, for example, serve DHCP to your ISP via an Openreach FTTP connection (although doing it encapsulated in a PPP connection would work if you really needed to do that).

Thanks, but I'm still not clear how my router was able to obtain a Sky IP address, when the WAN port was configured for PPPoE for a static IP of previous ISP?

I checked logs around time of migration, 01:30, , the PPPoE authenticated with a username and password configured for previous TalkTalk Business, but obtained a Sky residential IP address.

In reply to a post by craigski:

the PPPoE authenticated with a username and password configured for previous TalkTalk Business, but obtained a Sky residential IP address.

So try setting the password and the username to something irrelevant - see if you get the same results?

There is nothing to stop a router attempting both DHCP and PPP on a WAN port and going with whichever succeeds. Such a design would be more "plug and play", at the risk of potentially weird effects if both were available.

Does the router have the capability to select the authentication / link encapsulation / address allocation arrangements for the WAN port?

Sky can authenticate a connection using DHCPV6 so I would suggest this is what has happened.

Here's bit of AI speak.....

Sky broadband can use DHCPv6 for authentication via port-based or MAP-T deployments, but it is not universally supported across their entire network, with Openreach exchanges only supporting it on approximately 80% of lines, meaning some lines will still use DHCPv4 Option 61 authentication. For connections that do support DHCPv6, the authentication typically relies on information from the DHCPv6 messages, rather than requiring a specific username and password.

Dummy credentials also work.

2025-10-02T11:05:57+01:00 FW ppp0[2375595]: rcvd [CHAP Challenge id=0x1 <d4.................d>, name = "br0-dist.enwkg"]
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: sent [CHAP Response id=0x1 <40..................9>, name = "dummyuser@dummydomain"]
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: rcvd [LCP EchoRep id=0x0 magic=0x.......]
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: rcvd [CHAP Success id=0x1 "CHAP authentication success"]
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: CHAP authentication succeeded: CHAP authentication success
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: CHAP authentication succeeded
2025-10-02T11:05:57+01:00 FW ppp0[2375595]: peer from calling number xx:xx:xx:xx:xx:xx authorized

The Sky residential line is authenticating a PPPoE connection with dummy credentials, and getting an IP address via IPCP.

My understanding is that Sky requires DHCP client on WAN interface, with option 61.

In reply to a post by Realalemadrid:

Sky can authenticate a connection using DHCPV6 so I would suggest this is what has happened.

Nope, IPv6 disabled.

Edited by craigski (Thu 02-Oct-25 13:50:36)

Similar thread here from last year, so this is not a new thing.

Sky Forum

I have setup the WAN connection to DHCP, but have not set the 61 option. IPv6 is now also enabled.

It does make sense that ISP will allow any type of authentication, for a better migration experience (minimal downtime) of customers who may decide not to plug in new ISP supplied router on activation day.