On Sat, Jan 16, 1999 at 03:22:23PM -0500, Jay R. Ashworth wrote:

On Sat, Jan 16, 1999 at 12:29:12PM -0500, Steven J. Sobol wrote:

...

If you're feeling... what was the word someone else used, "masochistic..." also complain to David Holtzman (dholtzman@internic.net) so that he can yell at you and tell you you're full of shit.

I'm not by any means an Internic apologist, but I must stand up for dholtz. Every time I've had occasion to deal with him, usually when things were rotten, he's been quite polite to _me_.

I've heard from him once, and he was ranting the one time I heard from him. There have been various good and bad things said about Chuck Gomes, but at least he listens and provides feedback. Of course, Chuck's position (Director of Customer Programs, or some such, don't remember the exact title) is one where he is expected to provide good customer service. David's position is not necessarily one where he is expected to be in contact with customers at all times. But ferchrissakes, if you're going to talk to customers, you might at least *try* to be polite. -- Steve Sobol [sjsobol@nacs.net] Part-time Support Droid [support@nacs.net] NACS Spaminator [abuse@nacs.net] Proud resident of Cleveland Heights, Ohio, the coolest place on earth. http://www.ClevelandHeights.com

Phil Howard wrote:

John Fraizer wrote:

...

Just what does our $35/yr per domain go towards? I would venture to guess that drive space costs a whole shit load less that all the damned InterNIC commercials I've been seeing on T.V.!

What $35? Domains are FREE! ... at least for 30 days.

...

Does anyone know just who we need to bitch very loudly to?

The domain speculators who flood InterNIC with massive numbers of domains they don't intend to pay for, and then flood again with repeated templates to re-register the same domain all over again hoping to catch it right when it gets deleted for non-payment (under a new ficticious name, of course).

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. Actually, at this point I'd be happy to supply a credit card or a funded InterNIC account number along with applications. Money up front may well be the only way to clobber speculators. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

Daniel Senie wrote:

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. This is like telling people they have to be routed on the Internet to be able to get an address allocation.

Actually, at this point I'd be happy to supply a credit card or a funded InterNIC account number along with applications. Money up front may well be the only way to clobber speculators.

This is a more reasonable way to begin to block those speculators that are ripping off the system. There are a number of variations I am sure InterNIC could do. Among them would be to expedite new domain requests if the credit card payment, or established account authenticity, has been included with the request. Other ideas include limiting the number of outstanding requests per contact. If you have more than N unpaid domains, you can't regiater any more on that contact until you either pay up on some or delete some. Another idea I have for InterNIC would be that when a domain is released for non-payment, put it on "lockout" (just seeking a new term here) for a random period of time. If during the lockout period, a new request for it comes in, reject the request and extend the lockout for a new random amount of time. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at 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.

2) DNS servers that are behind a firewall are useless in the context you describe above.

Not true. The DNS servers exist and are used by many of these companies. Only those companies that need to use them can reach them.

3) You should NEVER pick random addresses. Please refer to RFC1918.

Agreed. And this does not happen (it once did, but some of the larger companies that many of the other companies connect to laid down the rules that said all addresses must be unique).

4) If you don't intend to be routed on the global internet, you SHOULD be required to use RFC1918 space. NOBODY should be allocate routable address space for internal, off-net use.

This is neither practical nor possible. wave your hands all you want, but it won't happen because RFC1918 space cannot ever hope to allow every one of these companies to have address space that they can communicate with each other uniquely, entirely within the RFC1918 space. There are two reasons for this and based on mail I've received from a few people, it is clear to me that a lot of people need these spelled out. 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. 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. It seems many people still have their heads stuck in ivory towers and lack the concepts of the real world. I once did, so I know it happens. Think of these "closed Internets" as businesses conducting business with each other over the Internet, but then deciding to get guaranteed bandwidth by directly connecting to each peer, not routing to the real open Internet, and basically becoming isolated except for the fact that in many of these companies their computers (servers and desktops) can not only reach many other companies this way, but also the real open Internet. Addresses must be unique unless they are entirely internal (links themselves often can be, too, but this does get messy sometimes) within one company, which is not the bulk of what this is. 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.

...

been included with the request. Other ideas include limiting the number of outstanding requests per contact. If you have more than N unpaid domains, you can't regiater any more on that contact until you either pay up on some or delete some.

This would be a moot effort. What is going to stop the speculators from just generating random email addresses for admin, techincal and contact addresses. It is very simple to route *@domain.com to a single email box.

They probably can and probably will do this. It's not an ultimate solution but it migh quiet things down for a little while until a better solution can finally be agreed on. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --

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 * --

:: Derek Balling writes ::

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.

In 1994, my employer has WAN connections to one external company. We now have about 17 such connections. Most of the 17 companies are engaged in some form of work for my employer. All 17 had networks prior to the time the sold, or even attempted to sell, their services to my employer. So, they all designed their networks completely unaware of each other, but it is now all essential that all 17 have IP unqiue IP addresses, because they all connect to my employer, and I can't route the same IP address to two places. Most of these 17 companies, even today, are unaware of the existance of the other 16. Furthermore, many these 17 companies all have WAN links to some of their other customers. And those other customers have WAN links. And so on. In fact, it would be interesting to see what percentage of U S industry is reachable from my employer without traversing any portion of the public internet -- I would guess it's rather large. (Hypothetically speaking -- obviously, none of these 17 companies are providing any form of transit for my employer, and my employer is providing no transit for them -- I'm just guessing that by following private WAN links and assuming complete transit, I could get damn near anywhere in the country, and probably a lot of places overseas. The point being that you end up needing to coordinate usage of 10.X.X.X over just about the whole world.) Just as an example, do you use any RC1918 space internally? Are you sure that you will never need to connect to my employer? If not, are you sure that your RFC1918 addresses don't conflict with mine? (I use RFC1918, but only for strictly internal stuff. Not for anything that anybody external to my employer will ever need to contact, even via private WAN links).

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.

Would you like a list of protocols that I need to support that don't NAT? :) How are you going to deal with the fact that this would effectively make servers (not just clients) appear as different IP addresses depending on where the client is located? Are you suggesting that I should run 17 different DNS's. Or provide hacked zone files to everyone I connect to, and load the hacked zone files they provide me on my DNS?

...

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.

OK. Let's say you need to implement some 10/8 space tomorrow. How do you plan to coordinate with everyone you will ever connect with?

So the companies come together - once - and allocate space for each other. 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.

I allow no one behind my firewall. But I won't NAT. (Some stuff I need to run doesn't NAT, although I probably wouldn't NAT even if it did). And I won't run hacked zone files. And I won't run separate DNS's for everyone who wants to connect to me. But even if I did allow other companies with whom my employer has a good relationship in behind my firewall, I cannot predict today every company that my employer would ever have a good relationship with.

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, ...

Hmm. An excellent idea. It wouldn't even necessarily have to just be for 1918 space. Just some name space that is guaranteed to never become a tld in the public internet. - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com

Yeah, this spawned a whole long thread (on going ... still) on domain policy. As long as you can get free domains, at least temporarily, this will continue to be problem. FWIW, InterNIC has changed whois output and dropped two key fields, "initial creation date" and "current status". That got a lot of gripes too. The real solution is one they don't want to do for some unfathomable reason, pre-payment or online payment for domain names. At 08:49 PM 1/18/99 -0600, Phil Howard wrote:

John Fraizer wrote:

...

Just what does our $35/yr per domain go towards? I would venture to guess that drive space costs a whole shit load less that all the damned InterNIC commercials I've been seeing on T.V.!

What $35? Domains are FREE! ... at least for 30 days.

...

Does anyone know just who we need to bitch very loudly to?

The domain speculators who flood InterNIC with massive numbers of domains they don't intend to pay for, and then flood again with repeated templates to re-register the same domain all over again hoping to catch it right when it gets deleted for non-payment (under a new ficticious name, of course).

___________________________________________________ Roeland M.J. Meyer - e-mail: mailto:rmeyer@mhsc.com Internet phone: hawk.lvrmr.mhsc.com Personal web pages: http://staff.mhsc.com/~rmeyer Company web-site: http://www.mhsc.com ___________________________________________________ KISS ... gotta love it!