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

61–70 of 91 posts

Re: DHCPv6-PD – First Steps

#61

Post by simoncion »

Tigress8780 wrote: post #39
mathsmath wrote: post #18

Earlier quoted context omitted.

Someone should double check me, but I think PD less than a /64 also just breaks (and probably is against the spec). A lot of the complaints I have seen in the last decade is from ISPs doing silly things and cutting their teeth on fresh IPv6 deployments. My ISP seems to have their collective ducks in a row now, and it has been rock solid for years. I actually had a case recently where a misbehaving IPv4 IoT device con…

It probably is. I remember that putting a /72 into OpenWRT's `ip6prefix` field actually breaks the whole network stack (including IPv4, the interface no longer has any address assigned to it).

I wonder if that's an artifact of configuration-generation scripts detonating before they ever get around to writing out any configuration, leaving the network interfaces entirely unconfigured.

Re: DHCPv6-PD – First Steps

#62

Post by amaccuish »

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…

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

Re: DHCPv6-PD – First Steps

#63

Post by simoncion »

Uptrenda wrote: post #33

People who advocate for IPv6 are always like 'ahhhh just plug it in and its ready to go!!!' There's even twitter accounts that shame people for how they approach IPv6. But after doing a crap load of network programming I can tell you its really not simple at all. - IPv6 has many different address types. - Depending on the type you want to bind to it needs to be handled different. - Some types need an interface ID app…

Your "end-user routers suck ass" comment is totally true. I wish the end-user and SOHO networking gear market wasn't a fucking race to the bottom.

Your other comments simply aren't a substantial concern at end-user sites in the real world.

* The only scopes that end-user sites might care about are global and link-local. I expect that situation is the same at nearly all non-end-user sites. Reading through the RFCs, it looks like the other scopes are ONLY relevant in multicast [0][1]... and even then, anything other than interface-local, link-local, and global looks like it's programmed into the routers and switches of the network, rather than host computers themselves.

* If you have functional IPv6 service at your site, your application software cares as much about the interface's fe80::/10 link-local address as it does about the 169.254.0.0/16 link-local address... that is, not at all. The rule is simple: "If you want to talk globally, use an interface with a global address. If there's no global address, send it to the 'default' router and hope for the best.". It's actually a better situation than in IPv4 where you pretty much never have a globally-connected address.

* Yes, you can do IPv6 NAT. In that case, you're no worse off than in the usual end-user IPv4 deployment. The cool thing about IPv6 is not that NAT doesn't exist, it's that there's far, far more than enough address space to make it so that you don't HAVE to deploy NAT at end-user sites. That doesn't mean that it's impossible for stupid, frightened, currently-ignorant, or revenue-maximizing ISPs to deploy NAT.

[0] https://www.rfc-editor.org/rfc/rfc4291#section-2.7>

[1] https://www.rfc-editor.org/rfc/rfc7346#section-2>

Re: DHCPv6-PD – First Steps

#64

Post by eythian »

lloeki wrote: post #35
hairyplanter wrote: post #30

Earlier quoted context omitted.

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

> 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. I'm surprised based on my experience: in 15 years of residential IPv6 usage I've always had the same IPv6 prefix (for a given ISP contract of course), even for those ISPs that insisted o…

My ISP-given IPv6 (/57 for whatever reason) prefix is also stable, however beware that, at least on my OpenWRT based router, the option to release the prefix back to the ISP when the router is shut down is checked by default. I discovered this when I rebooted for a firmware update and when it came back up my network had renumbered itself.

Re: DHCPv6-PD – First Steps

#65

Post by eythian »

Uptrenda wrote: post #33

People who advocate for IPv6 are always like 'ahhhh just plug it in and its ready to go!!!' There's even twitter accounts that shame people for how they approach IPv6. But after doing a crap load of network programming I can tell you its really not simple at all. - IPv6 has many different address types. - Depending on the type you want to bind to it needs to be handled different. - Some types need an interface ID app…

My GL inet router does native IPv6 just fine, without needing NAT6 or anything. Within its interface you can turn it on as "native" and it all just works.

Re: DHCPv6-PD – First Steps

#66

Post by the8472 »

OJFord wrote: post #55
hairyplanter wrote: post #30

Earlier quoted context omitted.

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

What's the point of using IPv6 at all on a home network if you use ULA though? If you continued to use an IPv4 setup you were familiar with but allowed your router to talk both or v6 only, wouldn't it be the same? Is it that you'd still have the globally addressable addresses on NICs with a ULA too, just that's not what you'd use for routing internally? (Not that I'm really sure of the benefit of that residentially e…

With ULA you generate a random prefix which means it's extremely unlikely there's a collision. So no need for internal NATing or interface disambiguation because a machine is connected to two networks (e.g. via tunnels) that are both using 192.168.0.0/24. Which also means less book-keeping for collision avoidance. Just roll the dice.

Re: DHCPv6-PD – First Steps

#67

Post by ninkendo »

simoncion wrote: post #59
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…

> ...they don’t drop the old one until the lifetime expires... That's a configuration problem on your end. Your border router needs to notice that it's being instructed to switch delegated prefixes and instruct radvd (or whatever route advertising daemon it's using) to advertise the now-defunct prefixes with a zero lifetime just before or just as you're advertising the new prefixes. With this information, devices on…

rtadvd does support advertising old prefixes with zero lifetime to rescind them. rad does not.

I’ll let you guess what daemon is deprecated, and what daemon is the new one you’re supposed to use in OpenBSD.

https://undeadly.org/cgi?action=article;sid=20180724072205

Re: DHCPv6-PD – First Steps

#68

Post by ninkendo »

kccqzy wrote: post #29
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.

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 prefix will change, which I wish didn’t happen.

You can say it’s unreasonable to expect a stable prefix (and we could argue about that all day) but don’t pretend it wouldn’t be massively beneficial if I could rely on one. It is absolutely a compromise. A necessary one? Yes. A reasonably simple solution to implement? Yes. But it’s still a compromise.

Re: DHCPv6-PD – First Steps

#69

Post by [deleted] »

simoncion wrote: post #63
Uptrenda wrote: post #33

People who advocate for IPv6 are always like 'ahhhh just plug it in and its ready to go!!!' There's even twitter accounts that shame people for how they approach IPv6. But after doing a crap load of network programming I can tell you its really not simple at all. - IPv6 has many different address types. - Depending on the type you want to bind to it needs to be handled different. - Some types need an interface ID app…

Your "end-user routers suck ass" comment is totally true. I wish the end-user and SOHO networking gear market wasn't a fucking race to the bottom. Your other comments simply aren't a substantial concern at end-user sites in the real world. * The only scopes that end-user sites might care about are global and link-local. I expect that situation is the same at nearly all non-end-user sites. Reading through the RFCs, it…

[deleted]

Re: DHCPv6-PD – First Steps

#70

Post by f_devd »

greenicon wrote: post #51
f_devd wrote: post #47

Earlier quoted context omitted.

My only gripe with IPv6 is that clients use an entire /64, I get it's useful for SLAAC, but I wish I could make clients receive a /68 or more with DHCPv6 so that the address space can be subdivided even when you are already behind a /64 prefix.

That’s exactly what prefix delegation is for. Your ISP ought to give an /56 or more, so you can then have multiple /64. I get an /56 by my ISP and have 6 or so different /64 in my residence.

ISPs do give enough where I am the issue is usually when you are behind 2 firewalls past that or have VMs that you want to DHCP, things like that.

A real world example my ISP provides /56 at the router level but if you put a firewall behind it, that gets a /64 (cannot be changed). Now the firewall cannot further delegate prefixes since it's already used. Some firewalls allow RA pass-through but in my case this wasn't an option so I had to set up NAT66 (non-standard :/) just to get outbound ipv6 connectivity.

Post reply on HN