- NANOG - lists.nanog.org

Re: Incompetance abounds at the InterNIC
by Adam D. McKenna 21 Jan '99

21 Jan '99

From: Phil Howard <phil(a)whistler.intur.net> :"Some" communication? : :It's not an issue of "completely" fill ... it's an issue of logistics. : :This "communication" you speak of will involve probably thousands of :companies when you consider the whole range of all of them that interconnect :(even though they don't interroute). Any one of them that already has an :established addressing _MAY_ end up connecting to any other of them that :already has established addressing. That means this "communication" has :to basically implement an entire allocation structure. And every business :that is not even yet connected would have to be sure their use of RFC1918 :space conforms to this allocation structure. You don't sound very sure of your arguments. To which thousand companies are you referring? :Basically, it's like saying, RFC1918 space will no longer be private :address space that can be used on a whim, but instead will now be allocated :by yet another entity. Usage of RFC1918 space shouldn't be determined by "whims", it should be planned just like anything else at a company is planned, and it should be accounted for. :> The best way to do this is with a firewall (companies doing this probably :> already have one, otherwise their "private" network ain't so private), and :> just about every firewall worth putting on a box will do NAT. You map :> individual machines that need their own IP address directly through on a :> one-to-one relationship, and the rest you let the firewall masquerade :> through. Conserves "real" IP space. : :NAT wasn't a common reliable tool when these things were established. The :first of these I remember getting involved in over 4 years ago. It is a :little better today, but the good ones are very costly. You will fail to :convince the vast majority of these companies to buy an overpriced super :firewall that does highly scalable NAT reliably when their needs are met :with a low priced router (e.g. Ascend Pipeline 50 to Cisco 25XX scale). There was a discussion of low-priced high-capacity NAT solutions a few months ago on NANOG, I'm sure if you look in the archives you will find it. :Yes, if you were starting this kind of thing today, NAT would probably be :the better way to go. But as well all know, business does not just go around :spending money to revamp what is currently working fine. That's fine. As long as they don't mind spending time and money renumbering their entire network once it gets connected to the internet. :And further, that also makes 10/8 unavailable for actual internal uses for :which RFC1918 was intended. And since many such companies already do have :RFC1918 in use for the intended purposes, this isn't the space that can be :just simply moved in to. RFC1918 is entitled "Address allocation for private internets". I think it describes exactly what you are talking about. :Dream on. : :You have to include _EVERY_ company that might ever do this. Not really. Companies do not usually route their entire corporate network to each other. When one company wants to connect to another, all they need to do is come up with one or two common subnets that neither company is using at that particular time, and only route between those IP's. That way, it doesn't matter to company A what company G which is two "corporate hops" away is doing. --Adam

6 6

RE: RE: ATM Switch Interoperability
by Martin, Christian 20 Jan '99

20 Jan '99

Steve, In your experience, then, would you agree that higher SCR rates should have higher MBSs, so that the Burst Tolerance linearly increases with SCR? I have a problem with an MBS of 100 for SCR 1000 up to 1000000. CDVT gives us some bucket depth, but I don't think we're clumping. The LS1010 doesn't shape VBRnrt, just polices. At the far end is a Fore ASX1000. So, we have three different vendors in the mix. Our ATM provider sets MBS to 100 no matter the contract. This seems too restrictive. Chris > > Here is the function for the relationship of Burst Tolerance > BT (time) and Maximum Burst Size MBS > (a number of cells). Most switches allow you to set the MBS > and then they calculate the BT based > on this function. Definitions: Ts = 1/SCR, Tr = 1/PCR, ts = BT > > MBS = | 1 + ((CDVT + ts) / (Ts - Tr)) | where |x| > stands for the largest integer less than x. > for Tr > 1 and CDVT > Tr -1. > > > This function is based on using a unit of micro-seconds for > each variable. The corresponding function is used > to calculate the maximum burst size B (a number of cells) on > the PCR policing: > > B = | 1 + ((CDVT) / (Tr - 1)) | For Tr > 1 where > |x| stands for the largest integer less > than x. CDVT must be greater than Tr - 1. > > This function is also based on units of micro-seconds. It > breaks down if Tr < 1 microsecond. At that point a smaller > unit of time would need to be subtracted from Tr instead of 1 > microsecond. This only matters with very large PVCs > with a PCR of over 1000000 cells per second. > > These values for MBS and CDVT are usually defaulted for the > user and the same default applies no matter what > the SCR and PCR values are. Some ATM providers set the CDVT > and MBS very low and adjust up if problems like > you are observing appear. > > If the lightstream does traffic shape properly this should > not be an issue. If you do have traffic shaping on the lighstream > you could set the PCR=SCR. You will lose a small amount of > burst but will be able to sustain at SCR. The bursts do not > really buy you a large amount of extra traffic anyway (unless > CDVT and MBS are set high) they are really just there to > allow for variations in accuracy of policing between devices. > > Steve Murray > MCI Worldcom > steve.murray(a)wcom.com > > > >>> "Martin, Christian" <CMartin(a)mercury.balink.com> 01/15 9:19 PM >>> > >We have it matched to the policing policy of the Network > Provider. By > >increasing the CDVT, we gain some bucket depth, but we are > only MUXing 5 > >VCCs over one VP. There shouldn't be too much clumping, espescially > >considering the load on the switches(low). One thing is interesting, > >though: The far end (customers) are all running over DS3 using HEC > >delineation. > > > >A curiosity: Given the parameters below for the contract, > particularly > >the MBS and CDVT, does it appear that we are being cheated? From my > >understanding of the UNI 3.1 spec, the MBS should be adjustable > >according to SCR/PCR, given the fact that CDVT is defined as the same > >for both SCR and PCR buckets. > > > >One obstacle that myself and my colleagues have not been able to > >overcome is the use (aside from bucket calculation) of the Burst > >Tolerance. It is obviously proportional to the MBS, but again, it > >appears as if a contract specifying a PCR/SCR of > 100000/50000 cells per > >sec, should have a higher MBS than a 10000/5000 cell/sec contract. > > > >Any insights? > > > >Chris > > > > - > >

1 0

Re: Incompetance abounds at the InterNIC
by Adam D. McKenna 20 Jan '99

20 Jan '99

From: Phil Howard <phil(a)whistler.intur.net> :> That's fine. As long as they don't mind spending time and money renumbering :> their entire network once it gets connected to the internet. : :That's my point. With real addresses, it addressed the issues of having to :renumber when new business interconnections were made, or when any of them :decided to get on the Internet. NAT was not viable then, as it is today. To clarify, I was not arguing against using real addresses. What I was had a problem with was your statement that suggests that this network of companies in any way resembles the internet. It doesn't. Companies only need to be worried about the subnets that they can "see". If they are connecting to two separate companies that are using the same address space, this will obviously create a problem. However, it only takes some common sense to resolve such problems. There is an awful lot of RFC1918 space available. --Adam

1 0

RE: Incompetance abounds at the InterNIC
by Regan, Sharon 20 Jan '99

20 Jan '99

Good Afternoon: As the network admin in an organization such as described, i.e. a "semi"-private network communicating with numerous partner companies, as well as multi-homed to the Internet, I can only agree with Phil Howard's sentiments. Whereas early on the thinking may have been that networks were either "public" or "private", that is truly no longer the case. In a truly "private" network, the exclusive use of RFC1918 may very well be adequate; however a good percentage of major organizations today engage in internetworking with one another, and therefore the issue of "uniqueness" within this environment indeed becomes an issue. And, while net 10 certainly seems to contain a large number of host addresses, the reality is that establishing the "Use of Net 10 Committees" within these environments is not workable ... and any agreements established by such committees would be unenforceable. Which is why organization's such as mine insist on global uniqueness. The distinction between the capital I Internet and large, international, multi-organizational Intranets is becoming blurred and may indeed one day not exist. Respecting the issue of domain registration, it only makes sense to register a unique domain name rather than simply inventing one ... I've seen instances where an organization with bosus internal domains renders a good portion of the internet inaccessible to themselves. Just my two cents worth. Sharon Regan Internetworks Newcourt Credit Group, Inc. -----Original Message----- From: Phil Howard [mailto:phil@whistler.intur.net] Sent: Wednesday, January 20, 1999 12:49 PM To: dredd(a)megacity.org Cc: nanog(a)merit.edu Subject: Re: Incompetance abounds at the InterNIC > At 09:51 AM 1/20/99 -0600, you wrote: > >Using RFC1918 space for this won't work because there has to be some kind > >of administration of the space to ensure enough uniqueness that no two > >companies that are visible to any one company have the same addressing. > >There can be only one such administration of any practicality even though > >this "closed Internet" is chopped into isolated segments. > > Sure it will. It requires (gasp) some COMMUNICATION between the companies > involved. I don't know of many companies who between them will completely > fill 10.0.0.0/8 with all the machines that need to interconnect. I mean > that's a pissload of machines. SIXTEEN MILLION machines. "Some" communication? It's not an issue of "completely" fill ... it's an issue of logistics. This "communication" you speak of will involve probably thousands of companies when you consider the whole range of all of them that interconnect (even though they don't interroute). Any one of them that already has an established addressing _MAY_ end up connecting to any other of them that already has established addressing. That means this "communication" has to basically implement an entire allocation structure. And every business that is not even yet connected would have to be sure their use of RFC1918 space conforms to this allocation structure. Basically, it's like saying, RFC1918 space will no longer be private address space that can be used on a whim, but instead will now be allocated by yet another entity. It MAY be arguable for some entity to go to ARIN and get a /8 to do just that with. But for now, it works ... AND IS COST EFFECTIVE (something that is a very powrful driving force in business) ... by simply using the existing methods of address space allocation. > >Further, many companies with these networks also allow direct access to > >the real open Internet. That means for sure that addresses in use on the > >open Internet cannot be duplicated anywhere else. So the allocation of > >space within the closed network has to be unique even compared to the > >open Internet. > > The best way to do this is with a firewall (companies doing this probably > already have one, otherwise their "private" network ain't so private), and > just about every firewall worth putting on a box will do NAT. You map > individual machines that need their own IP address directly through on a > one-to-one relationship, and the rest you let the firewall masquerade > through. Conserves "real" IP space. NAT wasn't a common reliable tool when these things were established. The first of these I remember getting involved in over 4 years ago. It is a little better today, but the good ones are very costly. You will fail to convince the vast majority of these companies to buy an overpriced super firewall that does highly scalable NAT reliably when their needs are met with a low priced router (e.g. Ascend Pipeline 50 to Cisco 25XX scale). Yes, if you were starting this kind of thing today, NAT would probably be the better way to go. But as well all know, business does not just go around spending money to revamp what is currently working fine. > >So it makes sense that every company connecting this way must obtain their > >own unique address space. > > No, it doesn't. You get to describe the model of how to make it work using technology that was available when it was set up, or describe the model of how to upgrade it to what is available today without spending any money. > >1. There is not enough space in RFC1918 to assign UNIQUE addresses to each > > company that interconnects with many other companies, that further > > interconnect with many others, and on and on. > > There's 16,000,000 addresses in 10/8... not to mention the rest of the > space. Seems like VERY poor space management if the people involved can't > fit in there. When you trace these interconnects around and include all the businesses that are connected to each other, although not entirely routeable to each other, the numbers become staggering. Now toss in the logistics of assignment and allocation strategies, and the politics of the larger companies demanding big pieces, you eat that 10/8 up in a heart beat. And further, that also makes 10/8 unavailable for actual internal uses for which RFC1918 was intended. And since many such companies already do have RFC1918 in use for the intended purposes, this isn't the space that can be just simply moved in to. I won't disagree that you speak of the ideal way to establish networking. But it does not happen that way when you figure in business processing, financing, budgets, and politics. We're in the real world and it's a dirty place. > >2. Even if there was enough space, there is no one doing any administration > > of such space to ensure that all such assignments are sufficiently unique > > to ensure that every company connecting to many others will never see > > two or more such companies using the space part of RFC1918 space. > > So the companies come together - once - and allocate space for each other. Dream on. You have to include _EVERY_ company that might ever do this. > If the companies have such a good relationship that they are allowing > people in behind their firewalls and such, then communication amongst them > shouldn't be a foreign concept. They don't all have relations to each other. Company A connects to company B and company C. B connects to D and E. C connects to E and F. D connects to E and G and H. F connects to H and I. Of course company I and company A could use the same block of address space. ....until company A decides they now need to connect to company I. Decide on a strategy that takes this all into account. The only such strategy is for EVERY company that might ever connect to have an address that is totally unique from every other company. That definitely means an allocation agency is required. But why duplicate that when one already exists (which is now ARIN with "agents" being various ISPs that suballocate space). RFC1918 is NOT intended to be a universally assigned unique address space. > >Likewise, name spaces also have to be unique, and the NS servers that are > >authority for them may not be reachable by you or perhaps even anyone else > >on the open Internet. But that doesn't mean they aren't real and being > >used by many different businesses. > > This is an interesting concept... perhaps there ought to be an RFC1918-like > TLD "prv" or something, which is reserved for resolving addesses that will > only ever sit on RFC1918 space. Set aside certain addresses in RFC1918 > space that the root servers could ostensibly "point" to as being the > "official" nameservers for that TLD, ... Actually, I have used "localhost" as a TLD, as well as "priv". But someone still has to make sure name spaces do not collide over the realm of all businesses that interconnect. InterNIC is currently performing that role whether they know it or not. It's (combined with national TLDs and their registries/ars) the only functioning facility. And most companies do decide that if they are going to pick a name to use in these private backbones, they might as well just get one that is going to be the same on the real open Internet. It makes sense even more so today because most businesses that don't have a web site now are sure they will get one eventually. And the network engineers they contract know this even more so. The only issue is whether they make that name be served on the real open Internet NOW or put it off until the finally get the budget to do the web site (which for many companies won't be until Y2K is past). If some domain you don't have any need to contact has a lame delegation from the root, or simply no known host "www", what's it to you? You can't see a non-existant web site and you can't ping their network, so what does it matter? Why are you even doing what would discover the lame delegation, anyway? I guess that people are just so fed up with speculators who typically do not establish DNS service that they are taking it out on legitimate businesses who register their real names but just don't choose to have the DNS on the open Internet at this time. Fortunately for my customers, we include such DNS services for free with any web site or LAN connection. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --

1 0

Re: NSI does it again
by Patrick Greenwell 20 Jan '99

20 Jan '99

On Wed, 20 Jan 1999, Deepak Jain wrote: > > But how do you rule out an NSI on-hold from an NSI/root name server > screw-up like we had a few months back? > > Start querying _every_ root name server to see if the data is in the > current com.zone? That is about the sum of it, yes. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com (tinc) \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1 0

Re: Incompetance abounds at the InterNIC
by Adam D. McKenna 20 Jan '99

20 Jan '99

From: Phil Howard <phil(a)whistler.intur.net> :John Fraizer wrote: : :> 1) You should have domain servers for ANY domain you register that live in :> NON-RFC1918 space. Otherwise, Why register the domain at all? If it's for :> use behind the firewall, why not use internic.net or whitehouse.gov? You :> say "Because they want to receive email at the domain!" Well, to receive :> email, the rest of the world has to be able to find the mx records and to :> do that, your domain servers have to live in NON-RFC space and we have now :> completely and totally blown your first point out of the water and made it, :> in your own words, "moot." : :You have totally missed the concept that businesses can connect to other :businesses which connect other businesses and so on, and conduct network :protocols using the TCP/IP suite, just as if it were an Internet, but in :fact is highly isolated and segmented. Any ONE company in it may only be :able to reach those companies they connected directly to, but the other :companies reach many more companies. : :Using RFC1918 space for this won't work because there has to be some kind :of administration of the space to ensure enough uniqueness that no two :companies that are visible to any one company have the same addressing. :There can be only one such administration of any practicality even though :this "closed Internet" is chopped into isolated segments. : :Further, many companies with these networks also allow direct access to :the real open Internet. That means for sure that addresses in use on the :open Internet cannot be duplicated anywhere else. So the allocation of :space within the closed network has to be unique even compared to the :open Internet. : :So it makes sense that every company connecting this way must obtain their :own unique address space. His original argument was that you should have domain servers available for domains registered through internic. You seem to be arguing an entirely different point. If a domain is to be used exclusively behind a firewall, with no outside connectivity, then you should use a reserved TLD (I know there are a few, I don't know what they are though.) All of your other points can be taken care of with Network Address Translation, which is trivial to implement. --Adam

1 0

RE: NSI does it again
by Chris Mauritz 20 Jan '99

20 Jan '99

You mean NSI engages in poor judgement? Nahhhhh....not more than once a week... C -----Original Message----- From: Patrick Greenwell To: Harold Willison Cc: nanog(a)merit.edu Sent: 1/19/99 5:50 PM Subject: Re: NSI does it again On Tue, 19 Jan 1999, Harold Willison wrote: > hmm.. does this mean you can no longer do a search on the words ON HOLD? Yes. > This is probably just a way to shoo away the speculators. I imagine so. However doing so without communicating with anyone about it is an exercise in poor judgement IMO. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ /\/\/\ Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com (tinc) \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\/\/

1 0

RE: Incompetance abounds at the InterNIC
by Chris Mauritz 20 Jan '99

20 Jan '99

-----Original Message----- From: Phil Howard To: jmbrown(a)ihighway.net Cc: emarshal(a)logic.net; dts(a)senie.com; John.Fraizer(a)EnterZone.Net; nanog(a)merit.edu Sent: 1/19/99 5:34 PM Subject: Re: Incompetance abounds at the InterNIC John M. Brown wrote: >> My only problem with Pay Up Front is that some customers are going >> to be dead beat about paying us. I would want to make sure that >That's your problem. You choose your business model and I'll choose >mine. Agreed. If you have to pay for domains up front, then your customer will have to pay up front. What a concept, eh? Chris

1 0

Re: MCI/CW Security
by Dan Bustillos - Datalink Internet 20 Jan '99

20 Jan '99

I haveworked with this web page in the past. If you mark that it is currently happening. Security ios paged and I had a call back with in 5 min. Just my 2 Cents! Thank you, Dan Bustillos Technical Support Leader Datalink Internet (530) 897-6400 (888) 328-4638 ******************* "Error, No Keyboard - Press F1 to continue" Only on a PC would you see this error. Never on my mac.

4 3

Re: Incompetance abounds at the InterNIC
by sthaug＠nethelp.no 20 Jan '99

20 Jan '99

> > And most of the domains never have working name servers at all. The > > internic rules say you're supposed to have name service first. This > > isn't always practical, but if speculative domains don't have DNS within > > a few days, I'd think that'd be enough to wipe the allocations. > > So many people keep harping on the point of having name servers first. > But that's a silly and moot point. The name servers may well be behind > a firewall and the use of the domain name is intended for internal use > and needs to be registered externally for the same reason one should use > allocated address space from ARIN instead of picking random addresses. If you are behind a firewall, you can use RFC 1918 addresses. You don't need addresses from ARIN, and you don't need to pick at random. Relaxing the requirements for name servers seems like an excellent way of making the DNS even more broken than it already is. A number of TLDs (.no being one of them) will *enforce* a minimum of two functioning name servers for each domain. If you don't like this, you can of course take your business elsewhere. > This is like telling people they have to be routed on the Internet to be > able to get an address allocation. Sure. Why should they be allocated global addresses when RFC 1918 is available? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 2