Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DHCPv6-PD – First Steps

sha256.net

Post reply on HN
Print view View original

21–30 of 91 posts

Re: DHCPv6-PD – First Steps

#21

Post by devman0 »

Tigress8780 wrote: post #16
j16sdiz wrote: post #7

Earlier quoted context omitted.

No. In IPv6, you can get an address using RA. DHCPv6 only if you want to smuggle some unrelated metadata as options (which, of course, not widely used outside enterprise). DHCPv6-PD are used only when you need a whole prefix. If everybody implement all the specs out there, we will have two different DNS record type, 4 or 5 address allocation schemes, a handful of IPv6-over-IPv4 protocol, whole a lots of incomplete an…

SLAAC is fine, until you somehow get a subnet smaller than /64 on your router, in which case SLAAC completely breaks. I understand why SLAAC has such a limitation, but this is what we get. It's not optimal, but the upstream network provider does not budge, and now everything except Android devices get IPv6 address via DHCPv6.

Unicast IPv6 addresses are required to have a 64 bit interface identifier and a 64 bit network identifier (e.g. /64), handing out subnets lower than /64 is not spec compliant.

Network operators can do crazy things, but if you color outside the lines things may break.

Re: DHCPv6-PD – First Steps

#22

Post by robhlt »

tssva wrote: post #4
candiddevmike wrote: post #2

While the article is focused on OpenBSD, implementing DHCPv6 with systemd-networkd is really slick and typically a 1-2 line config for your interfaces: Upstream: [DHCPv6] PrefixDelegationHint=::/56 Downstream: [DHCPv6PrefixDelegation] Token=::1

I have never been able to get DHCPv6PD working with systemd-networkd on my Verizon Fios connection at home. I have using other software.

It's working on my fios connection, but I remember that wasn't always the case. Verizon may have changed something recently or the issue was fixed in a recent systemd release.

My config looks like this with systemd 255:

  wan.network:
  [Network]
  DHCP=yes
  IPv6AcceptRA=yes
  IPForward=yes

  [IPv6AcceptRA]
  UseDNS=no
  DHCPv6Client=yes

  [DHCPv6]
  UseDNS=no
  UseHostname=no
  UseDomains=no
  PrefixDelegationHint=::/56

  [Link]
  RequiredForOnline=routable


  lan.network:
  [Network]
  Address=xx.xx.xx.1/24
  IPForward=yes
  DHCPv6PrefixDelegation=yes

  [DHCPv6PrefixDelegation]
  SubnetId=0
  Token=static:::1
That lan config can be re-used on other vlan interfaces too, to take full advantage of the /56 prefix. Just increment the SubnetID (hex only for some reason, so the next is 0x1).

Re: DHCPv6-PD – First Steps

#23

Post by ninkendo »

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable.

The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all software (I’m looking at you, OpenBSD, which has no out of the box support for it and I’ve not figured out how to configure it.)

So the real answer is to create a ULA prefix on the side that you generate randomly (or make an easy to remember one because this is residential use, who cares about collisions, it’s a private space) and use that for any use case that involves hardcoded IPs, like DNS server configuration.

But it still feels like a compromise to me. I wish more software was “prefixless”, including DNS server indication and even DNS zone files, such that a lack of prefix means “prepend the prefix you are already communicating on”… Firewall configuration would be simpler, DNS zone files could survive re-prefixing, all sorts of configuration could be made to work this way, but instead you’re left with either a ton of automation to reconfigure things when the prefix changes, a bunch of manual work, or just bite the bullet and use ULA.

Oh, and did I mention that in my particular setup, all my devices would keep trying to communicate on their old addresses even after a new prefix gets assigned and the new RA’s are sent? Meaning they essentially lose all connectivity if you’re using an IPv6-mostly setup like I have? Oh sure, they grab addresses on the new prefix, but they don’t drop the old one until the lifetime expires, which defaults to 4 hours in the environment I’m in (I think the rad daemon in OpenBSD inherits the lifetimes from its upstream router’s lifetimes, which makes the duration Comcast’s fault, but the proper thing to do is rescind the old RA’s when the interface changes addresses, and rad does not do this out of the box for me, or if it does it doesn’t work right.)

Ok rant over. I want to like IPv6 but dynamic prefixes are really the Achilles heel for me.

Re: DHCPv6-PD – First Steps

#24

Post by mikepavone »

hamandcheese wrote: post #12
miller_joe wrote: post #5

This is great! I’ve been using ipv6 on openbsd for a while now, starting with a hurricane electric tunnel years ago then to native v6 on Comcast and now Sonic. Configuring ipv6 PD has not been supported in base this whole time. I recall using wide-dhcp6c years ago and then switching to the dhcpcd in the article. The situation has improved, slowly, but it will be great to have this in the base system *EDIT*: dhcp6leas…

Did Sonic start offering native IPv6? Last I looked, it was only covered via tunnel only.

They turned on native IPv6 end of last year, at least in some areas (including Berkeley where I live). You wouldn't know it from their help pages, but there are some post in the forum to that effect.

Re: DHCPv6-PD – First Steps

#25

Post by justahuman74 »

ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

I wish getting and using an IPv6 subnet was like buying a domain name, and that residential ISPs would be required to use your subnet for your service, a bit like portable phone numbers.

The current IP allocation/usage procedures are a bit beyond most people

Re: DHCPv6-PD – First Steps

#26

Post by zamadatix »

ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

For those with flatter home network needs but still wanting a few things internal to be reachable by IP I'll throw in you can also use static link locals on fe80:: instead of a random ULA prefix. You'll still need the ULA method if you have multiple subnets and want static services reachable via routing though.

Unless the router says the old prefix now has a valid lifetime of 0 the proper thing to do is actually to wait for the prefix to expire like it seems to be doing. I never had this missing lifetime change problem with Comcast but it's very possible they do things differently in different service areas/for different service types.

Re: DHCPv6-PD – First Steps

#27

Post by stephen_g »

justahuman74 wrote: post #25
ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

I wish getting and using an IPv6 subnet was like buying a domain name, and that residential ISPs would be required to use your subnet for your service, a bit like portable phone numbers. The current IP allocation/usage procedures are a bit beyond most people

That would make the routing table exponentially larger though, which would become unworkable… That’s why they mostly only do it for networks big enough to need it.

Re: DHCPv6-PD – First Steps

#28

Post by zamadatix »

justahuman74 wrote: post #25
ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

I wish getting and using an IPv6 subnet was like buying a domain name, and that residential ISPs would be required to use your subnet for your service, a bit like portable phone numbers. The current IP allocation/usage procedures are a bit beyond most people

A good compromise between this (lots of routing work on the internet) and random prefixes all the time (lots of work on the end user networks) is setting DHCP-PD to do consistent PD assignments. Sure, you're space isn't portable between carriers if you move/have redundant internet but you can also rely on a static address in your assigned range working 3 years from now even if your router is offline for a month. ATT fiber does this. I haven't done a survey of who else.

Re: DHCPv6-PD – First Steps

#29

Post by kccqzy »

ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

Your rant doesn't make sense. The solution is already known and you mention it: ULA. It's not a compromise. You don't need to bite the bullet. Just use it. It's designed for this use case. Fixed IP address for every single device.

Re: DHCPv6-PD – First Steps

#30

Post by hairyplanter »

ninkendo wrote: post #23

This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable. The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all…

> or just bite the bullet and use ULA.

This is the proper ipv6 solution.

With ipv6, one ethernet interface is _supposed_ to have multiple addresses. You wouldn't want your lan routing to stop working when your ISP goes down, right? So configure your internal DNS with ULA (which should be stable for each machine for a given prefix, even with SLAAC) and be done with it, much like internal DNS using private addresses in ipv4.

For externally visible servers, do the normal thing, that is, those servers dynamically update global dns, much the same way with ipv4 dyndns.

Another learning curve for ipv6 is that people get frustrated by dynamic prefixes, but it's the nature of residential networks: the ISPs want a stateless solution, so customers get a dynamic prefix. Maintaining the same prefix across power outages needs a stateful solution, so only business plans offer them for an extra fee, much like static ipv4 addresses.

And we've had dyndns for decades now for exactly that use case. Just keep using that.

Post reply on HN