Live data from Hacker News

DHCPv6-PD – First Steps

sha256.net

71–80 of 91 posts

Re: DHCPv6-PD – First Steps

#71

Earlier quoted context omitted.

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…

ULA is still the right solution here. ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA. If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6. Residential random prefixes is the nature of residential networks, as ISPs do…

[deleted]

Re: DHCPv6-PD – First Steps

#72

Earlier quoted context omitted.

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…

ULA is still the right solution here. ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA. If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6. Residential random prefixes is the nature of residential networks, as ISPs do…

Static addresses in your carrier assigned public range are actually very similar to static ULA in terms of what happens with multiple carriers. The same is even somewhat true for moving carriers unless you specifically want to talk to that exact /64 again. That said I'd still recommend cleaning them up in such an event as the main advantage of utilizing the public addresses is things like your DNS servers can be exposed to the internet without the need of NAT. To me that's a lot more the "right solution" than making trade offs for fear of re-iping your devices for the times in your life you change carriers.

Multiple carriers has no (consumer level) solution I've found myself happy with. It's anywhere from "hope all your devices handle multiple public prefixes quickly and without errors" to "NAT and deal with the pain you had from v4 again" to "Use some other way to relay or host your static services which need to be externally accessible" to "go back to dealing with trying to automatically update that DNS server entry on and making sure it always stays consistent"

Re: DHCPv6-PD – First Steps

#73

Earlier quoted context omitted.

ULA is still the right solution here. ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA. If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6. Residential random prefixes is the nature of residential networks, as ISPs do…

I guess I'll ask here... How do I learn this? I'm comfortable with IPv4, including DHCP, DNS, VPNs, NAT, whatever. I'd like to be able to set up a v6 network[0] in whatever is the Correct and sane way. Is there a good end-to-end tutorial to set it all up by hand and explain what all these things (RA/DHCPv6/fe80::/ULA/etc.) are and how to use them or why not to use them? [0] Ideally pure v6 if possible; I think there'…

For a typical network you usually don't need to do anything. For a geek's network it depends exactly what you're wanting to geek out on. E.g. NAT64 will do what you're looking for at the end (with some caveats depending on what else you're wanting to geek out on) but it's more a carrier focused solution so you don't find as much info about it when reading about consumer tutorials and vice versa.

As for the actual configuration you'll want something specific to your exact network device as learning any of it with a guide for how another device expects the configuration to be entered will be hair pulling.

Re: DHCPv6-PD – First Steps

#74

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…

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

Whose power outage?

The ISP needs to reliably track allocations despite some of their equipment going out, except in the extreme edge case of their entire operation cold starting.

If the client modem goes out it can just be told the same number again when it boots.

And that's not even getting into how trivially small this amount of information is to save to disk.

Non-persistent allocation has technical benefits when your devices keep moving between nodes or when they're offline most of the time. Otherwise not so much.

Re: DHCPv6-PD – First Steps

#75
post #29

Earlier quoted context omitted.

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.

How could it not be a compromise? If I use a global unicast prefix, the IPs I see on my devices are their real honest to goodness routable IP. That is great! But I can’t use that IP in any configuration because it will change. That’s not so great. So I have to compromise by not using the routable IP in places where I need to put the address in a config file. Nobody wants ULA. ULA is a solution for the fact that your…

Well as someone else mentioned, do you want your devices to have no address when your internet connection goes down? A global IP is also a compromise unless you have your own ASN.

> don’t pretend it wouldn’t be massively beneficial

It would be barely beneficial to me.

I don't want to memorize my global prefix anyway.

Re: DHCPv6-PD – First Steps

#76

Earlier quoted context omitted.

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 w…

As browsers don't like link local addresses in the address bar, ULA is still better.

Link local addresses work the same as IPv6 addresses in the url bar, just make sure you're entering the full link local and not the first portion only. Static IPv6 is horrible to enter in browsers in general because you have to remember to [address] as well. Of course, if you're doing it for statically configured local DNS entries as in above then all of this is moot as you'd just use the name.

Re: DHCPv6-PD – First Steps

#77
post #29

Earlier quoted context omitted.

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.

Homie likes to pretend to overcomplicate things. Check the comment history, this rant isn't new. And yeah, folks need to understand that ULA addresses are functionally equivalent to RFC 1918 addresses, and ask themselves why they'd expect an ISP who charges extra for an unchanging globally-routable IPv4 address to give you an unchanging globally-routable IPv6 prefix for free.

id assume those unchanging ipv4 addresses are not shared and natted with other customs and thus charging for them makes sense as you're consuming a limited resource they are paying for.

That's not the same for not changing an ipv6 address

Re: DHCPv6-PD – First Steps

#78

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…

Unfortunately I think most OSs will prefer IPv4 over using IPv6 ULA returned from dns.

Yes, as far as I know, the order of preference is GUA > IPv4 > ULA. Which I guess basically means you either have to tweak the preference on each device in your network or you have to go IPv6-only.

Re: DHCPv6-PD – First Steps

#79
post #21

Earlier quoted context omitted.

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.

AFAIK, it's not strictly true that unicast addresses are required to use a /64 network identifier. It's common, almost necessary even, for environments with dynamic clients to use /64 subnets (precisely so that SLAAC works), but in a static environment it's perfectly fine to use prefixes larger than /64 (e.g. delegate a /80 to each individual host in a datacenter, for virtualization applications etc). Hence, I'm wond…

RFC 4291 section 2.5.1

and to your point, yeah you can step outside the spec and things can work in controlled environments, but "there be dragons" when your dealing with interoperability on a large scale (in this case Android expecting /64s per the RFC)

Re: DHCPv6-PD – First Steps

#80

Earlier quoted context omitted.

ULA is still the right solution here. ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA. If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6. Residential random prefixes is the nature of residential networks, as ISPs do…

I guess I'll ask here... How do I learn this? I'm comfortable with IPv4, including DHCP, DNS, VPNs, NAT, whatever. I'd like to be able to set up a v6 network[0] in whatever is the Correct and sane way. Is there a good end-to-end tutorial to set it all up by hand and explain what all these things (RA/DHCPv6/fe80::/ULA/etc.) are and how to use them or why not to use them? [0] Ideally pure v6 if possible; I think there'…

I wrote one: https://news.ycombinator.com/item?id=40603777
Post reply on HN