Live data from Hacker News

My security camera shipped a GitHub admin token in its login page

hhh.hn

261–265 of 265 posts

Re: My security camera shipped a GitHub admin token in its login page

#261

Earlier quoted context omitted.

An alternate to IPv6 would have been to store the NAT addresses in IPv4 somehwere. But the IPv4 options are fragile and normal NAT would likely destroy them. It would still require rewriting all of the networking and software. It would have engrained NAT everywhere and made lots of routing problems, like is that your or mine 10. network.

That's where the public prefix would be the differentiator... you could only access from external directly over IPv6, but it still represents the same device as the NAT ipv4 address. Difference is it's all public after, it would ease the transition dramatically, and then you can just use whatever you want internally making /32 the minimal assigned block or whatever the prefix size is.

Stop saying IPv6 when talking about new protocol. IPv6 already exists and is better than potential IPv4 extension. There was a window twenty years ago for alternative but now IPv6 is usable and can access IPv4 hosts with NAT64. The only reason for IPv4 is inertia.

Routing would be complicated when have to deal with variable length addresses when half the hosts don't know about them and half the routers remove them. It wouldn't make up for rewriting all the software, we know how hard that was with IPv6.

Re: My security camera shipped a GitHub admin token in its login page

#262

Earlier quoted context omitted.

I'm largely with you... I would think they'd take the IPv4 block and have a direct/virtual block that just extends it to more addresses... so it could be an IPv4 NAT or IPv6 direct. like 1.1.1.1/192.168.45.4 ... for a router that understands IPv6, that's the direct route to the sub-network, otherwise it will have to use IPv4, and the subnet route is treated as NAT and otherwise isolated. To me, that would make more s…

An alternate to IPv6 would have been to store the NAT addresses in IPv4 somehwere. But the IPv4 options are fragile and normal NAT would likely destroy them. It would still require rewriting all of the networking and software. It would have engrained NAT everywhere and made lots of routing problems, like is that your or mine 10. network.

ipv6 predated widespread use of nat

NAT's RFC was 1994 - although port translation didn't come in until 1996. The same year that IPv6's RFC came in 1996.

Had ipv6 not been created until say 2010 I suspect it would have looked to be backwards compatible with the widespread use of NAT then.

Re: My security camera shipped a GitHub admin token in its login page

#263

Earlier quoted context omitted.

That's where the public prefix would be the differentiator... you could only access from external directly over IPv6, but it still represents the same device as the NAT ipv4 address. Difference is it's all public after, it would ease the transition dramatically, and then you can just use whatever you want internally making /32 the minimal assigned block or whatever the prefix size is.

Stop saying IPv6 when talking about new protocol. IPv6 already exists and is better than potential IPv4 extension. There was a window twenty years ago for alternative but now IPv6 is usable and can access IPv4 hosts with NAT64. The only reason for IPv4 is inertia. Routing would be complicated when have to deal with variable length addresses when half the hosts don't know about them and half the routers remove them. I…

Windows still doesn't support CLAT in it's default view. IOT devices don't support CLAT

As such you still need an ipv4 network, so why bother with ipv6

CLAT should have been baked into the kernel 15 years ago.

Re: My security camera shipped a GitHub admin token in its login page

#264

Earlier quoted context omitted.

>limited to 10. and 102.168 I assume you meant 10.x.x.x and 192.168.x.x -- (and 172.16.x.x?), ie the standard subnets for home router-modems (which are non-routing and so can't be used on the internet).

Of course... this would transitionally make the ipv6 internal addresses easier to understand in the context of typical migration... you have the public prefix and the public ipv6 addresses of your internal network map cleanly to the internal/nat'd ipv4 ... you could still use any ipv6 internally once most of the internet transitioned.. but it'd be easier to reason with at least... I still don't know WTF/HTF ipv6 addr…

Public IP6s are allocated the same as ipv4, either ask for a block (I assume you'll need your own AS and appropiate method to announce), or your ISP hands you a block (should be a /48 I think, or maybe a /56)

Private you can do whatever you want in the fd00:: range

fd00:1:/64 for vlan 1 fd00:2:/64 for vlan 2

etc

Or

fd00:ea7:cace::/64

fd00:b00b:13s::/64

Or have your hosts on

fd00:192:168:0::1 fd00:192:168:0::2 fd00:192:168:0::3

(you don't have to have your router on :0 if you don't want to, just like you don't have to use .1 or .254 in a ipv4 /24)

If you want to allocate a given IP to a given mac address centrally then you need DHCPv6 as normal. The problem is that because dhcp isn't as required as it is under v4 (because of slacc), not all clients will support it, or support it properly. For desktops + servers you should be fine though.

Re: My security camera shipped a GitHub admin token in its login page

#265

Earlier quoted context omitted.

It's literally impossible to avoid long addresses being long or short addresses running out. One of those is a worse problem.

The length isn’t the only thing that makes the ergonomics suck. The lack of backwards compatibility sucks. The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative. The shorthand is not intuitive (though it’s not CIDR-level counterintuitive). Really, there’s way too much about wor…

But v6 _is_ backwards compatible though? It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how is this not backwards compatible? You could make a reasonable argument that it has too many backwards compatibility methods, even.

> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative

If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.

If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.

Post reply on HN