ownership, leasing, renumbering, and that draft
Robert Elz <kre@munnari.oz.au> Tue, 22 August 1995 11:51 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08710; 22 Aug 95 7:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08705; 22 Aug 95 7:51 EDT
Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07306; 22 Aug 95 7:51 EDT
Received: from munnari.oz.au (munnari.OZ.AU [128.250.22.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id SAA06963 for <cidrd@iepg.org>; Tue, 22 Aug 1995 18:31:34 +1000
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06919; Tue, 22 Aug 1995 18:31:04 +1000 (from kre@munnari.OZ.AU)
To: cidrd@iepg.org
Subject: ownership, leasing, renumbering, and that draft
Date: Tue, 22 Aug 1995 18:30:43 +1000
Message-Id: <11745.809080243@munnari.OZ.AU>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Elz <kre@munnari.oz.au>
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
- ownership, leasing, renumbering, and that draft Robert Elz
- Re: ownership, leasing, renumbering, and that dra… Tim Bass
- Re: ownership, leasing, renumbering, and that dra… Tim Bass
- Re: ownership, leasing, renumbering, and that dra… Brian Carpenter CERN-CN
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Steven J. Richardson
- Re: ownership, leasing, renumbering, and that dra… Bradley J. Passwaters
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Robert A. Rosenberg
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tim Bass
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… bmanning
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… bmanning
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… bmanning
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… Robert Elz
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Michael Dillon
- Re: ownership, leasing, renumbering, and that dra… Dave Crocker
- Re: ownership, leasing, renumbering, and that dra… George Herbert
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Michael Chui
- Re: ownership, leasing, renumbering, and that dra… Robert A. Rosenberg
- Re: ownership, leasing, renumbering, and that dra… Robert A. Rosenberg
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Tim Bass
- Re: ownership, leasing, renumbering, and that dra… Per Gregers Bilse
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Erik-Jan Bos
- Re: ownership, leasing, renumbering, and that dra… Tim Bass
- Re: ownership, leasing, renumbering, and that dra… bound
- Re: ownership, leasing, renumbering, and that dra… Piet Beertema
- Re: ownership, leasing, renumbering, and that dra… bound
- Re: ownership, leasing, renumbering, and that dra… Dave Crocker
- Re: ownership, leasing, renumbering, and that dra… Randy Bush
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Per Gregers Bilse
- Re: ownership, leasing, renumbering, and that dra… Tassos Nakassis
- Re: ownership, leasing, renumbering, and that dra… Nick Williams
- Re: ownership, leasing, renumbering, and that dra… bound
- Re: ownership, leasing, renumbering, and that dra… bound
- Re: ownership, leasing, renumbering, and that dra… Dave Crocker
- Re: ownership, leasing, renumbering, and that dra… Yakov Rekhter
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Jim Dixon
- Re: ownership, leasing, renumbering, and that dra… Robert A. Rosenberg
- Re: ownership, leasing, renumbering, and that dra… Sean Doran
- Re: ownership, leasing, renumbering, and that dra… Sean Doran
- Re: ownership, leasing, renumbering, and that dra… Piet Beertema
- Re: ownership, leasing, renumbering, and that dra… Scott Bradner
- Re: ownership, leasing, renumbering, and that dra… Piet Beertema
- Re: ownership, leasing, renumbering, and that dra… Jim Dixon
- Re: ownership, leasing, renumbering, and that dra… Scott Bradner
- Re: ownership, leasing, renumbering, and that dra… Sean Doran
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Tony Li
- Re: ownership, leasing, renumbering, and that dra… Noel Chiappa
- Re: ownership, leasing, renumbering, and that dra… Sean Doran
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Curtis Villamizar
- Re: ownership, leasing, renumbering, and that dra… Frank Kastenholz