Help me understand the issue if ISP provides /64 prefix

Installing and Using OpenWrt
1

I have seen a couple of posts where people do not recommend ISPs giving out /64 prefix.
Ex: Here and Here
I am having trouble why. I read up on SLAAC , few good videos for CCNA Related to SLAAC & RA and I find it hard to figure out what is the issue with this config.
Pretty sure I am missing something obvious here but consider this example:

On WAN6 interface I get an ipv6 address 2001:ad:effb:1234:<other 64bits>/64

This being the default gateway, why can't the client devices generate their own IPv6 addresses through SLAAC?
The 1st 64bit will be the network prefix and the other 64bit will be the eui-64 generated address.

Follow-up question:
If this does break SLAAC and one workaround is to

"Split up your /64 LAN after the first 64 bit "by hand" breaking RFC rules.

How do I go about doing this in OpenWrt, are there any examples for it?

2

I'll translate it to IPv4, so you'll better understand it.
wan has IP 10.0.0.2/24 with gw 10.0.0.1
You cannot assign it to the lan as well, nor can you use 10.0.0.2 as gateway for the lan clients. They need to use another subnet, like 192.168.1.0/24 and you'll have to NAT it to reach the internet.
The logic in IPv6 is that they provide you with a prefix to use in your lan, for example 172.16.0.0/20, which would be already routed via the IP of the wan interface, hence NAT is not needed anymore. If they provide you with just a /24 (which let's say is the equivalent of /64) then you would be able to assign it only on one lan interface, without breaking things. Because per design, a /64 is the smallest possible network prefix in order to be able to work with SLAAC.

2 Likes
3

As i.e. RIPE suggests ans ISP should allocate a customer a properprefi, like /56. Between the ISP and the CPE devise you would see a /64 and via DHCPv6 and prefix delegation the CPE would get the prefix which can then be used on the customer lan. Deutsche Telekom for instance does that, that way I can have 256 vlans each with it's own /64 and does not need neighbor discovery proxy or any other ugly hack.

So to answer your question. there is no reason against the ISP gives you a /64 on wan, there are only issues IF your ISP is giving you ONLY a /64.

4

I see, thanks yes this example makes sense.

Yes, infact my ISP does not even provide ipv6, I am using a USB dongle as my WAN6 upstream interface (through rndis) which gets an IPv6 Address in /64 range through DHCPv6.
WIth this I have both Ipv4 and ipv6 to learn.

So in these cases, we have NAT for ipv4. In my situation, I don't really need to have a separate LAN network for IPv6. All I need is a public IPv6 address to my home network devices. In my situation then, I believe I need to set all the IPv6 Settings to "relay" mode - so my Dongle handles sending out IPv6 RA & DHCP messages. (https://openwrt.org/docs/guide-user/network/ipv6/configuration?s[]=downstream&s[]=configuration&s[]=lan&s[]=interfaces#ipv6_relay) while my OpenWrt router just forwards it down to connected devices.

Am I understanding this correctly?

5

I believe this is and will be a prevalent problem that deserves a how-to by someone knowledgable (and that someone is not me). Lots of ISPs are starting to do IPv6 only now, and quite a few of them are only handing out /64 prefixes.

I consider myself knowledgeable when it comes to IPv4, but when it comes to IPv6 I am completely useless beyond a very basic understanding. And I am in the same boat as the OP: My ISP unfortunately only hands out a /64 prefix, I have various VLANs and a separate dedicated AP (also OpenWrt, also spreading VLANs in several wifi networks). For now I "solved" the problem by thoroughly ignoring the issue and disabling IPv6, but I would like to embrace it in the future.

Also, I know about NAT6 but I shy away from what looks like kludge scripts to make it work. From the corner of my eye I noticed that 22.03's switch to nftables will bring native NAT6 without any helper scripts. Would that be a solution to what I and the OP need?

Edit: It's hard to not get frustrated over the utter lack of good "advanced level" IPv6 tutorials. There only seem to exist "beginner level" picture-book tutorials explaining why we need IPv6 and "expert" high-level super-specific tutorials once you know a concrete problem. With nothing in between.

2 Likes
6

So as an unsolicited comment, it might be time to allow eating a few bits into the interface identifier IID (the last 64 bits of an IPv6 address) to allow "clandestine" subnetting in cases when the ISP flagrantly restricts users to a /64....
After all 64 bits for IID are clearly overkill for most networks (that is it seems likely that 56 or 48 bits should be enough as well for SLAAC and friends*)... however that is going to be even further from the IETF's recommendations for IPv6 roll-out than an ISP stingily handing out a /64 only...

) This is a bit annoying, in theory one might work around that by using DHCPd v6 to assign IPv6 addresses, but that is going to run into issues:
a) android devices only supporting SLAAC or rather not supporting DHCPv6
b) IPv6 privacy extensions assuming an 64 bit IID, IIRC (but one does not need to use privacy extensions)*
c) prefix delegation likely not working with bits carved out of the IID space...

**) It is not that for most intents and purposes the prefix alone is not already a strong enough identifier for tracking, and it seems actually less revealing to assign simple consequent IIDs manually, like ${PREFIX}::1, ${PREFIX}::2 instead of leaking potentially globally unique SLAAC addresses as IIDs, but this are off the cuff remarks, s likely I am missing some important reasons why that will not work.

7

[quote="moeller0, post:6, topic:132554]
So as an unsolicited comment, it might be time to allow eating a few bits into the interface identifier IID (the last 64 bits of an IPv6 address) to allow "clandestine" subnetting in cases when the ISP flagrantly restricts users to a /64....
After all 64 bits for IID are clearly overkill for most networks (that is it seems likely that 56 or 48 bits should be enough as well for SLAAC and friends*)... however that is going to be even further from the IETF's recommendations for IPv6 roll-out than an ISP stingily handing out a /64 only...[/quote]

Please, Please, Please, read about the history and why IPv6 works as it works.
Yes, you can "split" an /64 but then you loose i.e. SLAAC. The only exception EVERYONE has settled on are Point-to-Point Links and using /127, and /128(for router IDs). And the reason a/64is a/64is not to be able to have2^64` on a single link layer.

If an ISP hands out only a single /64 then they should read the documentaion of their RIR, like RIPE or ARIN. The RIRs hands out enough space that a single customer should get at least a /56, a business customer at least a /48. If an ISP fails to provide proper service then the customer should complain and switch provider (if possible).

[quote="moeller0, post:6, topic:132554]
*) This is a bit annoying, in theory one might work around that by using DHCPd v6 to assign IPv6 addresses, but that is going to run into issues:
a) android devices only supporting SLAAC or rather not supporting DHCPv6
b) IPv6 privacy extensions assuming an 64 bit IID, IIRC (but one does not need to use privacy extensions)*
c) prefix delegation likely not working with bits carved out of the IID space...

**) It is not that for most intents and purposes the prefix alone is not already a strong enough identifier for tracking, and it seems actually less revealing to assign simple consequent IIDs manually, like ${PREFIX}::1, ${PREFIX}::2 instead of leaking potentially globally unique SLAAC addresses as IIDs, but this are off the cuff remarks, s likely I am missing some important reasons why that will not work.

Yes, its annoying that Android refuses to implement DHCPv6, but: Via SLAAC the phone gets an IP, and via SLAAC the phone gets DNS information.
Also the default since years on Android is that for a new WLAN connection a random mac-address is chooses to prevent tracking a user over different networks. And as my personal opinion: Do you realize that we as a society have a far bigger privacy problem then internet numbers?! Every news site has a bunch of trackers and advertisement; your local police is able to track your phone through the mobile cells; we have cameras everywhere; most people going cash-free, but still people shit their pants because of SLAAC addresses; EVEN that more or less every network manager have privacy extensions enabled, or choose random mac addresses. And your IPv6 lease and prefixes are just as "stable" as your IPv4 address. And in any case, your ISP needs to hand out your user data anyway to local law enforcement. So what is the issue?

But back to topic:
For prefix delegation to work, the network needs a /64 for the uplink, and a dedicated network larger then /64 which can then be delegated to downstream interfaces.

8

I know, but as I said, I consider 64bits a total waste of bits for SLAAC. Sure to keep these bits reserved it is useful to have something randomly using them, but there will come a time when people look again at the number of usable bits in the IPv6 header and I predict that the 64bit IID will be scrapped. But I admit that day is not today.

Most recent IETF RFC on the topic (RFC 6177) has shunned away from user-friendly recommendations like /48... it still recommends larger than /64 but they muddied the water and ISPs are taking that hint.

About the last point, switching providers, I conceptually agree, but that is typically easier if all other things are equal between the ISP alternatives, so IPv6 implementation is one factor to consider, but alas rarely the only one.

I do not argue that SLAAC does not or can not work, my point is that SLAAC as only option is bad (we seem to agree) and one hurdle in trying to make IID bits do other work then pure IID.

Sure, which if not disabled can be a problem for an DHCPv6 based approach, unless the device can be configured to use a stable dhcp ID. I had forgotten about that actually, thanks for reminding me.

IMHO the issue is that using stable SLAAC addresses makes tracking as easy as logging IP addresses... Privacy, similar to security, works in layers, almost no layer by itself offers a significant amount of coverage and all have side-effects, so one has to pick one's poison here and make compromises*. But for me 64 bits because of globally unique SLAAC addresses was/is not an optimal, not even a good decision (short of making sure these 64bits are preserved for future splitting up).

About tracking via the assigned IPv6-prefix we agree (and I made the same point above), but these are typically stable for much shorter durations than SLAAC addresses.

*) I have zero problems with law enforcement here being able to link my network activity with me personally (the luck of living in a reasonably free and liberal country), but that does not mean that I want every miscreant or ad-pusher on the internet being able to do the same without at least putting in some effort.

9

Playing devil's advocate for a minute, but if it were reasonably possible to subnet a /64, clueless ISPs wouldn't give you a full /64 anymore and the vicious circle would start somewhere else…

4 Likes
10

ISPs can effectively already give out /128 if the so desire, but most ISPs do not do this. The 64/64 split is quite convenient even for ISPs. But you are right nothings would stop ISPs from doing that, but unless they have actual use for those bits as well, I do not see this likely to happen, even if we would find a way of clandestinely extending prefix delegation into the canonical IID space, but I am not working on an actual implementation of that, so this will likely stay a purely theoretical musing.

11

One simple solution would be altering the OpenWrt default configuration to preconfigure RA/DHCPv6/NDP services on wan6 and lan in hybrid mode and designating wan6 as odhcpd master interface.

This way you should get the normal DHCPv6-PD for sane ISPs and fallback to relaying/proxying for /64-only cases. The odhcpd daemon is supposed to switch the operating mode automatically, depending on the presence of a delegated prefix.

This will solve the problem for only one downstream interface though, additional ones would still require NAT6 or split subnet + routing tricks. But I guess a hybrid-by-default config would cover most common use cases.

1 Like
12

I believe that /64 only are common for mobile carriers, so this proposed change might make it easier to include such a mobile link as (backup?) member in a multi-wan setup.

1 Like
14

I've been trying this out. I don't fully understand it yet. I have a T-Mobile USA MiFi which is dual stack. It provides a /64 IPv6 address. There are no settings in its UI other than a checkbox to enable / disable IPv6 completely.

Then I have two OpenWrt routers in series. The first one is connected by WiFi to the MiFi. The second one has an Ethernet VLAN to the first one, and Ethernet or wifi to endpoint devices. This setup has been working for IPv4 as double-NAT; I don't care about NAT since the service is CGNAT anyway.

The trick to getting it to work at all is in an old post to use relay mode.
/etc/config/network:

config interface lan
    option ip6assign '64'

config interface wan6
    option ifname '@wan'
    option proto 'dhcpv6'

/etc/config/dhcp

config dhcp 'wan6'
    option interface 'wan6'
    option dhcpv6 'relay'
    option ra 'relay'
    option ndp 'relay'
    option master '1'

config dhcp 'lan'
    < usual ipv4 settings >
    option dhcpv6 'relay'
    option ra 'relay'
    option ndp 'relay'

I did this on both routers, and IPv6 seems to be working. On my laptop, sites like test-ipv6.com report 10 out of 10 tests passed. But is this really secure or the best way?

My other question is now that this is an IPv6 house, how do I connect lan-lan with IPv6? Is there something like a DHCP lease so that local names can be looked up to access a LAN machine?

15

Given your limitations, it's that or nat6.
For the second question, you have to use IPv6 gua addresses,but if there is no DHCP lease then it is hard to find which device has which address.