Products > Networking & Wireless

Why we need a DHCPv6?

(1/7) > >>

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:

--- Quote from: Zucca on January 21, 2022, 04:25:27 am ---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.

--- End quote ---

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?


--- Quote ---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.
--- End quote ---

I may of course be wrong. It happens sometimes

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version