Re: Policy Statement on Address Space Allocations

[Michael Dillon <michael () memra com>]

On Mon, 29 Jan 1996, Peter Galbavy wrote:

> ISPs are not given the opportunity to apply for topological *and*
> portable address space (eg we are multihomed to the US - Sprint
> allocations are not "good enough") from the InterNIC - we are sent
> to the RIPE NCC because our physical location happens to be within
> a geographical domain managed by the RIPE NCC.

You are the biggest ISP in Europe aren't you? How big? Couldn't you spend 
a few quid on incorporating Demon Internet Services Inc. in the USA? 
Wouldn't you then be eligible for IP addresses from the US Internic?

> > Demon is statically assigning IP addresses to dialup customers on a
> > large scale.  This results in adresses being used per customer and not
> > per dial-in port.  Obviously then number of customers is less limited
> > than that of dial in ports.  There is concern about the wastefulness of
> > this practise on a large scale and the non-linear effects it could have
> > on address space usage.  Hence it is *global*, read IANA, policy to
> > strongly discourage this practise and not to allocate more addresses
> > than three months worth of usage.  This is not just an NCC policy! 
>
> In the way we assign numbers, it is very linear. Just not all the hosts
> are reachable all the time. We return ICMP Host Unreacable from our core
> routers when a dial up customer is not logged in. I will try to explain

In a classless IPV4 world in which the old Class A address area is in 
production use, would we have enough available IP addresses for providers 
to do this on a large scale assuming that they would have near 100% 
utilization in the blocks that were being allocated statically?

Didn't the experiment with 39/8 show that it was safe to allocate 
classlessly out of the old Class A addresses?


Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-546-3049
http://www.memra.com                             E-mail: michael () memra com