4 ms·

I'd recommend using ULA addresses for things like local dns servers. When I was with my old ISP, we'd have our prefix dynamically delegated so I gave important

I'd recommend using ULA addresses for things like local dns servers. When I was with my old ISP, we'd have our prefix dynamically delegated so I gave important servers ULA addresses. I then used some iptables scripts to allow traffic to my IPv6 services by looking only at the host part of the address, so if the prefix changed, the firewall rules would still be valid and allow access. That coupled with dynamic dns made it possible to still have a reasonably good network. Since my new ISP gives us static everything, it's all so much easier. I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.

vetinari 6y ago
> I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix. IPv6 allocation rules. They wanted to avoid the situation that happened with IPv4, so the address block are licensed for use and renewed on regular basis, so they can change. There's no such thing as fixed or static IPv6 address, it is dynamic, turtles all the way down. Hence DHCP-PD. See also "Address space not to be considered property" (section 4.1) in the "IPv6 Address Allocation and Assignment Policy" (https://www.ripe.net/publications/docs/ripe-552#property https://www.ripe.net/publications/docs/ripe-552#property)
- everdrive 6y ago
  > They wanted to avoid the situation that happened with IPv4, This is directly contrary to what I've heard. Maybe my information is bad, or out of date, but I had thought that IPv6 addresses were meant to be static. I thought one of the selling points was that we couldn't run out of IPv6 addresses, as they were so numerous. If we're going to keep them dynamic, why even force this monstrous 128-bit number on us?
  - corty 6y ago
    As far as I've understood, they wanted a little of everything. IPv6 addresses should be more static short to medium term, because you don't have to reassign. Your local pool is basically infinite, so e.g. a client logging off the WiFi doesn't mean you immediately have to recycle the address. The local part (the latter 64 bits) is enough for everything and everyone. Now, the first 64 bits should be used for routing, which should preferably be more hierarchical than with IPv4. The idea was that a customer/company/small ISP would get a prefix assigned that was below the hierarchy of the upstream ISP (with IPv4, that hierarchy isn't possible because there aren't enough address bits, and lots of lower-tier customers got their own subnets). So a large ISP might be assigned 2345::/16, assign 2345:6789::/32 to a smaller ISP who might assign 2345:6789:abcd::/48 to a customer (who then will do more subnetting with that). That keeps the global and local routing table small, since everyone just needs to look at the address prefix to know where to route to. If the customer now moves to another ISP, he is assigned a new prefix (e.g. 4711:f0f0:666::/48) by the new ISP and needs to renumber, meaning that all the customers addresses keep their suffix but change their prefix. Protocols like SLAAC where designed as stateless to support (among other things) quick and easy renumbering. Just announce the new prefix, wait a TTL and you are done. Clients automatically switch over to the new addresses, in an ideal world this is mostly transparent to the end user. In the new millenium, especially after Snowden, the argument of privacy got stronger, meaning that randomised local /64 suffixes are now en vogue, as opposed to the earlier MAC-based static suffixes. Therefore everything is more dynamic and also more static ;)

vetinari 6y ago

> I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix. IPv6 allocation rules. They wanted to avoid the situation that happened with IPv4, so the address block are licensed for use and renewed on regular basis, so they can change. There's no such thing as fixed or static IPv6 address, it is dynamic, turtles all the way down. Hence DHCP-PD. See also "Address space not to be considered property" (section 4.1) in the "IPv6 Address Allocation and Assignment Policy" (https://www.ripe.net/publications/docs/ripe-552#property https://www.ripe.net/publications/docs/ripe-552#property)

everdrive 6y ago
> They wanted to avoid the situation that happened with IPv4, This is directly contrary to what I've heard. Maybe my information is bad, or out of date, but I had thought that IPv6 addresses were meant to be static. I thought one of the selling points was that we couldn't run out of IPv6 addresses, as they were so numerous. If we're going to keep them dynamic, why even force this monstrous 128-bit number on us?
- corty 6y ago
  As far as I've understood, they wanted a little of everything. IPv6 addresses should be more static short to medium term, because you don't have to reassign. Your local pool is basically infinite, so e.g. a client logging off the WiFi doesn't mean you immediately have to recycle the address. The local part (the latter 64 bits) is enough for everything and everyone. Now, the first 64 bits should be used for routing, which should preferably be more hierarchical than with IPv4. The idea was that a customer/company/small ISP would get a prefix assigned that was below the hierarchy of the upstream ISP (with IPv4, that hierarchy isn't possible because there aren't enough address bits, and lots of lower-tier customers got their own subnets). So a large ISP might be assigned 2345::/16, assign 2345:6789::/32 to a smaller ISP who might assign 2345:6789:abcd::/48 to a customer (who then will do more subnetting with that). That keeps the global and local routing table small, since everyone just needs to look at the address prefix to know where to route to. If the customer now moves to another ISP, he is assigned a new prefix (e.g. 4711:f0f0:666::/48) by the new ISP and needs to renumber, meaning that all the customers addresses keep their suffix but change their prefix. Protocols like SLAAC where designed as stateless to support (among other things) quick and easy renumbering. Just announce the new prefix, wait a TTL and you are done. Clients automatically switch over to the new addresses, in an ideal world this is mostly transparent to the end user. In the new millenium, especially after Snowden, the argument of privacy got stronger, meaning that randomised local /64 suffixes are now en vogue, as opposed to the earlier MAC-based static suffixes. Therefore everything is more dynamic and also more static ;)