September 1995 - Test - lists.nanog.org

Recent discussion on address ownership from the latest NANOG
by sob＠academ.com 23 Sep '95

23 Sep '95

For those of you who are interested, a set of notes I took during the last NANOG which (I hope) capture a discussion on address ownership. The URL for this page is: http://www.academ.com/nanog/sept1995/addresses.html Enjoy.... -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Authority over IANA & IP #s was Re: 206.82.160.0/22
by stjohns＠ARPA.MIL 23 Sep '95

23 Sep '95

Generally, we like to keep a low profile - unless there's a problem. HWB's basically correct about the history. Let me explain my current understanding of where everything sits. Keep in mind at least parts of this have been disputed even within the US feds. Also, the dates and details may be a little off. The number space began life as a part of the ARPA "toy" internet. The number space was managed by the NIC at SRI under a contract with the Defense Communications Agency (which was managing the ARPANet under an agreement with ARPA) until that contract was recompeted in '88. At that time the numberspace management was transfered to the Internic under a contract (cooperative agreement) with NSF. At this point the DOD basically transfered "ownership" of the number to the Federal Networking Council (actually, it may have been to its predecessor the FRICC - I don't remember the timing). The understanding was that the DOD would continue to have first call on the number space IF they needed it, but that block and other delegations would be done by the Internic in consultation with the IANA, EOWG, IEPG etc. As new schemes have come into being (e.g. subnetting, CIDR) the gov't folks have basically ratified (mostly by silence) the use of the space. The deal with the DOD having first call on the space was to ensure that the DOD didn't give away the space and then have to start paying for it. The deal today is that the FNC (as the representative US organization) continues to own the space, but chooses to limit its control over the space to issues (e.g. paying for numbers) that it considers critical. Although the Internic performs the registrar function it does this as an agent of the US Gov't and does not own the space nor does it own the registration data. The registration function (at the top level delegation) for numbers has been funded by the US Gov't since its inception - first by ARPA and DOD, then by NSF. The name space is another matter. In approx 1986, as a result of the growth of the HOSTTABLE (can you believe all the names on the used to fit into one file?) the Internet began the deployment of the DNS system. (The internet at this time was about 50 networks total). At this time of its life, the majority of hosts on the internet were still connected through either the ARPANet or the MILNet - the growth of the NSFNet centric internet was yet to come. The initial DNS deployment was limited to the non-country TLDs (e.g. MIL, COM, GOV, EDU, NET, ORG - INT came later) - this was corrected rapidly with the introduction of the country TLDs. All of the TLDs were considered "undelegated" at the time. Shortly after this deployment started, I wrote the policies for the .MIL domain which limited registrations to the US DOD and described the rules for second level registrations (e.g. independent service or agency such as ARMY or Joint Chiefs of Staff - JCS) - this was the first delegation of the non-country TLDs. Keep in mind, the registration function was still vested at the SRI NIC which was being paid for mainly by the Defense Data Network program at DCA with some contributions from ARPA related to ARPANet operational costs. Its unclear whether DCA or ARPA would claim ownership of the root domain, but it definitely vested within the US DOD. Ownership of the root domain was transfered to the FNC at the same time as the numberspace was transfered and upon recompetition of the NIC contract the registration function for root and the undelegated TLDs was transfered to the Internic. Registrations within .MIL transfered at the same time, but this was due to the fact the DDN NIC contract was won by the same organizations. The third delegation of a TLD was made circa '88 - EDU to the NSF (INT was made to ARPA previous to this, but that's a very long story) in keeping with its mission and connections program goals. .GOV was also delegated at this time - to the US Gov't. The FNC finally issued a policy RFC covering the .GOV registrations this year. At this time, COM, ORG and NET remain undelegated at this time which basically places policy control for them under the root authority which remains with the FNC. The notes above about ownership of the Internic database etc apply here as well. I was a program analyst at the Defense Data Network Program Management office at DCA from 85 to 89. As such, I was responsible for the NIC contract and directing the technical work there. The GOV, EDU, MIL and INT domains were delegated at my direction at that time - Steve Wolff at NSF agreed to accept policy control over EDU at NSF at that time. I currently sit on the FNC exec committee. All of the above notwithstanding the general mode of operation has been to let the community work out the issues as they occur. Unfortunately, sometimes the gov't has had to make decisions and give directions to its contracts, either without community input or against community recommendations due either to legal, financial or other issues. The feds continue to fund the Internic and the IANA and have fiduciary and program responsibilities due to this. Please! Take all of the above with a grain of salt - my general feeling is that the feds feel they are holding the numbers and namespace in trust for the community and really do have the internets best interests (e.g. continued operation) at heart. Mike At 14:04 9/22/95, Gordon Cook wrote: >Well I am pleased to see this from Hans Werner too -- especially the >lines of historical authority ..... > >he said: > >formally I guess one would claim that the >Internet address space is the personal property of the IANA instrument >of the United States Department of Defense, if that is what you like. >I would prefer to think that the Internet evolved so much over the last >ten years or so into the public realm, that the address and naming >spaces have become public property. Instead of bitching about the >InterNIC, NSF, ARPA, IANA, whoever, you guys should thank them for how >far they got things driven, and whet they fostered and allowed to >transition to the international private sector. [end of Hans Werner quote] > >Cook speaking: > >Are we hearing then that **ARPA has given up any and all of its authority >over IANA**? That DOD no longer claims to own IP numbers? Hans Werner, >I'd prefer for you to be precisely correct in your assertion about the >public property nature of IANA, IP numbers etc. I'd love to thank Arpa >for giving freedom to IANA and DOD for doing the same to IP numbers. But >I have not seen any evidence that they have indeed done this. If they >have perhaps the relevant people at ARPA and DOD would come out and >confirm just exactly what they consider their current authority over IANA >and IP numbers to be? > ARPA pays the IANA bills - NSF pays the Internic bills; we have "authority" but generally choose not to exercise it. Jon has a responsibility to "do the right thing" and we let him alone to do that. Mike

2 1

Re: Authority over IANA & IP #s was Re: 206.82.160.0/22
by stjohns＠ARPA.MIL 23 Sep '95

23 Sep '95

At 23:20 9/22/95, Guy T Almes wrote: >Mike, > Nice paper, but I think you're seriously off on the recompete of the NIC. >It was more like 1992 rather than '88 as you write. Given the way the >Internet changes character each year, that was quite a difference. > Note one parallel with the current DNS fee debate: during the period >(roughly) 1987 to 1993, the NSFnet EDU community depended on a NIC that was >accountable to the DoD. There were examples of friction that resulted, but >things were mostly quite amacable. > Now the private-sector COM/ORG community is having to put up with >vestigial accountability structure oriented around the NSF. There will be >some friction, and there will be some patience, and there will be progress. > -- Guy > You're correct mostly - my dates are off on that one issue - I should have reread the paragraph. Unfortunately, none of these events are point events. The beginnings of the recompetition started in 1988 before I left DDN, the actual award didn't happen until around the date you mentioned. But, it was known this was going to happen and the DOD was getting increasing concerned about paying for all those non-DOD registrations. This resulted in a number of discussions with NSF which eventually resulted in the Internic solicitation. The seeds were planted in 1988, but took quite a while to grow. As I recall (possibly faultily), the DDN NIC recompetition completed and resulted in contract award sometime before the Internic contract was awarded - this happened after I left DDN. I think the actual award of the replacement DDN NIC contract was 91 - my language is misleading. By Sept 1989 (when I left DDN), the SRI contract had been placed on year by year extension pending getting a whole lot of issues in line.

1 0

RE: Sprint violations
by jnc＠ginger.lcs.mit.edu 22 Sep '95

22 Sep '95

From: lodge(a)houston.omnes.net (Mathew Lodge) Well, no, actually. Customers don't care who's fault it is -- as far as they're concerned, it's broken. ... my point is that customers dislike "finger pointing" when it comes to resolving a problem. It won't wash. I sympathise; customers might tend to see it as an attempt to palm the problem off on someone else, ignore them, etc, etc. Unfortunately, it is also true that if the problem is caused by someone else, you can't fix it yourself. I see this all not so much as a technical problem, as rather a customer relation one. All I can suggest (and I'm sure you already know this) is trying to help them (i.e. make it plain that you care about them, and their problem), while making it plain that the problem is not entirely within your control. You can see if there's a workaround; you can use an analogy ("It's like if you call someone else in another country and their phone doesn't work; calling Bell Atlantic isn't going to make it work"); you can try and explain to them more detail of what's going on and where the problem is, so they understand why you can't fix it unilaterally; you say something like "we'll call the other provider for you, but we can't say if or when they will fix the problem"; etc, etc. Sigh, I don't envy you guys/gals out there dealing with customers... Noel

1 0

Re: 206.82.160.0/22
by Kai 22 Sep '95

22 Sep '95

>>>Are you saying >>> that Sprint refused to allocate the space you required? >>That last sentence is based on an assumption not a known fact. >?? It was a question. Sprint wanted nothing to do with it, and referred to the Internic. I even asked for a part of a now-aggregated-but-already-fragmented-hence- soon-more-fragmented larger aggregate (which makes the most sensee). No dice with Sprint. >>I think the real problem here is that Kazakhstan should have a block of >>addresses with a short enough prefix to guarantee routing and these >>addresses should have been allocated out of this block. >No. Political geography has little to do with the topology of the >Internet, thus allocating to a country doesn't correspond to >topological addressing. One might argue that a service provider in >Kazakhstan should have a short prefix, but a similar argument can be >made for any service provider. I can definitely not justify a /18 right now, a /20 for sure, and I would already be the largest owner of IP space with that. >>The obvious solution to this immediate problem is to guarantee routing >>for the long prefix until the event in Kazakhstan is over and then to >>think hard about what to do about similar cases that are not for short >>term events. I specifically requested this allocation (for a mere /20 to satisfy the slow-start policy) as permanent, not as a recyclable temporary assignment. While it's used for one particular purpose during next week, the assignment was due for real, customer use after the event. >Right, except you can *never* guarantee routing -- it is a cooperative >effort among service providers and some service providers may choose >not to cooperate. However, the organization wishing to have the long >prefix routed may pay the routing service provider(s) extra for the >special handling necessary to insure the highest probability of >routability to the sites the organization wants to reach. But this >gets somewhat complicated. I would think an easier solution would be >to simply get a block from the upstream ISP... Everything I ever tried...and non-cooperation out of political motives (that's an accusation,actually) is something new on the internet, at least on the routing level between NSPs. tiny.sprintlink.net was down most of the day, not taking mail. Sean should have taken notice by now... --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none (phones still down due to office move until Oct. 1st)

1 0

Re: 206.82.160.0/22
by David R Conrad 22 Sep '95

22 Sep '95

>The Internic is the sole and ultimate assigning entity of IP space, Ummm, no. RIPE-NCC and APNIC also assign address space as regional registries, CANET, JPNIC, KRNIC, and AUNIC/Telstra assign space as national registries. One might claim the IANA has the ultimate responsibility regarding address space, but this is somewhat irrelevant to this discussion. >and >Sprint specifically rejected any support for me or my provider in obtaining >at least a /20 assignment from the Internic, Why didn't you obtain the /20 from Sprint? >I was given this /22 assignment >(while continuous usage of the link ensures this space will be used >up in about 3-4 weeks, with /26 assignments going to BelCom's leased line >customers) even though the Internic knew better about necessary route >aggregation. I'm confused. You were given a /22 by InterNIC which is (presumably) provider independent, and which included a statement from InterNIC that says that routing is not guaranteed (which should, of course, be obvious) and you seem to be claiming they didn't understand about route aggregation. I would assume InterNIC encouraged you to obtain your address space from your service provider (Sprint) so your routes could be aggregated in your service provider's block. Are you saying that Sprint refused to allocate the space you required? >I consider it extremely hostile from Sean Doran and hence Sprint to suddenly Sean has been talking about this for at least 9 months. >come and announce filtering of just those networks they are announcing on >their own, ENCOURAGING OTHER NSPs TO DO LIKEWISE, bypass the ultimate >arbitrator (Internic) , No. InterNIC is only the ultimate arbitrator of who a particular address is delegated to within the blocks that InterNIC has authority. This has absolutely nothing to do with routability of those addresses. There is no ultimate arbitrator for routability -- it is a cooperative effort by all service providers. Due to routers falling over, some service providers are not interested in being as cooperative as they once were. >I can only >strongly discourage the implementation of the prefix filtering for prefixes >longer than /18 in 206.* through 239.* What is your suggestion to reduce the routing overload? Regards, -drc

3 3

RE: Sprint violations
by lodge＠houston.omnes.net 22 Sep '95

22 Sep '95

At 9:10 9/22/95, Noel Chiappa wrote: >On the other hand, if Sean et al are willing to take the arrows (arrows -> >pioneers, right? :-), good for them; it will provide cover for providers to >tell their own customers "sorry, there's no use sending out your /28; Sprint >will just filter it". It's always easier to tell a paying customer "no" when >you're just relaying someone else's decision, not your own, no? Well, no, actually. Customers don't care who's fault it is -- as far as they're concerned, it's broken. I had a similar situation impressed on me today: one of our customers wants to send e-mail with MIME attachments to one of his customers who has a CompuServe account. The attachments never make it through the CompuServe e-mail gateway. Now, we know that this is not a problem with our TCP/IP network and SMTP implementation -- it's a problem at the CompuServe end. The customer knows nothing about e-mail gateways, and nor does he care. As far as he's concered, it doesn't work. And Omnes, as his solutions provider, had better fix it. I still haven't worked out how to appease this particular individual: but my point is that customers dislike "finger pointing" when it comes to resolving a problem. It won't wash. Regards, Mathew | Mathew Lodge: lodge(a)houston.omnes.net |5599 San Felipe, 4th Floor | | Internet Specialist, Omnes -- A |Houston, Texas 77056, USA | | Schlumberger/Cable & Wireless company |Phone: +1 713 513 3237 | | "Bibunt omnes sine lege" |Fax: +1 713 513 3126 |

2 1

Re: filtering long prefixes
by jnc＠ginger.lcs.mit.edu 22 Sep '95

22 Sep '95

From: Mark Kent <mark(a)mainstreet.net> The Internet is no longer an experiment. Well, yes and no. I take very well your point that it's a very large public utility (in the sense of something that people depend on), but at the same time we (i.e. humans) haven't ever built a system like this before, so it's inevitably "an experiment". Like it or not, we're going to be taking some wrong turns. (Long argument as to why this is inevitable left out in the interest of brevity.) So, there are going to be periods of pain while we back and fill. Ladies and gentlemen, please fasten your seat-belts, the ride is going to be a little choppy... Move on higher up the chain and try again. Cutting off companies retroactively is not the answer. You need to put filters in that cut no one off today, but protect against growth tomorrow. Err, umm. If we are to achieve the same *overall* degree of aggregation, accepting less/no aggregation in the numbers allocated in the past means we have to achieve a lot more aggregation (perhaps unachievable levels) in the numbers allocated in the future. Perhaps the right answer, considered as a overall optimization problem, is not quite this far to one end of the spectrum reaching from "old-none, new-total" at one end to "everyone the same" at the other. Noel

2 1

Re: filtering long prefixes
by Sean Doran 22 Sep '95

22 Sep '95

Mark - I agree with you 100% that the Internic had adopted a policy of handing out longer prefixes than I had initially warned everyone Sprint would be refusing to accept from external neighbours. I also note that the Internic also had wording which pointed out the dangers of accepting this sort of prefix from them, right on its application form, which I reproduce below. I think that the InterNIC did its job of warning people of upcoming realities, and therefore its policies were not, in fact, in conflict with ours. 206/8 was specifically chosen, in fact, because no allocations had been made from it at the time. Now, I note that I have pointed out that we are willing to be flexible when it comes to /19s, but for the moment, the filter will reject anything longer than /18s in 206/8 to 239/8. In part this is because it gives me the opportunity to study who has gotten disconnected and how difficult it will be to reconnect them without doubling the number of prefixes we will see in 206/8, not to mention 207/8 to 239/8. You may call it direct engineering terrorism if you like. I call it a sound, planned, well-announced step to keep the maximum growth of the routing tables confined to the level at which technology exists to support them. My only (large) regret is that any long prefixes in 206/8 ever worked at all, principally due to an oversight in a reconfiguration of ICM AS 1800. I hate breaking things that were already working... To translate that sentence: "Maybe. Let's see how bad the mess is first." Sean. - -- from ftp://rs.internic.net/templates/internet-number-template.txt Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers in order to reduce the number of globally advertised routes. These potential policies may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

3 2

Re: Sprint violations
by jnc＠ginger.lcs.mit.edu 22 Sep '95

22 Sep '95

From: Per Gregers Bilse <bilse(a)eu.net> One problem we see is European offices/branches of US companies who want to use parts of their "company B" for a European connection As long as people see IPv4 addresses (as currently used, as routing-names - darn I wish we had a better piece of jargon there) as a purely administrative thing, some number you get assigned randomly, this makes sense. We have to make people think of IPv4 addresses as things which say where you are in the net, things which are higly ordered. I think Sprint's approach is rather heavy-handed and probably a toad counter-productive in the long run. I would consider it reasonable for Sprint to filter their own funny stuff .. for a considerable length of time before filtering other people's funny stuff ... Plus stones and glasshouses, etc. Well, I see your point. Also, if everyone filter out subnets outbound, we wouldn't need inbound filters, anyway, right? On the other hand, if Sean et al are willing to take the arrows (arrows -> pioneers, right? :-), good for them; it will provide cover for providers to tell their own customers "sorry, there's no use sending out your /28; Sprint will just filter it". It's always easier to tell a paying customer "no" when you're just relaying someone else's decision, not your own, no? Noel

1 0