> Do you use actual internet addressing?
Yes. I use global routable constant IPv4 and IPv6 addresses for all the hosts on my main LAN, no NAT, no RFC1918 addressing required.(Although I do use RFC 1918 addresses internally; for talking to modems. The modems’ admin interface addresses are exposed as 192.168.n.1 when n is 1,2,3,4 the nth modem. The Firebrick routes these addresses across from the link between the Firebrick and each modem’s admin interface and passes traffic onto the main LAN so that the modems can be queried and so forth)
> L2TP:
Yes, I thought about that. But then there’s the cost of AA L2TP, charged per byte of traffic. And the hassle of setting it up given my pain and concentration levels. That would give me 4G instead of 3G though. And it’s only used once in a blue moon anyway.
The current system keeps me going and is truly seamless because the src IP addresses don’t change so no TCP connections that are established need to be broken; so no protocol breakages at all.
IPv6 MTU does not change at failover, but for the normal DSL state, PPP MTU=1500+8=1508 therefore normal IPv4 PDU MTU=1500 bytes and that will drop, a lot, when in the failed-over state, because of the limited MTU of the 3G ‘dongle’ USB NIC (IP PDU MTU is only 1430 or 1440 or something like that). Because IPv4 can not only change MTU on the fly even while a flow is established so that I’m assuming that PMTUD will detect the sudden reduction in path MTU and fix the problem, but IPv4 can fragment packets at intermediate routers not just at the source. So for this reason, I’m assuming that even before PMTUD kicks in and changes the PMTU, the first IPv4 packets can simply get fragmented if need be and again I’m assuming, perhaps rather optimistically, that that isn’t going to be the end of the world if there’s a bit of IPv4 fragmentation on failover, perhaps only short-term, but I’m not willing to reduce the IPv4 MTU permanently even in the normal case and just for the sake of the smoothness if the failover when fragmentation should I hope work and may only be needed for a while. Does a sudden onset of fragmentation get detected and trigger a change in PMTU that some transport layer by Eg TCP can take advantage of to fix the temporarily or permanently limited MTU problem?
It’s really annoying because the reduced MTU of the USB 3G NIC is way below 1500 bytes, for no good reason at all. If anything it should be oversized something like 1600 bytes, to support tunnel overhead. What is incredibly annoying is that AA’s 4G/3G carrier network AQL/Three does not support IPv6 and this from AA, the leader in IPv6 provision, with IPv6 first offered in something like 2002 iirc. Have to use AA’s 6in4 tunnelling to get it to work