Hacker News new | ask | show | jobs
by MichaelGG 4497 days ago
> 1. In theory.. IPv6...hierarchical.

Is that even remotely close to being true in practise? Would we expect to see it be smaller than IPv4? Given the quadrupling of address sizes, wouldn't that mean there'd need to be 1/4th the number of routes? And peering destroys the hierarchy, does it not?

I was under the impression that the hierarchical routing had an assumption that networks could renumber at will. So multiple subnets might map to the same host or something to that effect. Is that incorrect?

>3. NAT is not a security feature

Except it turns out that proper NAT is equivalent to a firewall with inbound deny, outbound allow. Which is a pretty good start for security.

>ALG for every protocol

Applications that break with NAT usually do so due to poor design (hey SIP and FTP). With a firewall with default inbound deny, programs can't just accept inbound connections without doing work anyways (UPnP or whatnot). Although sure, it makes known-two-way datagram applications easier since you start transmitting and get a flow opened. Wouldn't help TCP based applications, for instance.
1 comments
welterde 4497 days ago
> Is that even remotely close to being true in practise? Would we expect to see it be smaller than IPv4? Given the quadrupling of address sizes, wouldn't that mean there'd need to be 1/4th the number of routes? And peering destroys the hierarchy, does it not?

No.. the point is that each ISP will get only one very large prefix (/32 or bigger) instead of many small ones, which can't be aggregated like it is the case for IPv4.

Right now there are about 46k ASN's in the legacy internet announcing about 490k IPv4 routes. Best case with IPv6 you would end up with 46k routes.

In practise it looks like there are 8k ASNs in the internet announcing about 16k IPv6 routes. So while not perfect, it's still quite a lot better than for the legacy internet.

> Applications that break with NAT usually do so due to poor design

So how would you design a P2P application that has no poor design?

link
MichaelGG 4497 days ago
Might the current IPv6 numbers just reflect that a lot of people aren't peering or anything? I was under the impression that a lot of announcements were driven by the need for not relying on a single provider.

>So how would you design a P2P application that has no poor design?

SIP and FTP break even in non-P2P scenarios, so my comment was mainly directed at them. For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.

link
welterde 4497 days ago
> Might the current IPv6 numbers just reflect that a lot of people aren't peering or anything?

Peering doesn't require you to announce more routes per se, although some networks do it for traffic engineering purposes. From an BGP [1] perspective there is not that much difference between peering and transit.

> I was under the impression that a lot of announcements were driven by the need for not relying on a single provider.

Multihoming is another issue. And you can explain the difference in the number of AS [2] as networks not having deployed IPv6 yet. But the number of announced routes per network will be lower for IPv6 than it is for IPv4 (which hasn't even reached the worst case yet).

> For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.

But that way you are still pushing more logic into the applications (namely that they have to implement UPnP). Which actually might end up requiring more code than your actual application (SAFT [3] for instance..). Now in the firewall you could just allow known-good inbound ports and be done with it.

[1] http://en.wikipedia.org/wiki/Border_Gateway_Protocol [2] http://en.wikipedia.org/wiki/Autonomous_System_%28Internet%2... [3] http://fex.rus.uni-stuttgart.de/saft/sendfile.html

link