dpowles@CCD.BBN.COM ("Drew M. Powles") (05/19/88)
Has any thought been given to the mechanisms and methodologies to be used for interconnecting separate Internets with overlapping address spaces? Granted, there's only one Internet at the moment, and we be it, but there may come a time where more than one Internet springs up along side of the existing Internet, even in the DoD, with completely separate administration mechanisms, including address assignment (although still based on the internetworking protocols of choice at the time, whether that's DoD IP, or ISO IP down the road). And these side-by-side Internets may have some interoperability requirements. Can interoperability be successfully implemented at an Internet (or read Level 3) position in the protocol stack, or do we have to resort to some application level funniness? I know this may seem to be a silly or somewhat naive question, but there are actual situations where this could eventually arise. Any thoughts? many thanks, dmp dpowles@bbn.com Drew M. Powles BBN Communications 9810 Patuxent Woods Drive Columbia, MD 21046
rcallon@GOVERNMENT-CENTER.BBN.COM (Ross Callon) (05/21/88)
Drew; I think the answer is a qualified yes. There are several "sub-issues" however. In a sense the issues involved in interconnecting multiple existing "Internets" are the same as those in having the Internet grow to encompass a large number of administrative domains, except for the added problem of address overlap (which is probably NOT the worst problem). In terms of address overlap, the solution depends upon whether you use the DoD IP or the ISO IP. With the DoD IP, I am not aware of any work on how to map between two overlapping inconsistent address sets. The obvious choice would be to more or less hand-configure some sort of translation, and have big tables in the gateways on the boundary. Exactly how this is done may depend on whether you run out of network numbers for any particular class of network address. For example, if a class A address on one side maps to a class B address on the other, then the host part of the address would also have to change. All of this seems potentially ugly. The ISO protocol, on the other hand, comes complete with globally unique addresses. For example, consider the proposed ways in which addressing could be done with the ISO IP in the DoD Internet (see RFC986, IDEA003, and a revision of both which is about to come out as a new RFC). Here the first three octets of the address specify "DoD Internet", and addresses are globally unique even with respect to Internets in some other part of the world. Another potentially more serious question regards how to route in a future world of multiple "Internets" (or a multi-domain Internet). It can be assumed that most of the administrative domains in the world will have strict restrictions on what sort of traffic they are willing to carry for what users. For example, a particular domain may be willing to carry any traffic which is strictly internal, traffic between this domain and neighbors only for specific users and/or applications, and transit traffic only for a small number of outside domains and specified applications. The domain may be very willing to carry electronic mail traffic for their main competitor, because they want to make copies for themselves (the main competitor may, for the same reason, be unwilling to use this service). One can easily envision all sorts of other "policy constraints" affecting routing. Thus routing will need to look at all sorts of administrative and policy considerations. The IETF Open Routing working group is currently thinking about how one may do this. IDEA003 represents a first draft of the requirements for inter-AS (or Inter-domain) routing, but is only in draft form (there is a list of proposed updates to be made in the future). We are currently working on several proposals for how to actually do routing in this environment. The Autonomous Networks Task Force is also working on related issues. There are other issues that are likely to come up when multiple "Internets" are interconnected. For example, there may be a need for congestion control to be sensitive to administrative policies and contractural arrangements. Ross
donegan@stanton.TCC.COM (Steven P. Donegan) (05/22/88)
I hope this isn't a hopelessly stupid question but: In the network I am attempting to build at my employer's site(s) we have a class B primary address 129.253.x.x and many workstations from many diverse vendors. The network backbone spans many buildings and countries via MAC level bridges. Most of the TCP/IP devices (our network is primarily XNS and DECNET) are of the SUN persuasion, one server with both MAU and thinwire interfaces, the thinwire running to 5 or 6 workstations and the MAU connecting to the backbone. The problem I have run into on a continuous basis is the situation where, even though the packets are capable of being seen by all parties, a host rejects a connection because (I think) the destination/source pair are in a different 'subnet' ie 129.253.001.x and 129.253.002.x. Is there any way under legal TCP/IP to get these blasted devices to talk to each other without buying a hardware device such as a gateway or router? I feel that the 'feature' of subnetting in my particular network is really a major LIMITATION! I have NONE of these types of problems with my XNS or DECNET devices. Help. Please, no flames for stupidity, I've been networking systems for a living for quite a while and am really interested in learning about this subject. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
chuck@excelan.UUCP (Chuck Kollars) (05/25/88)
In <44@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: > ... The problem I have run into on a continuous basis is the situation >where, even though the packets are capable of being seen by all parties, >a host rejects a connection because (I think) the destination/source >pair are in a different 'subnet' ... Is there any way under legal TCP/IP >to get these blasted devices to talk to each other without buying a >hardware device such as a gateway or router? ... If I understand your configuration correctly, you have one Class B network running on one (very large MAC-bridged) cable, with no need of subnetworking. Yet some of your nodes act like they have subnetworking enabled. Just disable subnetworking on all your nodes. Find the "address mask" or "subnetwork mask" or other such configuration value on each node, and be sure it's set to the value that means 'no subnetworking' (probably all zeros). [ex: ifconfig ie0 netmask 0] Or, maybe you are intentionally using subnetworking and have some subnetwork routers in your configuration. But sometimes two different subnetworks in fact ride on the same cable. In which case your question is how to have two IP networks on one cable. For BSD and most BSD-derived implementations, the answer is to add a route entry for the "other" subnetwork with a metric of 0 hops. Do this to every node. The metric value 0 hops is interpreted to mean 'on the same cable'. [ex: route add 129.253.2.0 129.253.0.99 0] (Of course, the purist rule is "ONE IP (sub)network <-> ONE cable". So convince yourself that you don't have an address administration problem before you start hacking.) -- Chuck Kollars, Excelan, Inc. mtxinu!excelan!chuck@ucbvax.Berkeley.COM (chuck@excelan.UUCP) ...!{mtxinu,leadsv,cae780}!excelan!chuck