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?

[mansaxel]

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"

Exactly. This is how IP is supposed to work. We have, by thinking "NAT is good enough" conditioned at least 25 years of networking users and administrators into not expecting and requiring the end-to-end model that is arguably the most fundamental component in IP networking.

Whenever I think of this broken illusion I get really upset.  You, OTOH, are recovering into actually appreciating the original qualities of IP networking and that makes for a little better world.

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

This mostly moves the trustpoint. So now you must trust the VPN provider.  (If it's you, that's probably easy.)  Further, you must do a threat analysis model; who are you trying to protect against, and what capabilities do they possess?

If you buy a VPN-as-a-service, then, as noted, you also have another part to trust.

If you buy a VPS in co-lo and set up VPN to it, then that part is solved (if you can trust the virtualisation separation layer to protect your data)

In both cases you still have the question of what happens to the data at the exit point; who is looking at it there, and, since it is not impossible to correlate the VPN stream with the decrypted traffic, and you've shown some kind of intent in encrypting the traffic, who now wants to look at it?

[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.

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.

No, a VPN is not about "lack of routing".  While VPNs work at the network layer and therefore involve routing they are about authentication, data integrity, and privacy not "lack of routing".

IP addresses are not secure.  If you allow access from a remote site by IP block you are open to anyone who can spoof that address which is a lot of people.  With a VPN connecting the remote networks you can actually authenticate the connection, protect the integrity of the data in transit, and prevent snooping.

Yes, a firewall rule will drastically reduce the number of people who can easily gain unauthorized access to your network but far less than a VPN would, as that would require them to take direct control of the endpoint.

Firewalls are necessary course, but mostly only in that they let you treat data on physically different networks differently.   "inside" vs. "outside" vs "DMZ".  Filtering traffic based on which physical network connection they originate on is secure and can't be spoofed without physical access or compromising a device on the private network and the firewall helps to prevent that.  A VPN gives you a "virtual private network" -- that is a connection that physically comes in on your connection to the public internet but which you can treat as an internal device.  A firewall granting access to private resources for connections coming from the public internet based on insecure data like the IP address is not a good use of firewalls.

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

Sure, I never suggested using one. Those systems are not VPNs in any real sense of the word.  They are encrypted proxies.  While they use VPN technology internally, a VPN is a network connection between two trusted devices/networks that takes place over an untrusted intermediate network.  Unless your desire is to communicate in a trusted fashion with NordVPN it doesn't really qualify as a VPN.

What I am saying you should do is run wireguard or openvpn or other similar technology between your hone network and your colo hosts if you want to use unsecured services like printing.  Relying on firewalls for that is better than nothing but is not real security.  It's not actually much better than simply using IPv6 and an open network since IPv6 is almost impossible to brute force scan due to the address space.  If you don't publish your printers IPv6 address only people who have the capability to sniff your network traffic will be able to find it and those are mostly the people who could also mount a spoofing attack.  Of course in this model once your printers IP address becomes public all bets are off and anyone in the world can print random stuff, so I'm not seriously recommending it.

Exactly. This is how IP is supposed to work. We have, by thinking "NAT is good enough" conditioned at least 25 years of networking users and administrators into not expecting and requiring the end-to-end model that is arguably the most fundamental component in IP networking.

I think you misunderstand.  End-to-end connectivity is great, but the goal is to treat the connectivity layer as a neutral infrastructure.  Assigning identity to certain IP addresses/ranges is fundamentally bad idea.  Part of the goal of IPv6 that goes beyond even the pre-NAT intent of IPv4 is to make addresses less meaningful -- they are tools for routing, and they are supposed to support renumbering easily when needed.  If you want identity, use a service built on top of IP, not the low level identifiers.

[mansaxel]

No, a VPN is not about "lack of routing".

In this context it is -- it's also used to go around the problem that everyone (except me and a few others, I've got a IPv4 /24 I'm routing home) have to use useless addresses at home.

IP addresses are not secure.  If you allow access from a remote site by IP block you are open to anyone who can spoof that address which is a lot of people. 

TCP is quite hard to spoof, because you need to control routing to do it. IPP is TCP. I'd be much more wary of deploying an UDP-based insecure protocol, like SNMPv2.

A firewall granting access to private resources for connections coming from the public internet based on insecure data like the IP address is not a good use of firewalls.

My reachable services are mostly (the printer is an exception) secure as-is. Firewalls to me are a way to keep the log noise down.

There are networks at home that contain Internet-of-shit devices. Those do not even get access to the HTTP-ternet via NAT. Likewise, some infrastructure devices that are hard to secure and important to keep private are on another network segment, also without HTTP access to the Internet. Of course neither class of device are on the same segment as the ChromeCast. Hell no if I trust that one...

Exactly. This is how IP is supposed to work. We have, by thinking "NAT is good enough" conditioned at least 25 years of networking users and administrators into not expecting and requiring the end-to-end model that is arguably the most fundamental component in IP networking.

I think you misunderstand.  End-to-end connectivity is great, but the goal is to treat the connectivity layer as a neutral infrastructure.  Assigning identity to certain IP addresses/ranges is fundamentally bad idea.  Part of the goal of IPv6 that goes beyond even the pre-NAT intent of IPv4 is to make addresses less meaningful -- they are tools for routing, and they are supposed to support renumbering easily when needed.  If you want identity, use a service built on top of IP, not the low level identifiers.

I think I was unclear. I don't think we should let users ever bother with learning IP addresses -- I've spent most of my professional network career advocating the use of DNS.

What I'm advocating is that we should never have to accept duplicate IP addresses, because that flies in the face of the the essence of the IP address, that it is unique.

[Zucca]

Drinking my hot tea and enjoying every single words of you two. Thanks.

IMHO You both are right. It depends what are you opening up, some devices are secure, some others are calling home and throwing ropes on the other side of your firewall so somebody could enter.
Regarding a printed port open.... what they could do? worst case trash my paper....

At home in my little little island I have one WIFI called "Untrusted WIFI" because for me, the general joe's wifi whrere all the devices connects, is by definition insecure.

There all my nasty androids and Alexa (my wife, go tell her..) are living. I have then another LAN just for my Lab and there I running my "secure" stuff.

That said some questions

I don't think we should let users ever bother with learning IP addresses -- I've spent most of my professional network career advocating the use of DNS.

I do not think my ISP is giving me a static /56, so I guess I need to do some DDNS IPv6. what I do not know if I can tell my pfSense box "if IP origin is this DDSN" THEN....
I have to do my homework.

with universally routable addresses like v6 ones (yeah, I know about local scope) one needs firewall rules TOO. 

For local scope here are you referring about

Code: [Select]

fe80:: addresses? I did not setup any firewall rules for those...
Again I need to do my homework.

[mansaxel]

That said some questions

I don't think we should let users ever bother with learning IP addresses -- I've spent most of my professional network career advocating the use of DNS.

I do not think my ISP is giving me a static /56, so I guess I need to do some DDNS IPv6. what I do not know if I can tell my pfSense box "if IP origin is this DDSN" THEN....
I have to do my homework.

Yes; since you're doing DHCP-PD assignment, you can (should!) expect the network part to change. For licensing and sanity reasons, I'm running another FreeBSD firewall, but I assume there's some  support for -PD dependent rulemaking in other firewall solutions, and in end nodes.

with universally routable addresses like v6 ones (yeah, I know about local scope) one needs firewall rules TOO. 

For local scope here are you referring about

Code: [Select]

fe80:: addresses? I did not setup any firewall rules for those...
Again I need to do my homework.

No, not quite the same! In IPv6, we talk about scoped addresses; and there are have been 4 scopes:

• Global scope, routable over the Internet.
• Local scope, routable inside a site; not expected to be eBGP announced. Now deprecated.
• Link-local scope; on one link only. This is FE80::/10.
• Node-local scope; basically loopback. ::1, equivalent to 127.0.0.1/8

I was actually unaware that site-local had been deprecated; which is good. I was against standardising it as it was proposed, and never bothered once I'd lost that fight.

Look atRFC4291 for a more complete discussion of the concepts.

[ve7xen]

"Site local" addresses were deprecated way back in 2004. Since 2005 the IPv6 analogue of IPv4 'private addresses' is Unique Local Addresses as defined in RFC 4193 (fc00::/7).

If you want to use them, you will typically give hosts both a ULA and a GUA (globally unique address) by advertising multiple SLAAC prefixes (or DHCPv6). Hosts will choose the correct source address to use based on the destination they are trying to connect to (this source address selection behaviour is codified in RFC 6724).

And the use case here, where your PD block isn't static, is exactly what ULA is for. The main intent is not to 'be private' but to avoid renumbering your internal resources when your GUA prefix changes for some reason. Though it can offer some element of that as well, if you only give devices like printers or whatnot a ULA address, they won't be able to reach the Internet or vice versa.

More from APNIC: https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/

[madires]

When dealing with changing IPv6 prefixes (e.g. DHCPv6 PD) and linux there are some nice features. You can add a fixed interface address without the network part (called token): 'ip token set "::1:2:3:4/64" dev eth0'. For each current prefix the interface address is expanded to <prefix>:1:2:3:4/64. And for the firewall (ip6tables, not sure if nftables supports this also) you can add a matching rule using '::1:2:3:4/::ffff:ffff:ffff:ffff' as address filter.

[Zucca]

My homework:

https://datatracker.ietf.org/doc/html/rfc4193
https://datatracker.ietf.org/doc/html/rfc6724
https://www.rfc-editor.org/rfc/rfc4291

the more complicated it gets the more I am enjoying it. I wish I had all the time I wanted to learn all that stuff....

Thanks everybody!