Why we need a DHCPv6?

[Zucca]

Ok,

exciting news....

My ISP is giving me a IPv6 /56 block!  and it works!

Now I set up two /64 LANs behind the pfSense firewall as tracking interfaces with two different prefixes.

My clients get their IPv6 automagically from the WAN IPv6 /56 according to the LAN tracking prefix... so far so good.

Now I have a philosophic dilemma.

Why we need DHCPv6?

As I understood my stuff get the IPV6 from the /56 WAN automagically. I do not have to setup anything to provide an ip to my clients.
If I need to reach one of my clients from outside it is just a firewall and static dns business?

I mean sure DHCPv6 is useful, but for average Joe that get a /56 from ISP.... Do I need it if ISP is giving me the IPv6 I want (=right prefix)?

PS: Interesting discussion

[Cerebus]

Well, if you want predictable static addresses for machines you can no longer rely on the machine's MAC address forcing a particular choice of address by auto-configuration. This is because some OSes now randomise their auto-configured IPv6 addresses for privacy reasons (to hide the MAC address).

So to get a predictable address you need to either manually configure it statically (messy, but doable), or hand the task over to a DHCP server where you have centralised control. On a home network it's probably OTT to fire up a DHCP server to do this unless: (1) You're doing it to learn, (2) you think it's fun sysadmining stuff, or (3) you want to configure some automated failovers or do other orchestration (unlikely on a home network unless you're a sick puppy like me).

I do run a DHCP server for both v4 and v6 but my 'home' network gets used for all sorts of networking experiments and tests, either for self-education or to simulate setups for 'work'. I like the central record of what's currently configured as what, and it makes it much easier to repurpose a machine for something else (e.g. I have a remote manageable server with lights out management that I irregularly spin up as different things VMWare, Xen, and so on and with appropriate addresses for each identity it has).

For most folks, even people with relatively complex home networks, I wouldn't say you need a DHCP server to manage unless you have a good reason to do so. Do you already have a machine dedicated to server type tasks such as DHCP, DNS and so on? If the answer is 'no' and you're going to have to fight some consumer router's perverted idea of how to implement a DCHP server then I would say "Steer clear".

[Zucca]

Well first of all you have all my respect to have so many eth cables at home.
I am a small fish, I just want to learn because I believe knowledge is the real power.

Sooooo I have my humble pfSense box which is doing a great job for firewall, DHCP, DNS Resolver and now I got my hands dirty with IPv6.

In my planet DHCP basically take off the work to set a fixed ip to clients so they can talk on the network without the pain to set a proper number each box.
Since the WAN in IPv4 has only ONE ip, the NAT is basically a call for some DHCP (many clients needs to talk to the gateway in the network to reach internet).

Here I am facing a new animal, IPv6.

As far I understand it, the new protocol is designed to give automatically an ip to each client WITHOUT a DHCP running in local the network. No NAT --> No need for a Gateway ---> you can survive without DHCP.


I would like to get a beer with you so I can explain myself better, I hope it makes sense what I wrote.

[mansaxel]

Well first of all you have all my respect to have so many eth cables at home.
I am a small fish, I just want to learn because I believe knowledge is the real power.

Sooooo I have my humble pfSense box which is doing a great job for firewall, DHCP, DNS Resolver and now I got my hands dirty with IPv6.

In my planet DHCP basically take off the work to set a fixed ip to clients so they can talk on the network without the pain to set a proper number each box.
Since the WAN in IPv4 has only ONE ip, the NAT is basically a call for some DHCP (many clients needs to talk to the gateway in the network to reach internet).

Here I am facing a new animal, IPv6.

As far I understand it, the new protocol is designed to give automatically an ip to each client WITHOUT a DHCP running in local the network. No NAT --> No need for a Gateway ---> you can survive without DHCP.


I would like to get a beer with you so I can explain myself better, I hope it makes sense what I wrote.

Ok, this is how it works:

For autoconfiguration, you've got SLAAC. Stateless Link-local Address Auto-Configuration. What it does is give a mechanism to make hosts discover which /64 prefix is suitable to use on the LAN. The router(s) periodically send out two things;

• The prefix, like "2001:DB8::/64"
• The list of addresses to suitable routers that will carry traffic out of the LAN.

The host, normally, takes the prefix and tacks its MAC address on it, stuffing 0xfffe in the middle to pad the length to 64 bits.

2001:0DB8:0000:0000 + dead:be + ff:fe + ed:dada = 128 bits.

Now, this has been deemed unsafe and leaky, since the MAC address will make a single host trackable through the Net. Therefore, we've got Privacy Extensions for SLAAC.  Then, the host will at intervals pseudo-randomise a host part to tack on the prefix:

2001:0DB8:0000:0000 + <64 bits of goobledygook> = 128 bits.

Now, this will give you connectivity, but not sundry items like addresses to DNS resolver, TFTP server, NTP server et c. 

Enter DHCPv6. Which, of course, because it's got its fans, also lets you give hosts addresses. 

Now, a bit of a peek under the hood:

IPv6 does not have ARP, nor broadcast. What it's got is a combination of two things:

• Link-local multicast for advertisements.
• Locally scoped addresses for link-local communication.

Any host that enables IPv6 on an interface also auto-configures a link-local address using the prefix FE80::/64. This address can only be used on that local net, but is then of course enough to use as default gateway. Also, it's used to send (and if one bends truth a bit) receive multicast packets, like RA and DHCPv6, as well as Neighbour Discovery, which replaces ARP in finding other hosts on the LAN.

That's about it.

[nfmax]

I thought the SLAAC privacy extensions were that - just extensions? So that the stable MAC-based IPv6 address is still present, for incoming connections to use, while outgoing connections, e.g. from browsers, use an address which will change over time?

Use of the extensions defined in this document may complicate
   debugging and other operational troubleshooting activities.
   Consequently, it may be site policy that temporary addresses should
   not be used.  Consequently, implementations MUST provide a method for
   the end user or trusted administrator to override the use of
   temporary addresses.

I may of course be wrong. It happens sometimes

[Zucca]

Thanks mansa!

This weekend I will digest and study your post. I understood the general stuff but I want to dig into the details...

Anyway good stuff here too

[mansaxel]

I thought the SLAAC privacy extensions were that - just extensions? So that the stable MAC-based IPv6 address is still present, for incoming connections to use, while outgoing connections, e.g. from browsers, use an address which will change over time?

Use of the extensions defined in this document may complicate
   debugging and other operational troubleshooting activities.
   Consequently, it may be site policy that temporary addresses should
   not be used.  Consequently, implementations MUST provide a method for
   the end user or trusted administrator to override the use of
   temporary addresses.

I may of course be wrong. It happens sometimes

It is my experience that no, the hardware-derived address is not configured on an interface where Privacy Extensions have been enabled (in reality not disabled; they're on by default on many places). Also, the FE80::/ address is randomised, at least on OS X which is what I can look at here right now.

Code: [Select]

treize:Public mansaxel$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether <snip>30:89
inet6 fe80::1866:5891:35e:45d2%en0 prefixlen 64 secured scopeid 0x5
inet <snip>netmask 0xffffff00 broadcast <snip>
inet6 <snip>:86f:48d6:fc34:f210 prefixlen 64 autoconf secured
inet6 <snip>:4f:c795:4c40:ff4e prefixlen 64 deprecated autoconf temporary
inet6 <snip>:2509:6b3c:8c79:54cf prefixlen 64 deprecated autoconf temporary
inet6 <snip>:803c:3a2:bcc3:6705 prefixlen 64 deprecated autoconf temporary
inet6 <snip>:45a7:91f:3182:a680 prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
treize:Public mansaxel$


None of those addresses have 0xfffe in the middle, which tells us they're not SLAAC

[ejeffrey]

Ok,

exciting news....

My ISP is giving me a IPv6 /56 block!  and it works!

Now I set up two /64 LANs behind the pfSense firewall as tracking interfaces with two different prefixes.

My clients get their IPv6 automagically from the WAN IPv6 /56 according to the LAN tracking prefix... so far so good.

Now I have a philosophic dilemma.

Why we need DHCPv6?

As I understood my stuff get the IPV6 from the /56 WAN automagically. I do not have to setup anything to provide an ip to my clients.
If I need to reach one of my clients from outside it is just a firewall and static dns business?

I mean sure DHCPv6 is useful, but for average Joe that get a /56 from ISP.... Do I need it if ISP is giving me the IPv6 I want (=right prefix)?

PS: Interesting discussion

Many if not most endpoint devices do not need DHCPv6.  If stateless address assignment + neighbor discovery protocol are enough for you then you don't need DHCP.

DHCP allows for more capability and flexibility if you need it.  For example, stateless autoconfiguration only works for /64 subnets.  Your router is using DHCPv6 to get the /56 subnet from your ISP to use with prefix delegation. DHCPv6 can also be used to configure network booting, set vendor options like network management controller addresses, assign fixed addresses to known hosts, and trigger DDNS updates.

[JohanH]

I've been using an IPv6 tunnel for years, so long that I've almost forgotten how it works. I do use RA and SLAAC, not DHCPv6. Keep in mind Android doesn't work with DHCPv6. If you don't believe, look at this ten year old bug https://issuetracker.google.com/issues/36949085. I see no reason to use DHCPv6 myself, so I really don't care. Looks a bit like corporations need it for control, from the desperate posts in the bug. The bug is kind of hilarious, I can't believe this guy refuses to implement it. Sounds like he refuses on purpose, due to all rude requests.

[ejeffrey]

Well, specifically because DHCP does not provide any additional functionality over SLAAC that android uses.  All of the DHCP optional fields are ignored by Android even in IPv4, and adds ways for things to go wrong (worse network roaming behavior, potential to not get extra addresses for tethering, inability to use ephemeral addresses for privacy).

[madires]

IPv6CP (part of PPP) doesn't negotiate IPv6 addresses (as IPCP does for IPv4 addresses). So IPv6 addresses need to be managed by NDRA or DHCPv6. The additional IPv6 prefix is assigned via DHCPv6 PD (Prefix Delegation). In some cases you want to run stateless DHCPv6 in a LAN to provide additional configuration settings which aren't supported by SLAAC. Some settings were added to SLAAC, but a client's implementation might not support those newer settings. Another reason to run DHCPv6 in a LAN is to run downstream prefix delegation for other routers.

[ve7xen]

Well, specifically because DHCP does not provide any additional functionality over SLAAC that android uses.  All of the DHCP optional fields are ignored by Android even in IPv4, and adds ways for things to go wrong (worse network roaming behavior, potential to not get extra addresses for tethering, inability to use ephemeral addresses for privacy).

Which is all well and good until you need DHCPv6 address assignment for some other device/reason on the same network you want to put Android devices on. SLAAC and DHCPv6 address assignment can't coexist on the same network.

In some settings it's also important to keep track of which device was using which IP when, which is not possible with SLAAC.

[ejeffrey]

Well, specifically because DHCP does not provide any additional functionality over SLAAC that android uses.  All of the DHCP optional fields are ignored by Android even in IPv4, and adds ways for things to go wrong (worse network roaming behavior, potential to not get extra addresses for tethering, inability to use ephemeral addresses for privacy).

Which is all well and good until you need DHCPv6 address assignment for some other device/reason on the same network you want to put Android devices on. SLAAC and DHCPv6 address assignment can't coexist on the same network.

The key phrase is "address assignment"  DHCPv6 can be stateless (using SLAAC for address assignment, then DHCPv6 for additional options) or stateful (SLAAC disabled, address + options transmitted by DHCP).  So you can support the additional features of DHCP (including prefix delegation and others) alongside SLAAC for address assignment, this is the most preferred configuration for client devices, and I have yet to see a good argument for DHCPv6 *address assignment* on a client network that a mobile device would connect to.  I do sympathize with the argument that android should implement what people use regardless of whether it is a good idea or not.

In some settings it's also important to keep track of which device was using which IP when, which is not possible with SLAAC.

It really isn't possible to do that with DHCP either.  Some clients randomize MAC addresses specifically to avoid this tracking.  If you want to track devices you need an authenticated network where you associate an actual identify with the client.  Once you have that DHCP doesn't provide additional tracking capability.

[Jeroen3]

I mean sure DHCPv6 is useful, but for average Joe that get a /56 from ISP.... Do I need it if ISP is giving me the IPv6 I want (=right prefix)?

I don't have it configured ND does it's job fine.
Most devices that need the firewall to be open don't do address randomization anyway.

[ve7xen]

The key phrase is "address assignment"  DHCPv6 can be stateless (using SLAAC for address assignment, then DHCPv6 for additional options) or stateful (SLAAC disabled, address + options transmitted by DHCP).  So you can support the additional features of DHCP (including prefix delegation and others) alongside SLAAC for address assignment, this is the most preferred configuration for client devices, and I have yet to see a good argument for DHCPv6 *address assignment* on a client network that a mobile device would connect to.  I do sympathize with the argument that android should implement what people use regardless of whether it is a good idea or not.

Yes, that is why I said "address assignment". There are a variety of reasons you might want this. You might want to do address reservations. You might want to do dynamic DNS. You might want to use different-sized networks for some other (dubious or not) reason.

It really isn't possible to do that with DHCP either.  Some clients randomize MAC addresses specifically to avoid this tracking.  If you want to track devices you need an authenticated network where you associate an actual identify with the client.  Once you have that DHCP doesn't provide additional tracking capability.

In theory yes. In practice you need both in many cases, as connecting the address to a port authentication event later may be non trivial. And you don't really need port authentication to get most of the way there, as DHCP clients will generally send their identity in their requests, while this is obviously not the case with SLAAC (in fact the opposite is usually true, with most devices using privacy extensions these days). In some environments you may even be able to enforce and relatively 'trust' this behaviour via your endpoint management system.

In an ideal world, sure, SLAAC is probably sufficient, but we live in the real world and DHCP makes a number of things considerably easier, and is without a doubt a lot more flexible. Sure many of those things may be dubious from an ivory tower view.

[Zucca]

Thanks everybody for the interesting discussion.
Hard to believe IPv6 is still such a beast to implement in Android, we are in 2022 

I am still having a hard time to understand how DHCPv6 works with tracking interfaces, for example...
That said, I do not see the point to run at home IPv6 to address internal Lan devices.
IPv4 is plenty for my home. Interesting is to have IPv6 to talk to internet through the WAN, where my trusty pfSense is acting as a wonderful firewall.
If we could look with a "IPv6 binoculars" through the WAN we could see so many "stars" (and growing) that with ipv4 we were not able to get.

Morewover, I still think a VPN is still the safest way to intentionally pierce a firewall from outside.
A DMZ or opening IPv6 ports at the firewall is a good sand box to play with in IPv6 toys but holly molly I do not know how safe it will be.... (much safer than ipv4 I think...)

[mansaxel]

Thanks everybody for the interesting discussion.
Hard to believe IPv6 is still such a beast to implement in Android, we are in 2022 

I am still having a hard time to understand how DHCPv6 works with tracking interfaces, for example...
That said, I do not see the point to run at home IPv6 to address internal Lan devices.
IPv4 is plenty for my home. Interesting is to have IPv6 to talk to internet through the WAN, where my trusty pfSense is acting as a wonderful firewall.
If we could look with a "IPv6 binoculars" through the WAN we could see so many "stars" (and growing) that with ipv4 we were not able to get.

Morewover, I still think a VPN is still the safest way to intentionally pierce a firewall from outside.
A DMZ or opening IPv6 ports at the firewall is a good sand box to play with in IPv6 toys but holly molly I do not know how safe it will be.... (much safer than ipv4 I think...)

I enable v6 on everything, because you know, you never know when you need to reach a box. Printer, for instance. I print to it from my colo hosts; very practical.

Also, while state tables in a OpnSense or PfSense are larger and more accomodating than in smaller routers, the ability to route traffic without state, is a real winner. (an average desktop pc behind NAT with a bunch of spywar^H^H^W^Wcloud services logged in and a few browser tabs up probably eats ~100 state table entries.)  Especially troublesome since your ISP probably has a CGNAT somewhere down the line. And that's going to mess things up. v6 simply makes for better networking.

Safety? It's the same programmers who write v6 code and v4 code. They're optimists. Not a good thing to be.

[madires]

If you are interested in IPv6 security issues I'd recommend to watch some of Fernando Gont's talks (search for 'Fernando Gont IPv6').

[Zucca]

I enable v6 on everything, because you know, you never know when you need to reach a box. Printer, for instance. I print to it from my colo hosts; very practical.

So you print at home without VPN? Is the IPv6 printer reachable from the internet?
How can you prevent another one to use your printer?

Sorry for the stupid questions, I am just confused.

[mansaxel]

I enable v6 on everything, because you know, you never know when you need to reach a box. Printer, for instance. I print to it from my colo hosts; very practical.

So you print at home without VPN? Is the IPv6 printer reachable from the internet?
How can you prevent another one to use your printer?

Sorry for the stupid questions, I am just confused.

There are some firewall rules in place, of course. When you don't have to address translate, making firewall rules is much easier.

[ejeffrey]

Firewall rules alone are not a great choice for protecting unsecured internal devices like printers.  While they will drastically reduce the scope of people that can access them firewall rules are not authenticated or private.  A VPN is much better.

VPNs actually benefit a lot from IPv6.  A major issue with VPNs is address space conflicts.  Since small private networks most often use 192.168.1.0/24 if your VPN client is connecting from behind one NAT device to your home network and they use the same addressing scheme you need address translation on your VPN which sucks.  There are ways around this but globally unique addressing makes it all a lot cleaner.
 
Another big reason for IPv6 at home is if you live somewhere that ISPs deploy carrier grade NAT.  That may not apply to you but it does to a lot of people and the only way they can get good end to end connectivity is IPv6

[Zucca]

Firewall rules alone are not a great choice for protecting unsecured internal devices like printers.  While they will drastically reduce the scope of people that can access them firewall rules are not authenticated or private.  A VPN is much better.

if mansa will give me his printer ipv6 and port should I be able to print in his home?
Guessing those two numbers in the IPv6 ranges is not easy so I do not think it is crazy insecure.
The ipv6 itself is the password. 

Of course ejeffrey is right, with the VPN only if you have the key you can unlock the firewall door.

[mansaxel]

Firewall rules alone are not a great choice for protecting unsecured internal devices like printers.  While they will drastically reduce the scope of people that can access them firewall rules are not authenticated or private.  A VPN is much better.

I beg to differ. Firewall rules are excellent. Lack of routing (which VPN basically amounts to) is useful too, but not as convenient. Also, with universally routable addresses like v6 ones (yeah, I know about local scope) one needs firewall rules TOO.

VPN's like the ones advertised by youtubers are basically useless except for watching Netflix from another country. Secure or safe they are not.

VPNs actually benefit a lot from IPv6.  A major issue with VPNs is address space conflicts.  Since small private networks most often use 192.168.1.0/24 if your VPN client is connecting from behind one NAT device to your home network and they use the same addressing scheme you need address translation on your VPN which sucks.  There are ways around this but globally unique addressing makes it all a lot cleaner.

Of course VPN addressing should NOT be "I'll just route whatever addresses the client has" but instead "If the VPN client wants to communicate through the tunnel, it'll better use the provided tunnel inside address or lose." That's very basic VPN admin stuff. The very reason we use VPN is that we do not trust the clients native network.

Another big reason for IPv6 at home is if you live somewhere that ISPs deploy carrier grade NAT.  That may not apply to you but it does to a lot of people and the only way they can get good end to end connectivity is IPv6

Fully agree.

[mansaxel]

Firewall rules alone are not a great choice for protecting unsecured internal devices like printers.  While they will drastically reduce the scope of people that can access them firewall rules are not authenticated or private.  A VPN is much better.

if mansa will give me his printer ipv6 and port should I be able to print in his home?
Guessing those two numbers in the IPv6 ranges is not easy so I do not think it is crazy insecure.
The ipv6 itself is the password. 

Of course ejeffrey is right, with the VPN only if you have the key you can unlock the firewall door.

Yes, if I allowed it! The printer has a list of allowed networks, the IPv6 firewall has a rule set allowing some networks and blocking the rest.  The only thing a VPN would add is encryption and a squashed MTU. And unless you're running the VPN yourself, and know what you're doing, the encryption part is doubtful.

[Zucca]

Interesting so basically I have to give you my /56 Ipv6 block and you could tell your firewall:

If "origin=Zucca IPv6" AND "Destination = mansa Ipv6 Printer" THEN "let it pass to port printer"

Regarding the VPN discussion I agree they do not give more security, what about privacy from evil ISP sniffing data?