[Solved] Prefix delegation problems

Installing and Using OpenWrt
1

Hi,

I've a FritzBox 6591 handing out PrefixPD to my routers. They are connected all over WAN interface with a switch between Fritzbox and Routers. Each LAN is getting its own Prefix. Recently I had a power failure. The devices were starting up with different speeds.
I realized that two of them suddenly had changed their prefixes.

RouterA had 2xxx:xxxx:xxxx:5550. Now its ...5551.
RouterB had 2xxx:xxxx:xxxx:5551. Now its ...5550.

On the FritzBox I didn't found any setting to influence the prefixes delegated to the devices.

I've found "Custom delegated IPv6-prefix" on OpenWrt.
If I change this I'm getting the old prefix and the new one I've defined under "Custom delegated IPv6-prefix".
How can I prevent OpenWrt to use/assign the other prefix which FritzBox is offering in addition to the one I've defined?
I avoided to restart Fritzbox so far. Maybe it will delete the "lease" for the other delegated prefix. But that would not solve the problem if I have same situation again. Any idea?

2

Tough situation. The Fritz should be able to distinguish somehow which prefix to delegate to each router. By using the custom delegated prefix you can have conflicts. If no one has a better idea, I'd advise you to go for static.

2 Likes
3

Yes this is really ugly. I can define static leases for IPv4 as usual (bound on MAC). But I cannot control anything for IPv6.

The FritzBox is giving away the prefixes in the order devices are requesting. Starting from xxx1.

The only option came in mind so far was to replace the switch in front with a router, grab the delegated /57 and delegate further down to the other routers. Even more ugly. Esp. for what I do have prefixes. ... USV for routers? Never thought about. -.-

Thx for this input. Was not aware of this so far.

4

If your prefix is not dynamic and provided there is some option in fritz, that would be a working alternative.

1 Like
5

Is this OpenWrt fork?
Can you connect with SSH?

1 Like
6

I don't have SSH access to this box and I doubt its OpenWrt based. It is a provider box. The only "hack" I have for this is to save the config into a file and decrpyt it. I have a script for that and activated requesting a -/56 prefix instead a -/62 in the past already. But it has 4k lines and another 1k lines extra crypted (guess by provider). I was looking into already. Didn't find any hint for so-called fixed prefix delegation. Maybe it exist, maybe it even doesn't exist.

For the moment I've deactivated wan6 on all connected routers and I'm activating it on boot over rc.local "manually" with different time delay now. So if another power failure will hit (very rare anyway) each device is getting its desired IPv6 prefix.
Not beautiful but it works.

IPv6 itself

ipv6 {
        ulamode = ulamode_dynamic;
        use_default_ula = yes;
        ula = fd00::;
        use_fixed_mtu = no;
        fixed_mtu = 1280;
        dhcpv6lanmode = dhcpv6lanmode_statefull;
        dpcpv6_default_pdlen = 56;
        dhcpv6_preference = 0;
        dhcpv6c_use_wanted_prefixlen = yes;
        dhcpv6c_wanted_prefixlen = 56;
        dhcpv6c_use_rapid_commit = no;
        radv {
                MinRtrAdvInterval = 450;
                MaxRtrAdvInterval = 600;
                AdvDefaultLifetime = 1800;
                DefaultRtrPreference = 0;
                PreferedLifeTime = 3600;
                ValidLifeTime = 7200;
                AdvDNS = yes;
                OtherPrefixesAllowed = yes;
                AdvRouteInfo = yes;
        }
        ip6_6to4static_cfg {
                popaddr = 0.0.0.0;
                local = ::;
                remote = ::;
                prefix = ::;
                prefixlen = 0;
        }
        ip6_6rd_cfg {
                popaddr = 192.88.99.1;
                prefix = 2002::;
                prefixlen = 16;
                ipv4masklen = 0;
        }
        ip6_static_cfg {
                prefix = ::;
                prefixlen = 56;
                wan_use_firstprefix = yes;
                wan_prefix = ::;
                wan_ifid_automatic = yes;
                wan_ifid = ::;
                wan_dns1 = ::;
                wan_dns2 = ::;
        }
        he {
                update_server = "ipv4.tunnelbroker.net";
                tunnel {
                        popaddr = 0.0.0.0;
                        local = ::;
                        remote = ::;
                        prefix = ::;
                        prefixlen = 0;
                }
        }
        aftr = ::;
        manual_aftrfqdn = "";
        use_gw_as_pcpserver = no;
        lan_dns6_server = ::;
}

For a device:

landevices {
        landevices_version = 3;
        landevices {
                ip = 192.168.178.xx;
                manual_ip = yes;
                uniqid = 2346;
                name = "OpenWrt";
                neighbour_name = "OpenWrt";
                mac = ;
                auto_etherwake = no;
                ifaceid = :::::;
                staticlease = yes;
                ipv4forwardrules =
                                   "udp 0.0.0.0:4500 192.168.178.xx:4500 0 mark 1 # wg0",
                                   "udp 0.0.0.0:4501 192.168.178.xx:4501 0 mark 1 # wg1";
                ipv4_exposed_host = no;
                ipv6firewall {
                        enabled = yes;
                        exposed_host = no;
                        ping6_allowed = no;
                        fw_open_for_prefix = no;
                        rules = "UDP 4500 mark 1 # wg0",
                                "UDP 4501 mark 1 # wg1";
                }
                allow_pcp_and_upnp = no;

What I do not understand it has assigned and uniqid, mac and ifaceid (reverted mac) to each device. So it should not be a problem for the box itself. Maybe the option has just to be added. But there are not so many FritzBox configs outside to compare.

1 Like
7

Have you already experimented with "ip6hint" and "ip6prefix" options?

3 Likes
8

One general comment:
Devices might have several ipv6 addresses. For outgoing traffic, the random prefixes & addresses give some additional security. The "preset" known prefixes are mostly necessary for incoming traffic, so that you can reach the devices via DNS names and defines exceptions to firewall, if necessary.

So I am not sure if having additional automatic prefixes would hurt if the device can still be reached also with the prefix that you have set by yourself.

2 Likes
9

So far not. I will do that if I have time. Today I probably don't have time to test. But I will do and give feedback.

Me neither. I have IPv6 for like a half year now. So I'm kind a noob when it comes to IPv6.

I guess I have to try it. :smiley:

10

Looks like radvd.
Is there only one downstream interface?
Is it possible to add another one?

Can you check on OpenWrt:

ifstatus wan6
1 Like
11

Nice catch. But I don't have any clue about radv. I have to read through first which need time.
Do you mean with downstream interface the devices connected to Fritzbox? Like "landevice" I've posted above (2nd part of config). If yes then there are 4 landevices defined. 3 Routers (getting prefix delegation) and 1 Raspi acting as DNS resolver (getting an IP only). Or do you mean another "radv" section?

For one Router:

{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 46002,
        "l3_device": "eth0.2",
        "proto": "dhcpv6",
        "device": "eth0.2",
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2222:2222:2222:5500:4af3:15ec:d8b6:8735",
                        "mask": 64,
                        "preferred": 1425,
                        "valid": 7012
                },
                {
                        "address": "fd00::4af3:15ec:d8b6:8735",
                        "mask": 64,
                        "preferred": 3412,
                        "valid": 7012
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2222:2222:2222:5540::",
                        "mask": 58,
                        "preferred": 2592,
                        "valid": 6192,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2222:2222:2222:5540::",
                                        "mask": 64
                                },
                                "zguest": {
                                        "address": "2222:2222:2222:5541::",
                                        "mask": 64
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "2222:2222:2222:5500::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 7012,
                        "source": "::/0"
                },
                {
                        "target": "fd00::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 7012,
                        "source": "::/0"
                },
                {
                        "target": "fd00::",
                        "mask": 64,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "::/0"
                },
                {
                        "target": "2222:2222:2222:5500::",
                        "mask": 56,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "2222:2222:2222:5540::/58"
                },
                {
                        "target": "2222:2222:2222:5500::",
                        "mask": 56,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "2222:2222:2222:5500:4af3:15ec:d8b6:8735/64"
                },
                {
                        "target": "2222:2222:2222:5500::",
                        "mask": 56,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "fd00::4af3:15ec:d8b6:8735/64"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "2222:2222:2222:5540::/58"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "2222:2222:2222:5500:4af3:15ec:d8b6:8735/64"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::aabb:ccdd:eeff:e34a",
                        "metric": 640,
                        "valid": 1612,
                        "source": "fd00::4af3:15ec:d8b6:8735/64"
                }
        ],
        "dns-server": [

        ],
        "dns-search": [
                "lan"
        ],
        "neighbors": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [
                        "fd00::9a9b:cbff:fe92:e34a"
                ],
                "dns-search": [

                ],
                "neighbors": [

                ]
        },
        "data": {
                "passthru": "stripped"
        }
}
1 Like
13

Is this the same for the other router?

1 Like
14

For other router it is:

"address": "2222:2222:2222:5580::",
"mask": 57,

For the 3rd router I cannot give atm. Because I've disabled IPv6 on this for now. Just to have one factor less if FB is handing out prefixes. Like watch and learn what is going on. ^^

But I guess I've already changed to much. Before I got /57 for all devices.
The /58 I've got (if I remember correct) after adding "Client ID to send when requesting DHCP" to that router. I've added "0EBF". So the length is mandantory (I think).

1 Like
15

If I understand correctly, when the server issues a prefix, it adds a route to the prefix via the client IP.
Thus, a custom static prefix may not work unless the client explicitly uses some option to request it.

Something like this:

1 Like
16

Well I don't have much options. I think the route is added due to options for IPv6 in FB. It changes nothing in terms of prefix delegation. The route is just removed if I change back from:

Assign DNS server, prefix (IA_PD) and IPv6 address
to
Assign DNS server and IPv6 prefix (IA_PD)

fb
fb1669×1481 218 KB

Well I think its a waste of time already. There is no option on FB to influence prefix delegation. I have no clue what is the "standard" for that. Do the client has to request propberly or do the "delegator" has to decide what to do?

1 Like
17

Looks like IA_PD is stateful and should be included in the DHCPACK:


You can try to capture it to modify and use with reqopts later.

On the other hand, odhcp6c has this option:


Perhaps it can make custom prefixes work properly.

Unfortunately, I have no native IPv6 to test it.

18

This overcharges me a bit. :smiley: ... What could I try to capture? I changed verbosity of odhcpd to 7 already. Nothing about PD negotiations. I would not even know which numbers I have to enter for reqopts. Does it make sense to fire up tcpdump and watch out for sth. usefull?

I saw this option also already. For me it sounds like "Custom delegated IPv6-prefix".
How would the syntax look like?

As I can see so far this is a bit more complicated and time consuming then I expected at the beginning. I have to switch off my whole network every time to reset everything and see if sth. has changed. Because as long FB is up every router is getting the same prefix after restart/changes as it had before.

19

I've found a temporary solution for (my needs):

My Routers are getting /57 prefixes automatically usually.
I've changed them to 57 for Router 1, to 58/ for Router 2 and /59 for Router 3.
This is working relayable.

I've tested also with assigning an IPv6 to the WAN interfaces to the Routers (I didn't do that before) in connection with the option
"Client ID to send when requesting DHCP" on Router side. It looks promising. Need more testing.

Next step will be a full reset of the FritzBox.

Thx for help so far @all. :slight_smile:

1 Like
20

So after resetting the box it seems everything is running as intended. I cannot track the issue down anymore. What I can say it is running relayable if I activate the assigning an IP over DHCP to the client rouers on FB and if I enable on OpenWrt side client id sending (prob. not necessary).

I can see now on FB side config that if I add a IPv6 device it's saving an IP (with mac included). It might be that I've changed MAC on devices and saved it only with IPv4 enabled as static device on FB. So not data entry for IPv6 saved on FB. Then it is like every time a new device is requesting IPv6 PD and first device asking is served with the first available PD. Sounds logical. :confused:

Thank for helping again. :slight_smile:

2 Likes
21

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.