Live data from Hacker News

One bad apple can spoil your IPv6 privacy (2022)

arxiv.org

61–64 of 64 posts

Re: One bad apple can spoil your IPv6 privacy (2022)

#61

Earlier quoted context omitted.

I’m thrilled to have good end-to-end connectivity to the degree I’m willing to configure my firewall for it. When I hear people in other threads talking about the “security advantages” of NAT, I imagine someone filling their car’s engine with walnuts and talking about how it protects them from speeding tickets.

That's the thing, you don't have good end-to-end connectivity if you configure the firewall as you should and block everything similar to what NAT does. After which, you have a question, how can you configure end-to-end connectivity securely?, which host(s) do you open up ports towards?

You don't have good end-to-end connectivity with NAT, right?

With CG-NAT my IP address is the same one that infected computers are using, so I'm often treated like a second class citizen on the internet.

Re: One bad apple can spoil your IPv6 privacy (2022)

#62
post #46
post #16

Earlier quoted context omitted.

My ISP assign changes the IPv4 /32 and IPv6 prefix every PPPoE authentication. This is so annoying and breaks routing every couple days or so that I ended up running NPT (NAT for IPv6) and using a ULA block for my LAN. I've seen reports saying you can request a specific prefix as hints to Prefix Delegation and it keeps it mostly static but it is not guaranteed.

I'm a little confused why you would need NPT to resolve this? Why not just create a separate local prefix for your local networking needs? Unless you mean something else by "breaks routing"?

Let's say you get delegated prefix abcd::/64, and you distribute it in your LAN with DHCP.

Now, every PPPoE authentication gets you a different prefix, so if your PPPoE session gets dropped somehow, the clients in the LAN won't get the new IPv6 address until the next DHCP renewal.

In this case, let's say the PPPoE session got dropped, and you got a new delegated prefix of dcba::/64. Your client's IP still has the abcd:: IP, while the router now only knows how to route the dcba:: prefix.

The only way I found to make it work is to give clients a ULA prefix and NPT the ULA with the dynamic delegated prefix from my ISP.

Re: One bad apple can spoil your IPv6 privacy (2022)

#63
post #61

Earlier quoted context omitted.

That's the thing, you don't have good end-to-end connectivity if you configure the firewall as you should and block everything similar to what NAT does. After which, you have a question, how can you configure end-to-end connectivity securely?, which host(s) do you open up ports towards?

You don't have good end-to-end connectivity with NAT, right? With CG-NAT my IP address is the same one that infected computers are using, so I'm often treated like a second class citizen on the internet.

> You don't have good end-to-end connectivity with NAT, right?

I do, I have a public IPv4 that I manage as I wish. Open ports on firewall and forward where needed. No issues so far.

> With CG-NAT my IP address is the same one that infected computers are using, so I'm often treated like a second class citizen on the internet.

Where are you from and what provider are you using?

That is just a crappy provider, you should switch to competition and get a separate IP with no CG-NAT. (never had CG-NAT on home connection, although I avoided providers that did that)

If you're a student in a uni campus/dorms you won't really have an option and it is what it is, it used to be CG-NAT 15-20 years ago too. Even with IPv6 they'd likely firewall everything off and the range would have bad reputation.

Re: One bad apple can spoil your IPv6 privacy (2022)

#64
post #62
post #46

Earlier quoted context omitted.

I'm a little confused why you would need NPT to resolve this? Why not just create a separate local prefix for your local networking needs? Unless you mean something else by "breaks routing"?

Let's say you get delegated prefix abcd::/64, and you distribute it in your LAN with DHCP. Now, every PPPoE authentication gets you a different prefix, so if your PPPoE session gets dropped somehow, the clients in the LAN won't get the new IPv6 address until the next DHCP renewal. In this case, let's say the PPPoE session got dropped, and you got a new delegated prefix of dcba::/64. Your client's IP still has the abc…

Ah I understand now, what a clever solution!
Post reply on HN