Dean Anderson wrote: > ... > Ok, fair enough. Instead of "hosts" in the traditional sense, the above > should be considered as '... approximately 20 million simultaneous uses of > unique IP addresses'. > > > > that must each have direct access to any of the rest, and you can't > > > NAT internally, then you probably have reached a point where you will > > > need a more sophisticated mechanism than NAT to reach the public > > > internet. > > > > You assume a network & traffic model that may not apply. > > _I_ don't make that assumption. This was asserted by the person who > suggests that there is not enough private IP address space. Otherwise, > they would not need more than 20 million unique private IP addresses. > > Either we accept it as a given that they really do need more than ~20 > million unique private IP addresses and also do need to reach the public > network, or else assert that perhaps no one really needs more than ~20 > million unique, private IP addresses while also needing to reach a public > network. Or alternately, assert that if such a case does exist, then it is > so unusual that some more sophisticated mechanism is needed for that case. You appear to overlook the case that H-D ratios apply to large complex enterprise networks just as they do to ISPs. Also, it is not necessary for all nodes to need public access. As soon as any do there is a need to avoid using any public prefixes on the internal network. > > > > Underlying this is the question of whether such a large network really > > > needs to simultanously reach the public network. If it doesn't, then > there > > > is no reason to limit oneself to the RFC 1918 space. > > > > Yes there is when some of the nodes do need access to the public > network. > > You can't expect to use a private version of a publicly routed prefix. > > I don't think you understood my text. I meant "If it doesn't [need access > to the public network], then there is no reason to limit oneself to the > RFC 1918 space" I understand what you wrote, but I think you are being overly simplistic. In some scenarios it is very likely that only 5% of the nodes need public access. This creates a situation where acquiring more public allocation is impossible due to current policy. At the same time there is no room to grow without guessing which /8's are going to be allocated last. > > > > I might also suggest that such a heavy address user migrate to IPv6 > > > internally as IPv6 has similar problems and it is developing means to > deal > > > with them. > > > > Easy to say, but turning something with that mass takes more time than > the > > dentist office network. Yes it is the right thing to do, but don't > expect it > > to happen in a timeframe shorter than 3-5 years. > > That is the same (or perhaps shorter) lifetime as changing the class E > definition. Changing the Class E definition will take longer because people will be less inclined to change an IPv4 stack until it clearly breaks. At that point it is generating support calls so the reality is people will do whatever they can to avoid using Class E addresses. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf