dnwcv@dcatla.UUCP (William C. VerSteeg) (12/12/87)
I have bumped into a distressing situation dealing with getting a generic host to communicate with other host with different IP network numbers on the same network. Let's assume that the following scenario for demonstration purposes. Through the process of adding link-level (hardware) bridges, I have had the unenviable situation of having more than one internet network appear on what appears to be one ethernet cable. I want to telnet from my PC to a SUN. They have different IP network numbers. The PC will not generate a packet to this host in the absence of gateway information. The only way I can think of to make this work is to have the PC route to a gateway, which sends an ICMP redirect back to the PC. This leads me to my questions. What can be done to make the PC (or any other device for that matter) directly access differring IP networks that are directly connected to its local ethernet? This situation runs against "normal" IP addressing schemes. But does it violate any specific rules? Are there implementations that handle this situation gracefully? Bill VerSteeg
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (12/18/87)
If a gateway is present, it should be configured as such. If there is no gateway, I can either return an error to the user, or ARP the address on the other network anyway. If it is on another subnet which has suddenly become irrelevant, re-configure and unset the subnet bits. If I ARP it, maybe it is a spurious broadcast, maybe it works. If it works, various clever bits of code that treat things routed via a gateway differently break down, but the connection probably survives. To me, the tradeoffs have seemed to favor returning the error. If the user is in the what I think to be the mainstream, he has a configuration problem, and should know about it. Our code was recently reported (by a customer) to be willing to ARP any address configured as a gateway, although it won't ARP off-net addresses if no gateway is configured. I didn't design it, but it seems reasonable. Comments? James B. VanBokkelen FTP Software
dnwcv@dcatla.UUCP (William C. VerSteeg) (12/19/87)
The topic of discussion is how to tell a device that an IP network other than his own is on his local cable. This _is_ an atypical configuration, but one that can arise in the following situation. A user has two ethernet cables joined by a link level (hardware address) bridge. From each of these cables he has lots of IP traffic to the world at large. He would want an IP router for each cable. The network numbers should be different to limit traffic on the link level bridge. If the IP network numbers were the same, the world would be forced to guess which IP router to use, thus increasing load on the link level bridge. Assuming distinct IP network numbers, an IP speaking device on the first cable would then think that it had to go out the IP router to the world. Each packet would then rattle around the world, then go back in the second cable's router to gain access to a machine on the other cable. A more efficient, direct method would be to use the link level bridge. This could be done in two ways that I know of. 1- Each device (router or non-router) could be told of networks that co-reside with his own on a particular interface. Are there any implementations that do this? Does anybody have source code to a package that does this? 2- The router on each cable could know about multiple networks on a single interface. The router could then send ICMP redirects. These redirects should straighten the route. Proteon claims to support this. Sun, among others does not. Are there any other implementations that do this? Does anybody have source code to a package that does this? Thanks Bill VerSteeg
tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) (12/20/87)
I have a hard time believing that optimazation of non_local traffic through a bridge is a valid reason for going through the hassle of having two network numbers for what is otherwise a single network. If you have so much traffic that you need two gateways, then have two, but give them the same network number. If you really want to keep traffic from segment a on segment a and traffic from segment b on segment b, then put a gateway between the two Ethernet segments. What is the point between putting two different Internet networks on a single extended LAN? Is this commonly done? Is there a good reason that is not occuring to me? _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________
slevy@UMN-REI-UC.ARPA (Stuart Levy) (12/20/87)
The reason we do it is something like this, in my opinion ...
a) Some of us want IP-router like isolation, so we either get a bunch
of separate networks or we do subnetting. Being good Internet citizens
we're doing the latter.
b) Not all of us want to do subnetting (who needs a gateway for 3 machines).
c) Not all of us can do subnetting (some implementations still can't).
d) All subnetting implementations available to us demand that ALL
subnets on a net be of the same size.
e) We like to put separate groups in separate chunks of address space,
with the idea that they can choose to become a subnet later
without having to change all their IP addresses.
f) We have enough groups who might potentially become subnets that
we want to allow for a couple of hundred at least, and so chose
class-C subnetting on our class-B net.
g) The resulting subnets are too small to stuff all miscellaneous hosts
in just one of them, even if we wanted to. One or a few large
subnets plus a lot of small ones would be nice but we can't get it.
A hierarchy of subnets would be nice too, but we can't get that either,
at least not if we follow the normal rules.
Stuart Levy, slevy@uc.msc.umn.edu
Minn. Supercomputer Center & U. of Minnesotamartillo@ATHENA.MIT.EDU (12/20/87)
Wouldn't it be reasonable to have two network numbers if some machinese were relatively more secure and was encrypting the IP packets? It might be desirable to have a mail gateway between the somewhat more secure encrypted (logical) network and the unencrypted (logical) network. Yaqim Martillo
RAF@NIHCU.BITNET ("Roger Fajman") (12/21/87)
> What is the point between putting two different Internet networks > on a single extended LAN? Is this commonly done? Is there a good > reason that is not occuring to me? In the case of multiple subnets on one LAN with a class B address, a reason is that you have many small subnets and a few large ones. If you set your subnet mask to accomodate the size of the large subnets, then you may not have enough subnet numbers to accomodate the quantity of small subnets that you have. The reverse is also true. One possible solution is to have the subnet size be small, but assign multiple subnet numbers to the large LANs.
mckenzie@LABS-N.BBN.COM (Alex McKenzie) (12/21/87)
A (temporary) reason we had at BBN for having two IP nets on a single Ethernet was a restructuring of our campus network. We built one big Ethernet to replace several smaller ones. It was extremely convenient to be able to change which physical Ethernet a system was connected to asynchronously from changing what IP address that host was using. In fact, if I recall correctly, some hosts began using their new IP address before discontinuing use of their old IP address, as another way of maintaining uninterrupted service during the cutover. Alex McKenzie
mar@ATHENA.MIT.EDU (12/22/87)
But there is a simpler solution to the one you described, and it is even documented in RFC 1027. This is ARP subnet routing, or the ARP hack, as it is sometimes called. This means having your gateway respond to arp requests for machines on other subnets, giving it's own ethernet address. For instance, if you have a machine on subnet 1 of your class B network which does not understand subnet routing, and this machine wants to send a packet to a host on subnet 2, not knowing about subnets it would assume that it can send directly and arp for the destination host's IP address. The gateway on subnet 1 receives this ARP, and responds with it's own hardware address so that the packet gets sent to the gateway, which can forward it to the correct destination. So the ARP hack works in the case of smart gateways and dumb hosts. Proteon gateways support this, and I think Cisco ones do too. There are mods available for the 4.2 kernel, and it is already in 4.3, if you enable it. -Mark
slevy@UMN-REI-UC.ARPA (Stuart Levy) (12/22/87)
We're already doing subnet (proxy) ARP -- not exactly with our gateways, which don't have this feature built in (they're things like SUNs) but using a program employing the SUN `nit' ethernet-tap interface to listen for ARPs and respond from a table, giving the Ethernet address of the gateway, just as you suggest. This works fine for really dumb hosts that aren't using subnetting, and gives us "transparent" subnets. The case where it -doesn't- work is for hosts that -are- using subnetting, e.g. for the subnet gateways themselves. Say we want to give a default route (to 128.101.1.3) to one of them on a subnet other than 128.101.1.*. The UNIX routing software won't permit this -- it demands that gateways be on the same (sub)net as some interface address. So we synthesize these fake gateways (actually by building them into the same table that handles subnet ARPs) so that every subnet has a fake gateway within reach.
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (12/22/87)
Ok. There are a number of situations where this configuration (more than one net or subnet on a single broadcast medium) seems to bring some benefit. However, it goes against a fairly fundamental paradigm of RFC 791 and RFC 950, the use of the network (and subnet) mask to make a simple routing decision. My present code, and its installation, configuration, debugging & documentation all benefit from this. I assume that if you're going to break the paradigm, you want to go whole hog and have different classes of networks, and different numbers of subnet bits, all on the same cable? So the configuration would have to look like: mask 255.255.224.0 net 128.4.32.0 local ; class B, 3 subnet bits mask 255.255.0.0 net 18.10.0.0 local ; Class A, 8 subnet bits mask 255.255.255.0 net 192.9.1.0 local ; Class C, 0 subnet bits Three nets wouldn't be enough - I'd better design for 8, or 16. The list gets scanned for every miss on the ARP cache. Not too expensive. However, the configuration would have to be set, correctly, on every host on the net. Is it still safe to assume that everything which is not on the list should go through a default gateway, or do workstations need explicit routes there, too? We can write the code, we can document it, we can probably even explain it to the non-guru (to whom setting up an IP network is already a major adventure). Right now, I don't think it is justified. Maybe once automatic, central configuration initialization & control is available, maybe once the Unix manufacturers all get into agreement about the nature of broadcast packets, maybe once IP Multicast is generally understood, and implementations are beginning to show up (in DC, Postel warned that this was something vendors should keep their eyes on). It looks like a low priority to me. Are there people with money to spend that say otherwise? jbvb
tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) (12/23/87)
Maybe I am about to say something that is obvious and that everybody already knows, but here goes............ The purpose of subnetting (as I understand it) is to allow gateways and separated (sub)networks to exist in what appears to be a single network outside, therefore making routing decisions outside of the network to not be concerned with is going on inside the network. This does not, however, mean that one can change the topology inside their network without expecting some IP addresses to change, just as one would not expect to move their host from MITRE to SRI with getting a new IP address. The problem is that the name-domain function apparently does not allow other hosts to dynamically rediscover that some host has a new IP address. I don't know is this is an implementation problem or a design problem, although I assume the former. If I might indulge in a little self-promotion, the algorithms I have been working on, which are collectively called Landmark Routing, cause gateways to self-configure automatically, assign addresses to gateways, and bind host "names" to those addresses in an efficient and dynamic fashion (at least they do if my design is correct. We have no implementation to date, although we are now embarking on simulation). What this means is that hosts are assign permanent IP addresses that NEVER change even if the host moves, and that the Landmark Routing function automatically handles all (landmark) address assignments. Then assignment of IP addresses is then purely an administrative consideration, and not a topological one. If this is of interest to folks, please let me know so that I can focus my work appropriately and work towards a testbed. I plan some RFCs on this topic later in 1988. _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (12/23/87)
One point I hadn't made in the earlier messages is that I am looking at the issue from the standpoint of a single-user PC workstation. We don't presently support more than one interface, and so we aren't blessed with all the configuration issues (and problems) that a multi-homed host has from the beginning. Support for multiple networks on one cable (however primitive) seems to be associated with multi-homedness, and I think I see why. If I wind up doing it, my routing code gets elaborate, but the primitive O/S prevents me from taking much advantage of it. Hi ho. jbvb