MSGID: <10j5jh3$2bn1a$1@dont-email.me> ccd6cc97
REPLY: <497801945c.DaveMeUK@BeagleBoard-xM> 776fd715
PID: PyGate 1.5.2
TID: PyGate/Linux 1.5.2
CHRS: ASCII 1
TZUTC: 0000
REPLYADDR Pancho.Jones@protonmail.com
REPLYTO 3:633/10 UUCP
On 12/31/25 20:19, David Higton wrote:
> In message <10j3tdq$29dt0$1@dont-email.me>
> Pancho wrote:
>
>> On 12/30/25 20:00, David Higton wrote:
>>> In message <10iv40e$1e1ba$1@dont-email.me>
>>> Pancho wrote:
>>>
>>>> IPv6 seems like a world of pain.
>>>
>>> In my experience it just works.
>>>
>>
>> I'm surprised. Accepting that you do not do some of the things I do,
>> like policy routing rules based upon a host computer IP, I'm still
>> seeing servers on the internet that advertise they should work with IPv6
>> but don't. This means they don't fall back to IPv4.
>>
>> I'm not far enough along in my understanding to be entirely confident,
>> but I would be surprised if I were wrong.
>
> I've not encountered anything that's more difficult in IPv6 than in IPv4.
In general, I'm not claiming IPv6 is more difficult. However, I have 30+
years of dealing with and solving the problems of IPv4. Switching to
dual stack IPv6 is introducing new problems, which I need to understand
and solve.
The reason I was looking at IPv6 was to solve some poorly understood
problems I appear to have with a new VoIP SIP provider.
> I'm certain that IPv6 works just as well and as reliably as IPv4; after
> all, it's been in global-scale use for many years now, so all the issues
> have been solved. But there's always scope for something to go wrong,
> like in the example I quoted earlier where there was an IPv6 interface
> that didn't previously exist, and configuring it (which was no more
> difficult than the original IPv4 config, which was done so long ago that
> everyone had forgotten it) simply hadn't been done. Since everything
> mainstream now defaults to IPv6, there were two fault symptoms, depending
> which browser and OS were in use:
>
> 1) The site appeared unavailable;
>
> 2) The site was reached, but only after a delay.
>
> Nothing about it was a problem of IPv6 per se.
>
But in practice, I am having IPv6 problems. Not caused by IPv6 itself,
but apparently by third party misconfiguration. It is no good IPv6 being
good, or my routing implementation being good, if in practice I'm
banging my head against third party problems.
At this stage it is quite possible I have misconfigured something, but
it takes a lot of effort for me to understand each problem, so I discuss
my experience in this public forum to gauge other people's practical
experience.
> I'd be interested to know what "policy routing rules based upon a host
> computer IP" you're using. My router runs OpenWRT. Everything gets
> its IPv6 address via DHCPv6. The traffic rules pick up the device by
> name, so, if the IPv6 address changes, the rules change automatically
> to match.
>
I use permanent VPN tunnels to access the WAN, something like NordVPN.
Some LAN services I specifically want to route through the VPN, some I
specifically want to route over the standard WAN. One way I have
traditionally done this is to using a pfSense router to use a service
internal LAN IP address to decide which external gateway to route over.
Other people might do something similar using VLANs, but my switch
hardware strips VLAN tags.
For the avoidance of doubt, I'm relatively naive w.r.t. networking. I
just knock up the first thing that works, rather than do something
technically orthodox.
--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700
SEEN-BY: 226/30 227/114 229/110 112 134 200 206 275 300 317 400 426
SEEN-BY: 229/428 470 616 664 700 705 266/512 291/111 292/854 320/219
SEEN-BY: 322/757 342/200 396/45 460/58 633/10 280 414 418 420 422
SEEN-BY: 633/509 2744 712/848 770/1 902/26 2320/105 5020/400 5075/35
PATH: 633/10 280 229/426
|
