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

IPv6 Is A Disaster (but we can fix it)

matduggan.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: IPv6 Is A Disaster (but we can fix it)

#91

Post by aidenn0 »

NoZebra120vClip wrote: post #11
stop50 wrote: post #10

Earlier quoted context omitted.

If the host has no v4 it switches to v6 if possible. Disabling the support is not needed

Very ambiguous reply. Which host? The remote or the local? What do you mean "has no v4"? No A record? No v4 address on an interface? Which hardware and OS are you describing? Clearly the blog post illustrated some examples where switching to v6 was not happening, so it seems to contradict your comment right off the bat. There are many implementations of dual-stack IPv4/v6. In fact, they are more divergent than IPv4 i…

If (a host trying reach a remote service) has (no route to the address indicated by the A record) then it will try a AAAA record if one exists.

> Which hardware and OS are you describing?

This is how it's supposed to work on all OSes; on any recent BSD (excepting perhaps Apple?) or Linux setup, it should work this way.

> Clearly the blog post illustrated some examples where switching to v6 was not happening

In those situations it was for connecting to services that do not advertise a AAAA record.

Re: IPv6 Is A Disaster (but we can fix it)

#92

Post by NoZebra120vClip »

aidenn0 wrote: post #91
NoZebra120vClip wrote: post #11

Earlier quoted context omitted.

Very ambiguous reply. Which host? The remote or the local? What do you mean "has no v4"? No A record? No v4 address on an interface? Which hardware and OS are you describing? Clearly the blog post illustrated some examples where switching to v6 was not happening, so it seems to contradict your comment right off the bat. There are many implementations of dual-stack IPv4/v6. In fact, they are more divergent than IPv4 i…

If (a host trying reach a remote service) has (no route to the address indicated by the A record) then it will try a AAAA record if one exists. > Which hardware and OS are you describing? This is how it's supposed to work on all OSes; on any recent BSD (excepting perhaps Apple?) or Linux setup, it should work this way. > Clearly the blog post illustrated some examples where switching to v6 was not happening In those…

No, actually it does not work that way. You have it backwards, first of all: IPv6 AAAA record is queried first, then the connection is attempted, and then a fallback may happen to an A record and an IPv4 connection attempted.

https://www.rfc-editor.org/rfc/rfc5220.txt

I'm not sure why you specified "if a host has no route to the address", because that's a very specific and transient failure. Furthermore, the dual-stack handling necessarily happens in the application, so this is not an OS or kernel-level decision, it will be subject to each individual app's behavior: https://issues.apache.org/jira/browse/SERF-190

As you can see from RFC5220, IPv6 is preferred over IPv4, unless an option is set to swap those around. Of course, certain configurations can confound this preference order, such as ULA IPv6.

"No route to host", as should be obvious, is only one of many errors that could prevent an app from establishing an IPv6 connection. It would seem that they should handle most failures as an occasion to fall back to IPv4, unless configured not to.

Re: IPv6 Is A Disaster (but we can fix it)

#93

Post by Dagger2 »

NoZebra120vClip wrote: post #92
aidenn0 wrote: post #91

Earlier quoted context omitted.

If (a host trying reach a remote service) has (no route to the address indicated by the A record) then it will try a AAAA record if one exists. > Which hardware and OS are you describing? This is how it's supposed to work on all OSes; on any recent BSD (excepting perhaps Apple?) or Linux setup, it should work this way. > Clearly the blog post illustrated some examples where switching to v6 was not happening In those…

No, actually it does not work that way. You have it backwards, first of all: IPv6 AAAA record is queried first, then the connection is attempted, and then a fallback may happen to an A record and an IPv4 connection attempted. https://www.rfc-editor.org/rfc/rfc5220.txt I'm not sure why you specified "if a host has no route to the address", because that's a very specific and transient failure. Furthermore, the dual-sta…

That is also not accurate. Clients query both the A and AAAA records simultaneously up front, sort the replies according to the RFC3484/6724 rules, and then try each address in turn.

The rules are somewhat involved but they roughly boil down to "sort v6 addresses first if the client has a non-ULA v6 address, otherwise sort v4 first". However, note that the very first rule in 6177 is "avoid unusable destinations" so not having a route to an IP may factor in to the sorting.

A machine with no v6 will(/may) still query AAAA records, but it will attempt to connect to any A records first before trying any AAAA records. (This sometimes exhibits as people seeing software like apt-get report connection failures to v6 addresses and then blaming v6 for it, even though the problem is that they only have v4 and the v4 is broken.)

Re: IPv6 Is A Disaster (but we can fix it)

#94

Post by Dagger2 »

unethical_ban wrote: post #20
bell-cot wrote: post #4

My IPv6 philosophy: If any "new" computer technology has been around even half as long as IPv6 ( https://en.wikipedia.org/wiki/IPv6_deployment#Major_mileston... ), with even a tenth of the "you gotta start using this!" push from the Big Boys - and yet still is very widely avoided/resisted, and the older-tech alternative commands a price premium due to widespread demand...gosh, that "new" technology must absolutely su…

But no one has pushed. Consumer routers still suck regarding IPv6. Last time I tried setting up IPv6 on my wan I got a /128 which is utterly incompetent. No service wants to cut off access to the ipv4 customers so they've made things just work. We have only recently hit address exhaustion (relative to IPv6 age). No one wants to jump first and there is no government mandate for support. I don't know who you think the…

A /128 on the WAN is normal. Addresses assigned by DHCPv6 (which is commonly used by ISPs for WAN address assignment) are assigned as /128.

The important part is the delegated prefix, which you normally get via DHCPv6-PD and should be at least a /56.

Re: IPv6 Is A Disaster (but we can fix it)

#95

Post by Dagger2 »

hot_gril wrote: post #56
bauruine wrote: post #53

Earlier quoted context omitted.

IPv6 is backwards compatible to IPv4 but not the other way around. If you have a solution how to address a 128bit IPv6 address with the 32bits available on v4 I'm sure many people are eager to talk to you. It's just not possible.

With a 6-to-4 gateway then yeah. But at that point you're using v4.

How do you expect compatibility with v4 protocols/software/hardware/routers/ISPs to work without using v4?

That's a serious question. Do you have a way for this to work? Because I don't think it's possible (for fundamental reasons: https://en.wikipedia.org/wiki/Pigeonhole_principle), and it would be extremely unfair to criticize the designers of v6 for not fixing an unfixable problem.

Re: IPv6 Is A Disaster (but we can fix it)

#96

Post by Dagger2 »

hot_gril wrote: post #60
unethical_ban wrote: post #59

Earlier quoted context omitted.

NAT is a bandage over a crippling of proper network behavior. You trust your port forwarding isn't illicitly opening itself, no? Then you can trust a default deny inbound policy on IPv6.

My port forwarding would have to actively try to allow traffic to my host. It doesn't even know where to forward to. And like it or not, NAT has momentum. Getting rid of NAT would be a big migration in of itself.

This is actually wrong, and dangerously so. Your router knows perfectly well where to forward any given packet to: it forwards it to the IP that's in the packet's "destination IP" header.

If a connection comes into your router with the destination IP set to one of your LAN machines, NAT will not stop the connection.

There's no reason to be using NAT to protect yourself from inbound connections, because that's not a thing NAT even does in the first place. It often makes things actively worse even, by making it easier to port scan for your servers and by giving you a false sense of security.

Re: IPv6 Is A Disaster (but we can fix it)

#97

Post by Dagger2 »

JohnFen wrote: post #27
zamadatix wrote: post #13

Earlier quoted context omitted.

The nice thing about NAT64 is you only NAT when you're talking to a v4 only client, otherwise you still have pure v6. This leaves no hacks to remove for a pure IPv6 experience it just means you can have single stacked IPv6 devices instead of needing to dual stack or wait for the entire rest of the world to also configure IPv6 too. I.e. it allows you to push IPv4 to your internet edge only in a way that doesn't downgr…

When the day comes that I have to shift to IPv6, I think I still want to NAT, though. I could be (and probably am) misunderstanding things, but I don't see how I can eliminate my need for it. What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.

What you're asking for here is port forwards/DNAT, i.e. applying NAT to redirect an inbound connection. When people say "NAT", they're usually talking about SNAT/MASQUERADE, i.e. NATing outbound connections.

If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to NAT, you just need to port forward.

Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.

If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection any of your machines make would immediately inform the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.

But if you're gonna do it, you can do just that, without trying to run the network on some local IP range too.

Re: IPv6 Is A Disaster (but we can fix it)

#98

Post by Dagger2 »

JohnFen wrote: post #45
WorldMaker wrote: post #42

Earlier quoted context omitted.

Compatibility breaks are always headaches. There's not "just broke a 'single' thing" when it comes to compatibility breaks. That is why strict semver suggests a major bump no matter how "small" a compatibility break appears to the developer. There is no such thing as a "simple" compatibility break to downstream users. In general, despite the complex vocabulary about most of it, in many ways IPv6 is simpler than IPv4.…

> in many ways IPv6 is simpler than IPv4. It's not really about whether or not IPv6 is simpler than IPv4, though. It's about how painful moving from IPv4 to IPv6 is. And it's very painful. If the only thing that changed between the two was that the IP address space is bigger, it would reduce the pain of changing. I'm certainly not going to claim that my experience is representative of anyone except for me, but the re…

It's honestly not that hard. Looking at your other posts, you think it's hard because you're unfamiliar with it, because you're trying to overcomplicate it, and because you're trying to do everything all at once rather than gradually.

None of these things are IPv6's fault.

Hell, give me remote access to your network and I'll set it up for you -- at least enough to get you started on it if not 100% on every single thing. I don't expect you'll take me up on that offer, but it'd be easier to just do it than tell you about it, since you can't tell people anything: http://habitatchronicles.com/2004/04/you-cant-tell-people-an...

Post reply on HN