Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[aesmith]

AESmith uses IPv6 NAT, which is where he and I differ.

I don't at the moment, although I was advocating it as an alternative to PI for an organisation with more than one ISP, or one that wants to be able to change ISPs without renumbering their internal network.

It would still silently screw all your open TCP connections though, which is the nastiest of all possibilities.

Would it?  I understood that the prefix was changing on a router reboot and presumably other disconnect/reconnect scenarios.  I didn't read this as meaning it changes "hot". 

Having said that I can't understand why they'd not make the assignments static, they can't be short of address space.  That wouldn't be an issue anyway with DSL or other always-on connections, since they use the same amount of address space whether static or dynamic.  What they should be doing, in my opinion, is to assign a fixed prefix to the customer but then to push it out via prefix delegation.  That would be the equivalent of most ISPs on IPv4, and saves most customers having to hard-code the prefix in their router.

[Weaver]

Well, whenever a local-end IP address changes, then an o/s, if it knows about the change, needs to dump all TCP connections, as otherwise of course a remote correspondent receiving subsequent TCP PDUs will have no idea about who is the strange person sending these packets with an incomprehensible new src address in them, as they won't match the appropriate field in the remote’s TCP connection object. (I once made this mistake when I was designing an implementation of a novel transport protocol many years ago.) Of course, if an o/s doesn't know about the address change, then it can't do anything about it: a local sender just keeps on retransmitting and a remote end keeps throwing incoming packets away or firewalling them out.

I suppose a clever o/s might pick up a new router advertisement and pass it up to TCP subsystems, but does an RA mean that you've _lost_ the old addresses you had or just that you've just gained some additional ones? I'm not at all sure. What about multihomedness or multiple gateways? This isn't the same as DHCP expiry. I rather doubt that these mechanisms were designed with such craziness in mind. I've never heard of a “negative RA”-type mechanism.

But no network designer can go around assuming that all possible operating systems have that behaviour. And what if you aren't even producing RAs driven by some dynamic mechanism, like DHCPv6 from-the-ISP (how?) or PPP IPCP ? My router is just set up to generate RAs based on static configuration. So if an ISP changed a prefix, then then I'd never know. So Sky aren't going to sell to many Firebrick owners!

[aesmith]

My point was not particularly to support dynamic allocation, but just to point out that if it occurs only on a router reboot there's not going to be a lot of traffic "in flight" at the time.   The whole prefix delegation thing is something I haven't played with, and in theory it should allow things to readdress in due course, but I'm sure it is intended for provisioning and for pushing out planned change not for on the fly unscheduled changes.  Apart from anything else it wouldn't work if the customer has anything statically addressed.

I suspect in Sky's case it's just not really been thought through, in terms of how much more disruptive a change of prefix is compared to a change of external IPv4 address.   Are Sky providing and supporting a router supporting their IPv6 provision?  Would be interested to know how they handle all this on their chosen box.

[Chrysalis]

Weaver NAT is not needed on sky's setup, each device still gets its own ipv6, so there is no sharing.

But it is annoying that it means things like setting up a tbb monitor is difficult and in addition any configuration files have to be changed whenever it changes.

To solve the latter problem I have already made a script which fetches the prefix and then will regenerate my config files using that prefix.  However I am still annoyed about the prefix changing so easy, my connection is very reliable and will stay up for several months at a time, but I dont like been in the position where i am scared to reboot the router, do maintenance etc. for in fear of losing my ip address.

Some people on the skyuser forums are been very defensive of sky's setup, so I am in disagreement with them, apparently for the others their prefix does survive a router reboot, but it doesnt for me.  Although one guy gave me a few reasons why it might be happening which I am going to look into.

A change of prefix probably wont disrupt joe bloggs to be fair, most consumers dont care about static ip configurations.

[Chrysalis]

Quick update, the prefix actually has a 7 day expiry, and the reason I was losing it was that dhcp6c on my router sends a RELEASE command when its shutdown.  Temporary solution I have currently is to kill dhcp6c manually instead of shutting it down with its init script.  I cannot edit that init script sadly as it is hard coded but will speak to the dev about it.

I still have the issue the /64 prefix within that /56 keeps changing but the dev of the firmware I am using is going to make a new firmware later today with a newer wide-dhcp client which will hopefully fix that issue.

[aesmith]

I still have the issue the /64 prefix within that /56 keeps changing but the dev of the firmware I am using is going to make a new firmware later today with a newer wide-dhcp client which will hopefully fix that issue.

Is that wholly within your gear, I mean Sky issuing the /56, and your equipment deciding which /64 prefix to use on the LAN?   Wondering if your script could have a hard-coded mask so it always assigns a certain /64 within the current ISP issued block?

[Chrysalis]

I need to correct myself.

My last post was based on me thinking a /56 is the first 3 fields only, its actually the first 3 plus half of the fourth, I was confusing with a /48 which is the first three.

So the /56 was still changing not the /64.

Now to answer your question aesmith yes I can choose which /64 to use, the sla-id function within wide-dhcp controls that.

I have a couple of problems right now, one is a minor annoyance, the other one is quite bad.

1 - The minor problem is the router gets its wan ip in EU64 format, wide-dhcp does have a ifid function where you can make it use a friendly ::1 but that was never implemented in the wide-dhcp code (which got abandoned in 2008) and only added by some linux distro versions of wide-dhcp.  I grabbed the debian patches and gave them to the dev of the firmware, but he is definitely not keen on implementing them as he is paranoid about changing ipv6 code, I even supplied him prepatched files, time will tell if I can convince him.
2 - The bigger problem is when dhcp6c is been shutdown on my router it is sending a release command to sky's dhcp servers, this is why the /56 has been changing.  Someone on skyuser forums also uses wide-dhcp and does not have this problem but he runs the patched version on ubuntu, I think he doesnt realise how different things are on embedded systems, I cannot just download a debian package and install it on a router.

if dhcp6c is shutdown by the rc command, /56 is lost.
if dhcp6c is shutdown with a kill command without arguments /56 is lost.
if dhcp6c is shutdown with a 'kill -9' command (which instant terminates so does not allow it to do its shutdown routine) the /56 is preserved and is sticky.

Sadly the rc script is not accessible on the router, and if it was it be read only.  So this to be fixed requires the firmware dev to resolve it.  I have made a shutdown script for it which force kills it using the -9 signal, but this will rely on me remembering to use it before reboots, going offline etc. and if the router ever goes offline by itself e.g. an isp outage it will run the rc shutdown script for dhcp6c although if the isp is dead it probably would not recieve the release command to be fair in that situation.

To automate it? well asuswrt-merlin has wan-start scripts, meaning you can insert commands to be run whenever the wan is brought online, but it does not have a wan-stop script for automation when wan goes offline.  However since sky uses dhcp auth, the dhcp-event script may work which is ran whenever there is a dhcp change on the wan interface. However I think that wont be an option since when the ipv6 prefix comes online that will be a dhcp event and I would then be instant killing it.

I could also try to firewall of the release command, but I think this will be impossible unless they somehow use packets identifiable by iptables.  There is nothing in wide-dhcp documention I can see in relation to release commands been sent, it would appear its hardcoded and I think one of the debian/ubuntu patches patched it out.

[Weaver]

@Chrysalis - want a spare Firebrick ?   

Love and peace, shame about the system software nuisance.

[Chrysalis]

Massive progress made, he applied the patches no problem.

The only issue left to resolve is the release command, which I expect we will solve by making the rc script forcefully kill it with -9.

The router now gets a friendly formatted ipv6 now ifid works.

[Weaver]

Glad to hear that you're making progress. Good news.