James Knott <james.knott@rogers.com> writes:
[1. text/plain]
Rüdiger Meier wrote:
On Thursday 17 November 2011, James Knott wrote:
However, this is an example of someone being stuck on IPv4 methods. With IPv4, the shortage of addresses limited what an ISP could offer. With IPv6, there's absolutely no valid reason for not offering at least a /64 subnet.
Of course there are valid reasons for this...
Such as??? As I mentioned, I can configure my tunnel for a subnet or single address, but that's my choice.
They grant you the right to do so, but they have no obligation, that's two very different things. Valid reasons? Sure: In Germany every network operator has to maintain a database of *all* connections from within this networks to the outside for 6 months, let me take your numbers from below: For a new outbound connection, I have the freedom to use the current epoch time (as in the original definition) makes up 32 bits, then the process id, 48 bits, then I have 16 bits to spare. Assume I just enumerate my connection, the first connection is 1, the second 2, and so on. Focus on the getaddrinfo(3) call and assume there's no nscd, or the names to be resolved are changing constantly (reverse lookups in spamfilter software for instance). I am actually monitoring my dns traffic, and I think I have some 20000 lookups per day. That's 20000 different addresses I used for getaddrinfo(3) alone. Take other stuff into consideration you use up 30000 addresses per day, on one host. Add your torrent mad brother or sister on their computer, 60000. That's a staggering 1.8 million addresses per month, 11 million addresses in 6 months. And that's just one customer. Take the largest German ISP, t-online, with around 15 million subscribers, that makes roughly 167 trillion entries in their database. Quite a bit. I imagine that would be reason enough to limit the number of addresses routed in a /64 to 1 or 2 or maybe 10.
I get my IPv6 subnet from a tunnel broker and it's a /56 (256 /64 subnets).
If you want to setup your net for more than 256 users then you as their ISP would not give everybody a ::/64 net.
256 users???? A /56 subnet can support up to a trillion times the entire IPv4 address space. A /64 subnet allows 18.4 quintillion addresses. The IPv6 address space is huge. I've heard of comparisons such as the number of grains of sand on earth or the number of atoms in a ton of carbon. Another was if a 2"square represented the IPv4 address space, then IPv6 would be represented by the area of the solar system. Tell me again why an ISP should limit a customer to only one address.
See above. Another would be if they happen to be on a fragile end of the BGP tree and have to change their routes frequently, STP propagation might be fast, but to propagate a changed route if there's millions of entries in the arp table could take a while.
Of course you are a bad ISP with only such a ::/56 net almost as bad as Lew's ISP with only ::/64 for 6000 users. The reason to "not offering at least a ::/64 subnet" for everybody is still_valid_.
I'm not sure you understand what you're implying here. a /56 network means that 56 of 128 address bits are used for the network address and the remaining 72 bits are used for local subnetting and host addresses. With a /56, you can have 256 subnets, each supporting 18.4 quintillion addresses. As for an ISP offering /64 subnets, that's the minimum size that allows using the MAC address to form the host address, using the current methods, where the 48 bit MAC is padded out to 64 bits. There is no shortage of /64 subnets. In fact, there are 2^64 or 18.4 quintillion of them. Even if an ISP is handing out /48 subnets (2^80 addresses each), the number of subnets is 65K times the entire IPv4 address space (2^16 x 2^32).
So? What are you implying here? That all routers on the internet magically had a RAM update and now can hold billions of addresses? It's good to have plenty of space left for the future, but it's not wise to go and waste that space immediately, or calling setups that won't cope with what you imagine broken or wrong? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org