ietf
[Top] [All Lists]

RE: [Ietf] 240.0.0.0/4

2004-04-22 12:15:32
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>