On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <
nanog@nanog.org> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
OK, so one router or two?
- Both providers have IPv6 (competing in the market so don't cooperate on how to address, manage customer homes)
This shouldn’t be necessary with appropriate CPE, especially if Mr/Ms/Ze Smith has a single router for both.
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything else technical (typical consumer); They only knows how to walk into a store and buy a random thing off the shelf and ask for "WiFi".
Again, assuming a single router managing both providers with a sane implementation and rational defaults, this shouldn’t be a problem.
Of course, today, that isn’t really available in v4 for the most part, either.
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
Let’s further pretend that the software in the box is sane about its v6 implementation and has a “primary” and “backup” port allowing it to make rational default choices
about priority/preference fields in the RAs that it generates and that it defaults to SLAAC only on the LAN ports.
- Lets also assume the cable boxes have a consumer actionable way to force R1483 mode, and assume the DSL device can do the same (I know many providers that don't allow this type of configuration)
R1483 is unfamiliar to me unless you mean the RFC covering Multiprotocol Encapsulation over ATM Adaptation Layer 5.
Assuming this is what you mean, let me get this straight, we’ve got a consumer who doesn’t know what IPv4 or IPv6 are, and she just wants WiFi, but she’s supposed to understand what RFC-1483 is and/or the implications of ATM Adaptation layer 5 for multi protocol encapsulation? I could be wrong, but I think that’s asking a lot.
The CPE should have rational defaults for supporting the two connections, period. She shouldn’t need “consumer actionable anything” an it should be possible to just plug it in and have it work.
- So this dual WAN (retail) device now has one Public IPv4 address per WAN interface (assuming one or both of the services was not disallowing bridging mode, in which case its a Private address on one or both of the WAN interfaces)
Sure, but we really don’t care about the IPv4 thing here, that’s going to involve tragic NAT hackery and whatever. Hopefully it’s a somewhat temporary problem.
- this dual wan device also gets a PD from both upstream providers which delegates to the CPE
That’s certainly what I would expect.
I will ignore the dual router case as that normally looks very ugly in networks as customers typically don't hook that up correctly (normally hook one box in behind the first, not in parallel). Do we think this use case just works today? Can we say we are confident we know how this all pans out in real production? e.g. CPE only uses one PD? uses both? does all the right things to support SLAAC downstream?
I think that if the CPE has rational defaults (which I admit is not a given today) and truly supports IPv6 on the dual WAN ports with proper support for PD and corresponding SLAAC on the LAN ports, then yes, this should work.
CPE should use both. It should create RAs with a prefix from the primary port PD as preferred,valid,on-link and the secondary port PD as valid,on-link. CPE should have no problem doing SLAAC downstream.
I do not know if there are currently any routers that get this right, nor do I know if there are not. It’s almost certain there are still CPE routers that get this wrong.
I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what happens and normally the consumer has no clue what's going on and the router just deals with it. For the IPv6 side, I am not yet confident this is all just working yet. I would like to be wrong. I can say - in my consumer mode in the US - this example above is not working by default. (I won't out the providers of course). I want the answer to be different, but there is still more work to do (especially since dual provider has become much more common due to work from home).
It’s a valid concern and I’m not sure what testing has been done at this level yet. I will say that it’s a not particularly common configuration even in IPv4 and the switchover when the primary ISP fails isn’t as entirely smooth as you imply.
You may know exactly what to expect, but I guarantee the consumer faces at least some confusion at best in most cases.
I’ll also guarantee you that when they call their ISP it’s almost certain to be a very confusing conversion on both sides of the phone, especially if they are using any of the really big providers that have call centers full of people that can’t deal with anything beyond the script they barely know how to read (if that) and the 4 or 5 buttons they’re allowed to poke to (send a it to your modem, re-flash your modem’s firmware, “test” your modem’s reachability, produce a delay to make the customer think they did something, or escalate the call to someone that will never actually call the consumer).
Owen