Re: ownership, leasing, renumbering, and that draft

Tim Bass <bass@unix.lajes.af.mil> Tue, 22 August 1995 12:36 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09207; 22 Aug 95 8:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09203; 22 Aug 95 8:36 EDT
Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa08032; 22 Aug 95 8:36 EDT
Received: from unix.lajes.af.mil ([132.30.140.5]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA07743 for <cidrd@iepg.org>; Tue, 22 Aug 1995 19:58:04 +1000
Message-Id: <199508220958.TAA07743@nico.aarnet.edu.au>
Received: by unix.lajes.af.mil (1.38.193.3/16.2) id AA25347; Tue, 22 Aug 95 10:02:58 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Bass <bass@unix.lajes.af.mil>
Subject: Re: ownership, leasing, renumbering, and that draft
To: Robert Elz <kre@munnari.oz.au>
Date: Tue, 22 Aug 1995 10:02:58 -0800
Cc: cidrd@iepg.org
In-Reply-To: <11745.809080243@munnari.OZ.AU>; from "Robert Elz" at Aug 22, 95 6:30 pm
Mailer: Elm [revision: 70.85]

> 
> I have been quiet on this list for some time now, since
> starting all this debate by daring to question the merits
> of the draft under consideration (draft-ietf-cidrd-ownership-01.txt)
> 
> Since then I have been told that it is improper to object to
> a draft without proposing an alternative, which I knew of
> course in any case, [and which is usually a reasonable position
> (occasionally something is simply so brain dead and unworkable
> that even without an alternative it must be opposed)] and so
> proposed a couple of alternatives in my original message.
> 
> I have also been told that it is not permitted to mention any
> alternatives on this list, as this isn't the list for that
> (that is, this isn't the working group for that).
> 
> Consequently, in this message you won't find me expressing a
> direct opinion on what should be done with the draft, as doing
> that without proposing an alternative (assuming of course, that
> I would be objecting to its progress) is not the best thing to
> do, and the latter is out of order.  Oh well, perhaps you can
> draw your own conclusions from the facts/opinions that I think
> I am permitted to send here - or perhaps more accurately, which
> haven't yet been ruled out of order.   Note that if a chair, AD,
> or doc author, questions this message with a response like
> "Well, what else can we do?" I will take that as an explicit
> OK to go ahead and post my suggestions, and debate their merits.
> 
> First, on the question of what is the current state of play
> with regard to address assignments, and whether this draft is
> changing the state of the world, or merely making explicit
> something that was always there, but hidden ... clearly this
> is a change.   It may have never been expressly stated that
> numbers allocated were owned (what does it really mean to own
> a number anyway), it has however always been assumed (and
> practised) that a number once allocated remained with the
> organisation it was allocated to as long as that organisation
> desired to retain it.  That is, more precisely, that number
> would not be allocated to any other organisation.  There is a
> long established principle (of law) that permitting a state
> of affairs to remain long enough, and allowing others to rely
> on that, abrogates any right to claim otherwise.
> 
> Now this is not, of itself, an objection to the aim of the
> draft, but to the way it is written.  That is, if address
> leasing is decided to be the way the Internet needs to move,
> then that decision should be made in a frank and honest way.
> That is, the draft should simply say words like "Until now,
> addresses have been allocated in perpetuity, this cannot
> continue (for reasons explained), and consequently a change
> needs to be made.   This document makes that change".
> 
> Second, there exist words in the draft that exempt existing
> numbers from this scheme.  I have some comments on that.
> 
> First, the most minor issue is existing "as of when", which has
> been asked before.  And answered as well.  This is not really
> important - it's a pick a date, and be done with it, though the
> draft should be more explicit about just when that date is,
> perhaps with words like "as of the publishing of this draft
> as an RFC".
> 
> What is relevant is what is the definition of "allocated" at
> that time, whatever it is.   If I go to my service provider a
> week or two after the operative date, and ask for a new number,
> and the service provider allocates it out of a block they
> obtained before the relevant date, is that an "already allocated"
> number or not?   If I have a number I have had allocated for years
> now (say one from the SRI NIC, to put it in perspective), but
> which hasn't been used for almost as many years, that is, it
> is not currently consuming any of the precious router table
> space, is that number exempt from renumbering should I decide
> to start using it again?
> 
> For a draft attempting to set in place a major policy initiative
> this one is terribly lacking in detail.
> 
> Next, on the same issue, are we guaranteed that existing
> numbers, however they are defined, as of the relevant date,
> will never need to be renumbered?    Who is in the position to
> make that guarantee?   Is the cidrd working group able to
> force providers to accept ancient old numbers and provide
> routing for them?   Since this doc is proposing means of
> keeping routing working, isn't it rather a cop out to simply
> ignore all the existing address allocations, as if they weren't
> a major (perhaps the major) part of the problem being faced?
> 
> Would it not be better, if leasing and renumbering is the
> solution to the world's routing problems, to simply make
> the policy apply to everyone - which avoids all of the above
> definition problems?   Of course it does rather raise the
> issue a little higher among those IETF people who get to
> decide on whether the draft should move forward or not, at the
> minute everyone taking any notice of this issue (or essentially
> all of them) can sit back "this doesn't affect me" and allow
> it to slide by - which wouldn't happen if all of those people
> were faced with renumbering.
> 
> On a related issue, every time a concern is expressed by someone,
> on how they would not be able to renumber, the standard answer
> is "this doesn't apply to you, only new allocations".  That is
> an inappropriate response.   True, it deals with the particular
> case raised, but fails to notice that these are just examples
> of situations that arise all the time.  New organisations, not
> yet connected, and not yet holding immutable numbers will find
> themselves in all of the same situations as those of us who
> are connected now, with all of the same problems we would face
> if forced to renumber.   When responding to those who object
> on this basis, the defenders of the draft should look beyond the
> immediate objection, and into the reasoning behind the
> objection, and explain how a new organisation, not yet
> connected, not yet with a number, and consequently not yet with
> the knowledge, even if with the means, to object, would avoid
> the problems posed by those who do now have a connection, but
> are being exempted from this draft.
> 
> Then there is the qualification that private nets are not a
> concern of this draft, it applies only to "the Internet".
> At first glance that seems resaonable, people building their
> own private nets can use any numbers at all, right?   That
> is, those defined for the purpose in RFC1597 (or its successor
> when, and if, published), or simply any other numbers picked
> at random.
> 
> Well, not quite.   This ignores the value of addresses assigned
> to be unique, world wide, regardless of to what the addresses
> are connected.   There seems to be some view prevalent that
> there is the Internet, and it is important, and then there is
> everything else, and that is all irrelevant.   All those other
> nets have just the same needs as the Internet - they are just
> typically a little smaller (or a lot smaller).   Two
> organisations that wish to connect to each other need to agree
> on a numbering plan that avoids conflicts - they need some
> address allocation organisation to deal with this.  Of course,
> for two of them, even several hundred, that isn't hard.
> 
> Where the difficulty arises is where two such private nets
> decide to interconnect, having previously used independant
> number allocation plans.   Nightmare is the correct description
> of the results - however of course the draft's standard answer,
> "renumber", is a plausible solution.   If the two medium sized
> nets that are now to connect are doing that as two entities,
> and are able to renumber, then that solution even works.
> 
> However consider the case where the two nets are not connecting,
> instead one organisation connected to one of those nets wants
> a connection to the other (simultaneously).  That organisation
> can renumber itself, if necessary, so as to remain unique on
> both of the nets to which it is connected, but how can it
> renumber other organisations on the two nets, which know nothing
> about each other, have no intent to communicate with each other,
> but happen to have picked the same net numbers?  If my
> organisation sends a packet addressed to 10.1.2.3 (where both of
> the other organisations have selected net 10 from 1597), how is
> my router supposed to decide to whom to send it?   Sounds a
> little difficult to me.
> 
> There is a reason that unique numbers have always been
> recommended to everyone, connecting to the Internet or not
> (and which is why there are more non-connected allocated numbers
> than connected ones).   It wasn't just that it "seemed good
> at the time".  When we start to break the kinds of assumptions
> that are the basis of the IP protocol suite we really need to
> be very sure that we know exactly what we are doing, and that
> we have considered all of the ramifications.  The answer "we
> don't know any other way to survive" probably just means "we
> aren't bright enough", and should lead to more work to look
> for a solution that has probably been there all the time,
> unnoticed.
> 
> Now I imagine that those who are going to object to this have
> already got out their "irrelevant to this draft" big red
> pens, or whatever, as 1597 address allocations are not being
> directly addressed in it, and the question of whather they are
> a good thing or not belongs in another discussion.
> 
> Yes, so it does - with one caveat, and that is that this draft
> doesn't change anything wrt those kinds of allocations (or non
> allocations).  Unfortunately, it does.  The problem relates to
> just who does address assignments.  If address assignments are
> now to be leases from providers, to whom does an organisation
> without a provider turn if they decide that they need a unique
> address?
> 
> One of the standard rebuttals to this is "the Internet shouldn't
> be subsidising outsiders", and nor should it - the organisation
> requesting a number should be paying whatever costs are incurred
> in granting that request, however that certainly is a side
> issue that isn't relevant here.
> 
> If addresses are still to be available to outsiders, from
> somewhere, so they can have addresses that are known unique,
> and which they can use to build their own private (though
> possibly large) independant nets, and then interconnect with
> each other, then what is the relationship of those numbers
> and this draft?
> 
> If the organisation, whatever it is, that granted these numbers
> finds that its original lease for its address block has expired,
> and that it cannot be renewed, what happens to the addresses
> it has allocated to unconnected third parties?   Is it really
> correct to claim that this draft does not apply to such cases?
> 
> If the effect of this draft is that unique addresses are no
> longer to be available to non-Internet-connected organisations,
> then it should say so explicitly, and justify that decision.
> 
> Recall, this is the IETF - the IETF makes standards for all
> users of the IP protocol suite, not just the connected Internet.
> Anything published with the IETF stamp of approval should be
> able to apply equally to all users of the IP protocols.
> 
> And finally (I hope) for this message, the draft claims that
> an option for a site faced with renumbering is to decide not to
> do so, and accept limited connectivity instead.   Let's
> examine that option for a minute, and let's take the best
> possible case for this to apply.
> 
> Assume that a site (X) has an IP number that has been leased to
> them, and connects to a provider (P) using that address.  
> Further assume that the only party with whom X has any interest
> in communicating is one other site (Y) which happens,
> conveniently, and probably not accidentally, to have a
> connection to the same provider (P).    Now assume that X's
> address lease expires, and for whatever reason, it decides that
> renumbering is not an option for it.
> 
> The draft covers this case explicitly, or it seems to ...
> 
>    If the organization doesn't require Internet-wide IP connectivity,
>    then renumbering can be avoided. In this case the organization may
>    still maintain limited IP connectivity (e.g. with all the subscribers
>    of its direct provider) by limiting the scope of its routing
>    exception to its direct provider.
> 
> Now that fits X perfectly, that is exactly what X doesn't
> require, all it needs is connectivity to Y.   Consequently,
> it accepts the terms of the draft, has its routing advertisments
> limited to its direct provider (P), where they still reach Y,
> and in theory, everyone is happy.
> 
> But what about the rest of P's customers?   We assume it has
> some here.  If P is routing packets bound for X's address to
> X, as it has to do to retain connectivity between X and Y, how
> do any of the rest of those people manage to communicate with
> whoever has been reassigned the address that was (nominally)
> taken from X when its lease expired?
> 
> Of course, there is a hidden assumption here, which is that
> addresses reclaimed upon lease expiry can be reallocated.
> Address conservation issues would tend to support this as
> a reasonable practice, but perhaps that is not what the draft
> intends, I can't find any explicit statement on that issue
> one way or the other.   Perhaps one should be added so this
> question can be addressed more precisely.
> 
> Perhaps the aim is that addresses, once expired will be placed
> into a pool of "unable to be used or routed" addresses, and
> forgotten, or something.
> 
> Note that X might have come to P from provider Q, precisely to
> get connectivity to Y (perhaps with some service guarantees
> that couldn't be met via whatever connectivity existed between
> P and Q) bearing an address that was allocated (leased) by Q
> originally.   X is still unable, or unwilling, to renumber.
> So P's other customers can continue to continue to communicate
> with all of Q's customers, existing and future, Q needs to
> remember that it never actually received the address back from
> X, and so never allocate it again.   Further, the relationship
> between Q and X might not be good, X may refuse to tell Q even
> if it does stop using the address - P may also not be a good
> friend of Q's, and even if it is, doesn't necessarily know all
> of X's intentions.   So there is no way that Q can tell that the
> address is now free for use in the general case - it really has
> to assume that it is immediately free after the lease has expired
> (plus any grace period), or it has to assume it is never
> available for re-use.
> 
> This won't (needn't) have any adverse implications for the
> routing system, but it seems it may have in other areas.
> 
> Of course, the alternative would be to delete this paragraph
> about limited connectivity (offering a little hope to those for
> whom renumbering is not a viable option) and replace it with
> one that explicitly says "renumber or no connectivity", but
> perhaps that might be too politically sensitive to attempt.
> 
> There's also the waffle about what size prefixes can be
> moved around without renumbering, which has been pointed out
> before, and which I find one of the most imprecise and
> meaningless specifications I have ever seen (it leaves the
> "best" of the used car contracts for dead).
> 
> To finish, I find the draft imprecise, incomplete, inaccurate,
> lacking in intellectual honesty, and impossible to actually
> use for any practical purposes.
> 
> However, I am not permitted to draw a conclusion from that,
> as to what should be done with it, as before doing so I would
> need to offer an alternative.  I will not suggest new words for
> a draft I feel is fatally flawed in any case - that would be
> a waste of effort, and I am not permitted to offer my
> alternative, so at this point I think I have to leave it to
> others in the working group to make up their own minds - and
> eventually the IETF as a whole.
> 
> kre
>