Policy Statement on Address Space Allocations

Peter Galbavy peter at demon.net
Mon Jan 29 15:13:52 UTC 1996


>   > I wish I knew. In this I am the worst type of couch potato. ....
> 
> So stop critising "paradigms" without proposing better ones or at least
> research the rationales and history behind them.

OK OK. I am trying to make some form of contribution :) Give me a little
time.

>   > And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses
>   > are not. 
> 
> First you missed the emphasis on *somewhat*.  Second you are guessing wrong. 

OK. But for informational purposes is there a figure available ?

> From both of the above it seems that you only know of and are only concerned
> with your own particular situation. 

I would have to say, from reading my own e-mails that maybe I have given
that impression. Let me reqind a bit and summarse it differently below...
This should *not* have been the case.

>   > This is no ones "fault", just the way the policy is. Therefore
>   > I say the policy is WRONG.
> 
> What is the better policy?

Maybe that is what this thread can begine... a discussion of a different/
better policy ? Who knows ?

> More local topology than continental one is *very* important.

Yes. How can we help to make this happen ? Are there tools, that if we
make sure our RIPE records are up to date that will help you in your
allocations ?

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.

>   > We have e-mail for admin - it is timezone orthoganal. The existance
>   > of the RIPE NCC should just be remote, local staff for the InterNIC.
> 
> Fine with me. Do RIEP and theother contributors agree? 
> We can re-organise starting next week.

I am not sure I meant you to agree with me on this one... :-)

>   > If the RIPE NCC applies a "local model" then it is not conforming
>   > to the policies of IANA and the IAB that you keep referring to.
> 
> The RIPE NCC applies local policies within the boundaries of the global
> policies.

The problem is that various people posting to this list change which set
of policies they refer to whenever the "other" set suits better for their
arguments. One set of goals please. Please.

> I could help you washing in detail but I do not think this is appropriate 
> in all these fora. For the record I will summarise:
> 
> 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
some of the reasons we do it this way below. But reasons do not change
or infulence the current RIPE/IANA policies - which is the thing I am
trying to highlight for "discussion". I am *NOT* trying (I know that it
may look that way) to say that the RIPE NCC is full of people who don't
care and are not doing "the right thing". This is patently untrue...
Daniel et al are doing a very good job within their interpretation of
(in my belief) an incorrect, incomplete frame work.

> Indeed we have allocated you a /19 to start with in addition to the 
> address space you have been allocated for other purposes than dial up IP.  
> Of course you will receive further allocations within the range of the 
> above policy whenever you need them.  Of course we will do our best to 
> make the further allocations aggregateable with previous ones. 

The primary issue with this one is not that of not getting the address
space, but of getting additional address space in a timely fashion. By
the time I write this we would have taken on another 150 - 200
customers since Friday. That is almost one /24. This (at a guess for
growth) gives us about 2 months for a /19. It takes too long (in the
real world - with holidays, sickness etc) to apply for a new allocation
only days or a week before this (or the next) block runs out. If we can
apply for a /19 at least 30 days before we need it then this may solve
the problem, but I do not think this would work within the current
applications processing methods. Or would it ? I don't actually know at
this point, since we have been very concerned at how long it took to
get the last block.

> Assignments of address space by local IRs to customers have to be
> registered in the RIPE (whois) database.  You have raised that your
> commercial interest of keeping your customer list confidential should
> outweigh this registration requirement in the case of individuals
> because of the special characterisitcs of the (consumer) market you
> operate in.  We have recognised that the tradeoff between the benefit of
> registration and the commercial interests of individual dialup providers
> is indeed special and consequently have worked with you(!), IANA and the
> other regional registries to establish a global policy for this special
> case.  This policy has to take into account the need for verification of
> assignments since the registration requirement has been dropped and the
> database is not available for verification. 

It is not (even) a commercial confidence interest, since I believe that
the RIPE NCC could be trusted with this information, but one of *LAW*.
The EEC (as it was then) quite correctly required the UK parliment to
pass a law called the Data Protection Act in 1984. In my opinion this
act is far *too* weak, but even in its current form does not allow us
to pass these detais on, with a small number of exceptions.

> We have worked with you in this matter, you have agreed to the result. 
> I think it is *very* inappropriate to publicly abuse those who have
> worked with you and to throw polemics at compromises some of which you
> have even suggested and all of which you have agreed to.  I will leave
> the polemics for what they are. 

OK. OK. I will publicly apologise for any offense I may have given to
the *people* involved. You have worked very hard trying to be fair. I
just do not think that the underlying policies from which this fairness
is drawn is correct for all situations. I will not apologies for
critising policies that I believe to be flawed or the organisations
that blindly implement them. I *do* believe that people run these
organisations and that the policies should allow these people to behave
like human beings and make judgements based on experience rather than
a fixed, immutable set of criteria.

>   > I wish I had the time, but it appears that we will have to make the
>   > time to get more involed. sigh.
> 
> Yes, it is more appropriate than polemicising publicly.

I am here now in Amsterdam at the RIPE meeting, I am happy to try
to make a contribution.

>   > The RIPE NCC model probably would work if it took into account that
>   > fact that its members are (on the whole) commercial organisations
>   > that sell differing products and services and have different
>   > requirements of the NCC. This does not appear to be the case.
> 
> You have received sufficient address space for your present needs
> and you have been assured that -unless there are policy changes- you
> will receive enough for your future needs. The same policy is
> applied to everyone.
> 
> --- Polemic mode on ----
> 
> I have the slight suspicion that for you the only good model is
> one that does exactly what *you* want, everyone else be damned.
> 
> --- Polemic mode off ----

Nope. I am always open to critisism and people pointing out me errors.
I do not think that the only policy that would work is the one that
would fit my situation, but owing to a lack of involment in the
"politics" of the Internet in the past 24 months or so (how long I have
been in the serice provider game officially) those policies have 
happened without me seeing them, and so the bits that could make it all
work for me/us have been either missed or overlooked.

For a bit of background on why Demon use static IP allocation, and
how, for those who are interested as opposed to just being opposed...

When the service started (and I was just a customers) there was *NO*
other reasonably priced IP service for individuals / small companies in
the UK. Anyone want to disagree ? Right...

Demon were set up to provide and Internet *service* not *access*. Please
note my terminology on this one;

Internet Service: Being a real host, providing full SMTP capabilities
(ie mail transport, not mail access), fixed/unique FQDN, in effect
being a full Internet site when connected.

Internet Access: Getting access to WWW/POP3 etc, "using" the Internet
to get information through search engines, e-mail stored in a mailbox
etc etc. Being a Web surfer tupe consumer.

It is difficult to enumerate the difference to well, but I think most
people who have thought about it could. Some people also think of
it exactly the other way around.

We now have very close to 60000 dialup customers, each with their own
FQDN and IP address. So far this "just" overflows a class B, once we
include all all the other bits of equipment and the slightly sparse
address space in the "secure" /24 subnets.

Thre are a number benefits of static IP, just as there are
disadvantages.  We use a proprietary dynamic routeing protcol, which
has been worked on very heavily over the years to provide (effectivley)
invisible routeing changes when customer log in to the lines. The
disadantages are the point of this discussion.

I know a number of customers who use the IP addresses of the dialups
for security and filtering (do that with a dynamic IP address). Another
one (not so often used, but damned useful) is the ability to continue
TCP sessions between disconnets (many a large FTP saved my this).
There are others, but this e-mail is long enough already.

This is a religious argument that I do not believe has any *real*
impact on address space allocation except for a cosmetic one. So what
if we gave almost every PC/Mac/UNIXen box in the world an IP address.
Even in IPv4 space there are plenty for the coming years. IPv6 may be
adopted for real in a few years, and by then it all changes anyhow.

*ANOTHER* important one, but much more unlikely, is that we may one
day (and pigs will grow wings and fly) offer all our customers a
*permanent* connection to the 'net - what then ? The telecoms
technology allows for it - it is just down to tariffing. Just
a thought.

Again - I have not inteded any of this as an attack on the dedication
of the RIPE NCC staff, I just get carried away (I think I am human
after all),

Anyway, enough of this, I need to do some "work" here - I left my
colleagues at RIPE while I cam to our offices to try to catch up with
e-mail...

Regards,
-- 
Peter Galbavy                                                 peter at demon.net
@ Demon Internet                                      phone://44/181/371_3700
                                            http://www.wonderland.org/~peter/
                  snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/



More information about the NANOG mailing list