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

I spent a week without IPv4 to understand IPv6 transition mechanisms

apalrd.net

Post reply on HN
Print view View original

291–300 of 511 posts

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#291

Post by CaliforniaKarl »

op00to wrote: post #259
mavhc wrote: post #40

Earlier quoted context omitted.

NAT and a Firewall are two different concepts. What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?

Someone might know your IP, and somehow that information is delicious and irresistible to evil .. uh .. spammers?

In that case, have your system use a random IP.

Right now, my macOS system has four publicly-routable IPv6 IPs, all random. New ones are generated, and old ones removed, regularly.

https://www.internetsociety.org/resources/deploy360/2014/pri...

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#293

Post by gerdesj »

throitallaway wrote: post #271
Faark wrote: post #266

Earlier quoted context omitted.

And what computer is making what requests. Now that i think about it, this cloud be the reason why youtube started making recommendations based on stuff i just watched in private browser tabs...

Look at what Android does with MAC address randomization on wireless networks. We will probably see something similar with IPv6.

Not just Android. My laptop does it too (NetworkManager). That's just IPv4 on devices designed to travel so it seems a fair thing to do. Bloody pain to diagnose why a static DHCP lease isn't working the first time, after that you find the mechanisms to turn it off. Nearly everything does it for IPv6, for a given value of everything!

For decades we have generally allowed all outbound and worried and fretted about and filtered inbound. I think it is time for us all to get a grip and do the job properly. However, with the delights of DNS over http and the like, the horse has not only bolted but has a new paint job, far better shoes than you can afford, eats grass that was prepared by a Michelin starred chef and belongs to someone else now.

We all need to be far more sophisticated about how traffic (knowledge/ideas/data) flows in and out of our networks/lives. Packet filtering is just one tool in the box and worrying about an addressing scheme being global (IPv6) instead of a weird hybrid (IPv4) is completely missing the real issue stabbing you in the nadgers.

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#294

Post by creatonez »

AtlasBarfed wrote: post #228

"although software support is virtually a requirement these days" Who's fault is this again? ------------- "- IPv6 is absolutely ready for prime-time and has been for awhile BUT "- About half of the internet sites I rely on support IPv6 natively, so there needs to be more pressure on site admins and CDNs to support IPv6 natively" That is a contradiction. ----------- "There seems to be a lack of drive (judging by foru…

I don't know where you got this narrow view... reading too many amateur blog posts?

Many of the companies/organizations in the IPv6 space are some of the most friendly and easy to work with in the industry

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#295

Post by CaliforniaKarl »

jlokier wrote: post #213
screamingninja wrote: post #138

Earlier quoted context omitted.

Just split that /64 into smaller /80 subnets. If I were your ISP, I would be upset too. The apparent issue here is that you're falling back to what's familiar- static IP addressing. How about mDNS?

You can't use a smaller subnet than /64 for devices that use SLAAC for address allocation. (Unless you're putting them behind an IPv6 NAT, so thry can have their oen private /64).

Or setting up things like stateful DHCPv6: https://serverfault.com/a/714923

It's not great, but it's an option!

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#296

Post by megous »

ajross wrote: post #65

> You should stop thinking of NAT as a security mechanism and think of it as the emergency address exhaustion prevention that it is. I hate this attitude. This is isomporphic to saying "stop thinking of system call interfaces as a security mechanism and think of them as an address space sharing mechanism". It's not technically wrong, but it's wrong in practice. Even the most naive NAT can't misroute an inbound packet…

"Even the most naive NAT"

That would be full cone NAT, right? Can't think of anything more naive... :)

And that can definitely bite you in the ass.

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#297

Post by mqus »

throw0101c wrote: post #162
adriancr wrote: post #145

Earlier quoted context omitted.

> The source address for external connections is effectively randomized It's still unique to one device right?, even if random my argument still holds. Or do you mean to say multiple devices can use the same address? note: I've read the RFCs and they just mean - initial address is random but unique to a device. Each day the address will likely change but new address is still unique to the device (otherwise how would…

> Each day the address will likely change but new address is still unique to the device (otherwise how would routing work). If you set up your device to spin up a new IPv6 address every hour (or even every minute), how will they track you using IPs? On macOS it's 24h, but it doesn't have to be: $ sysctl -a | grep temppltime net.inet6.ip6.temppltime: 86400

ipv4 with NAT gets you a new "adress"(meaning port) on every single new connection. I don't see IPv6 doing the same thing(it has no clue about connections)

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#298

Post by commandersaki »

mgbmtl wrote: post #38
TekMol wrote: post #21

I still think IPv6 can be safely ignored. This articles section "here are some reasons you should start using IPv6 within your own network" seems to comfirm this. None of the 6 "reasons" speak to me.

Here's an easy one for you: if you have a gigabit connection, most home routers can barely handle the load of NAT. That's why gamers push for IPv6. It's mentioned in the article but few people realize how inefficient NAT can be at gigabit and more. My ISP router could do max 800 mbps, which isn't so bad, but it degraded when we were multiple people using the link. With IPv6 it's much less of a problem, we can easily…

Haha bollocks. NAT adds probably at most 1 microsecond to the processing of packets. It’s state for a flow is roughly 16 bytes. The nonsense about NAT being inefficient or slow astounds me.

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#299

Post by mqus »

justeleblanc wrote: post #118
AnonymousPlanet wrote: post #56

Earlier quoted context omitted.

Maybe people don't want to disclose the number and purposes of interior machines?

Your machines could change their IPs for every second of every day and you wouldn't come close to exhausting your /64 subnet for the next billion years.

Won't this break your TCP connections? NAT won't, because it's connection-aware by its nature. And you also get a new "address"(=port) on each new connection, regardless of any setting.

Re: I spent a week without IPv4 to understand IPv6 transition mechanisms

#300

Post by CaliforniaKarl »

PeterisP wrote: post #265
api wrote: post #9

Earlier quoted context omitted.

IPv4 is now stretched to the point that you often end up requiring multiple layers of NAT, such as carrier-grade NAT plus endpoint NAT. That reduces the reliability of pretty much all protocols and makes any protocol doing peer to peer communication really hard or even impossible to run. The latter includes tons of games, video chat, peer to peer VPNs, decentralized social networks, and so on. These problems will onl…

I get that there are people in the world with severe lack of IPv4 addresses and this is a valid reason for them to switch to IPv6. However, assuming that I and my organization have enough IPv4 addresses (without requiring any of the tricks of multiple layers of NAT), is there a sufficient reason for us to justify the effort/expense of changing what works?

_You_ might not need to deal with the tricks of NAT, but more and more, your customers _do_.

For example, I'm in the US, and my mobile device has an IPv4 IP sitting behind the mobile provider's CG-NAT. My mobile device also gets IPv6.

Since you only provide your site over IPv4, that means my opinion of your site is governed in part by my ISP's CG-NAT, which you do not control. If the CG-NAT is overloaded, or otherwise having issues, that will manifest to me as problems with your site. I will assume the problem is with your site, and take my business elsewhere. In this example, if your site was also provided over IPv6, then my phone would have skipped the IPv4-only CG-NAT, and things would be fine.

Post reply on HN