From ncc at ripe.net Wed Mar 9 11:24:19 1994 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 09 Mar 1994 11:24:19 +0100 Subject: Network numbers allocated through HP In-Reply-To: Your message of Mon, 07 Mar 1994 11:10:09 MET. <199403071010.LAA29284@foobar.Germany.EU.net> Message-ID: <9403091024.AA04078@reif.ripe.net> This is of interest to all local registires: Andreas Schachtner writes: * Hello, * * recently, an increasing number of customer approach us to route * class B and C networks, where I can't find any entries in the NIC * or RIPE databases. * * Most of the customers claim, the addresses had been allocated by * Hewlett Packard. * * I assume there has been a block delegation of networks to HP by the * DDN NIC in the past, but this didn't make it into the databases. Correct. These are becoming visible in the Internic RS database now: Hewlett-Packard Company (NETBLK-HP9B) 19420 Homestead Road Cupertino, CA 95014 Netname: HP9B Netblock: 192.53.104.0 - 192.53.255.0 Coordinator: Ilnicki, Slawomir (SI8) [No mailbox] (408) 447-2797 Record last updated on 09-Jul-92. But somehow doesn't make it into the exchange. HP's administration as to whom they assigned these numbers to is on paper only. We have requested a copy and expect to receive it in the next few days. Han in there. * I wonder if only EUnet Germany is hit by this or if other Internet * service provider encounter similiar problems. This is a common problem. * If this is a more * common problem, maybe it's a good idea, if the RIPE NCC tries to track * this down ? The RIPE NCC is doing so. Hang in there for a few days for the snail mail from the US to arrive. If you have any further questions, please fo not hesitate to ask. Daniel Karrenberg NCC Duty Staff of the Day From ncc at ripe.net Thu Mar 10 14:11:21 1994 From: ncc at ripe.net (RIPE NCC Staff) Date: Thu, 10 Mar 1994 14:11:21 +0100 Subject: Network numbers allocated through HP In-Reply-To: Your message of Mon, 07 Mar 1994 11:10:09 MET. <199403071010.LAA29284@foobar.Germany.EU.net> Message-ID: <9403101311.AA08714@reif.ripe.net> The NCC has the listof HP assigned networks now, on hardcopy. If you encounter customers with such networks we can from now on check for you. If you have any further questions, please fo not hesitate to ask. Daniel Karrenberg NCC Duty Staff of the Day From woeber at cc.univie.ac.at Thu Mar 10 16:47:43 1994 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 10 Mar 1994 16:47:43 +0100 Subject: Network numbers allocated through HP Message-ID: <0097B3BD.A886B3A0.26283@cc.univie.ac.at> >The NCC has the listof HP assigned networks now, on hardcopy. >If you encounter customers with such networks we can from now on check for >you. > >If you have any further questions, please fo not hesitate to ask. > >Daniel Karrenberg >NCC Duty Staff of the Day Any plans to add this block or the individual networks to the database? -Wilfried. From Daniel.Karrenberg at ripe.net Thu Mar 10 16:54:00 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 10 Mar 1994 16:54:00 +0100 Subject: Network numbers allocated through HP In-Reply-To: Your message of Thu, 10 Mar 1994 16:47:43 MET. <0097B3BD.A886B3A0.26283@cc.univie.ac.at> Message-ID: <9403101554.AA09157@reif.ripe.net> > "Wilfried Woeber, UniVie/ACOnet" writes: > > Any plans to add this block or the individual networks to the database? This is really for the InterNIC to do. It is 67 A4s with small print. We will try to scan them and make the file available. Daniel From Daniel.Karrenberg at ripe.net Mon Mar 14 15:19:02 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 14 Mar 1994 15:19:02 +0100 Subject: Private Address Space RFC Message-ID: <9403141419.AA12242@reif.ripe.net> Folks, it took a little longer again! Hre is what we sent to Jon as a DRAFT on Friday. Please note that the actual addresses can still change although this is unlinkely. Please do not spread this too widely before it is published. Daniel Network Working Group Yakov Rekhter Request for Comments: XXXX T.J. Watson Research Center, IBM Corp. Category: Informational Bob Moskowitz Chrysler Corp. Daniel Karrenberg RIPE NCC Geert Jan de Groot RIPE NCC March 1994 Address Allocation for Private Internets 1. Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. [XXJon: Here we need some language acceptable to you that makes clear that the address space assignment part is indeed official] 2. Introduction This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. The authors hope, that using these methods, significant savings can be made on allocating IP address space. For the purposes of this memo, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network. 3. Motivation With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The current practice is to assign globally unique addresses to all hosts that use TCP/IP. There is a growing concern that the finite IP Rekhter, Moskowitz, Karrenberg, de Groot [Page 1] RFC XXXX Address Allocation for Private Internets March 1994 address space might become exhausted. Therefore, the guidelines for assigning IP address space have been tightened in recent years [1]. These rules are often more conservative than enterprises would like, in order to implement and operate their networks. Hosts within enterprises that use IP can be partitioned into three categories: - hosts that do not require access to hosts in other enterprises or the Internet at large; - hosts that need access to a limited set of outside services (e.g. E-mail, FTP, netnews, remote login) which can be handled by application layer gateways; - hosts that need network layer access outside the enterprise (provided via IP connectivity); Hosts within the first category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. For many hosts in the second category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Only hosts in the last category require IP addresses that are globally unambiguous. Many applications require connectivity only within one enterprise and do not even need external connectivity for the majority of internal hosts. In larger enterprises it is often easy to identify a substantial number of hosts using TCP/IP that do not need network layer connectivity outside the enterprise. Some examples, where external connectivity might not be required, are: - A large airport which has its arrival/departure displays individually addressable via TCP/IP. It is very unlikely that these displays need to be directly accessible from other networks. - Large organisations like banks and retail chains are switching to TCP/IP for their internal communication. Large numbers of local workstations like cash registers, money machines, and Rekhter, Moskowitz, Karrenberg, de Groot [Page 2] RFC XXXX Address Allocation for Private Internets March 1994 equipment at clerical positions rarely need to have such connectivity. - For security reasons, many enterprises use application layer gateways (e.g. firewalls) to connect their internal network to the Internet. The internal network usually does not have direct access to the Internet, thus only one or more firewall hosts are visible from the Internet. In this case, the internal network can use non-unique IP numbers. - If two enterprises communicate over their own private link, usually only a very limited set of hosts is mutually reachable from the other enterprise over this link. Only those hosts need globally unique IP numbers. - Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise. 4. Private Address Space IANA has reserved the following two blocks of the IP address space for private networks: 10.0.0.0 - 10.255.255.255 192.168.0.0 - 192.168.255.255 We will refer to the first block as "24-bit block", and to the second as "16-bit" block. Note that the first block is nothing but a single class A network number, while the second block is a set of 255 contiguous class C network numbers. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise. As before any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the reservation above. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future. Such hosts will be called private hosts, and will use the private address space defined Rekhter, Moskowitz, Karrenberg, de Groot [Page 3] RFC XXXX Address Allocation for Private Internets March 1994 above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any external host. While not having external network layer connectivity private hosts can still have access to external services via application layer relays. All other hosts will be called public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to external public hosts. Public hosts do not have connectivity to private hosts of other enterprises. Moving a host from private to public or vice versa involves a change of IP address. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. 5. Advantages of Using Private Address Space The obvious advantage of using private address space for the Internet at large is to conserve the globally unique address space by not using it where global uniqueness is not required. Enterprises themselves also enjoy a number of benefits from their usage of private address space: They gain a lot of flexibility in network design by having more address space at their disposal than they could obtain from the globally unique pool. This enables operationally and administratively convenient addressing schemes as well as easier growth paths. For a variety of reasons the Internet has already encountered situations where an enterprise that has not between connected to the Internet had used IP address space for its hosts without getting this space assigned from the IANA. In some cases this address space had Rekhter, Moskowitz, Karrenberg, de Groot [Page 4] RFC XXXX Address Allocation for Private Internets March 1994 been already assigned to other enterprises. When such an enterprise later connects to the Internet, it could potentially create very serious problems, as IP routing cannot provide correct operations in presence of ambiguous addressing. Using private address space provides a safe choice for such enterprises, avoiding clashes once outside connectivity is needed. One could argue that the potential need for renumbering represents a significant drawback of using the addresses out of the block allocated for private internets. However, we need to observe that the need is only "potential", since many hosts may never move into the third category, and an enterprise may never decide to interconnect (at IP level) with another enterprise. But even if renumbering has to happen, we have to observe that with Classless Inter-Domain Routing (CIDR) an enterprise that is connected to the Internet may be encouraged to renumber its public hosts, as it changes its Network Service Providers. Thus renumbering is likely to happen more often in the future, regardless of whether an enterprise does or does not use the addresses out of the block allocated for private networks. Tools to facilitate renumbering (e.g. DHCP) would certainly make it less of a concern. Also observe that the clear division of public and private hosts and the resulting need to renumber makes uncontrolled outside connectivity more difficult, so to some extend the need to renumber could be viewed as an advantage. 6. Operational Considerations A recommended strategy is to design the private part of the network first and use private address space for all internal links. Then plan public subnets at the locations needed and design the external connectivity. This design is not fixed permanently. If a number of hosts require to change status later this can be accomplished by renumbering only the hosts involved and installing another physical subnet if required. If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit class C block, which consists of 255 contiguous class C network numbers, can be used. Using multiple IP (sub)nets on the same physical medium has many pitfalls. We recommend to avoid it unless the operational problems Rekhter, Moskowitz, Karrenberg, de Groot [Page 5] RFC XXXX Address Allocation for Private Internets March 1994 are well understood and it is proven that all equipment supports this properly. Moving a single host between private and public status will involve a change of address and in most cases physical connectivity. In locations where such changes can be foreseen (machine rooms etc.) it may be advisable to configure separate physical media for public and private subnets to facilitate such changes. Changing the status of all hosts on a whole (sub)network can be done easily and without disruption for the enterprise network as a whole. Consequently it is advisable to group hosts whose connectivity needs might undergo similar changes in the future on their own subnets. It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from *inbound* routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. Groups of organisations which foresee a big need for mutual communication can consider forming an enterprise by designing a global addressing plan supported by the necessary organisational arrangements like a registry. If two sites of the same enterprise need to be connected using an external service provider, they can consider to use an IP tunnel to prevent packet leaks form the private network. A possible approach to avoid leaking of DNS RRs is to run two nameservers, one external server authoritative for all globally unique IP addresses of the enterprise and one internal nameserver authoritative for all IP addresses of the enterprise, both public and private. In order to ensure consistency both these servers should be configured from the same data of which the external nameserver only receives a filtered version. The resolvers on all internal hosts, both public and private, query only the internal nameserver. The external server resolves queries from resolvers outside the enterprise and is linked into the global DNS. The internal server forwards all queries for information outside the enterprise to the external nameserver, so all internal hosts can access the global DNS. This ensures that information about private hosts does not reach resolvers and nameservers outside the enterprise. Rekhter, Moskowitz, Karrenberg, de Groot [Page 6] RFC XXXX Address Allocation for Private Internets March 1994 7. References [1] E. Gerich, "Guidelines for Management of IP Address Space", RFC1466, Merit Network, Inc., May 1993. 8. Security Considerations While using private address space can improve security, it is not a substitute for dedicated security measures. 9. Conclusion With the described scheme many large enterprises will need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space which will effectively lengthen the lifetime of the IP address space. The enterprises benefit from the increased flexibility provided by a relatively large private address space. 10. Acknowledgments We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza Turchanyi (RIPE NCC) for their review and constructive comments. 11. Author's Addresses Yakov Rekhter T.J. Watson Research Center, IBM Corp. P.O. Box 218 Yorktown Heights, NY, 10598 Phone: +1 914 945 3896 Fax: +1 914 945 2141 Email: yakov at watson.ibm.com Rekhter, Moskowitz, Karrenberg, de Groot [Page 7] RFC XXXX Address Allocation for Private Internets March 1994 Robert G Moskowitz Chrysler Corporation CIMS: 424-73-00 25999 Lawrence Ave Center Line, MI 48015 Phone: +1 810 758 8212 Fax: +1 810 758 8173 Email: 3858921 at mcimail.com Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Email: Daniel.Karrenberg at ripe.net Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Email: GeertJan.deGroot at ripe.net Rekhter, Moskowitz, Karrenberg, de Groot [Page 8] From poole at eunet.ch Mon Mar 14 15:47:13 1994 From: poole at eunet.ch (poole at eunet.ch) Date: Mon, 14 Mar 1994 15:47:13 +0100 (MET) Subject: Private Address Space RFC In-Reply-To: <9403141419.AA12242@reif.ripe.net> from "Daniel Karrenberg" at Mar 14, 94 03:19:02 pm Message-ID: <199403141447.PAA19974@eunet.ch> > > Hre is what we sent to Jon as a DRAFT on Friday. > Please note that the actual addresses can still change although this is > unlinkely. Please do not spread this too widely before it is published. > What does "published" mean in this context? In any case, my greatest concern with this RFC is that it completly ignores the discussion of a common problem: acquistion and mergers of companies. This is -not- an uncommon occurence and the new scheme will nearly guarantee conflicts in such a case. Simon From Daniel.Karrenberg at ripe.net Mon Mar 14 15:59:39 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 14 Mar 1994 15:59:39 +0100 Subject: Private Address Space RFC In-Reply-To: Your message of Mon, 14 Mar 1994 15:47:13 MET. <199403141447.PAA19974@eunet.ch> Message-ID: <9403141459.AA12413@reif.ripe.net> > poole at eunet.ch writes: > > > > Hre is what we sent to Jon as a DRAFT on Friday. > > Please note that the actual addresses can still change although this is > > unlinkely. Please do not spread this too widely before it is published. > > > > What does "published" mean in this context? Published as an RFC. > In any case, my greatest concern with this RFC is that it completly > ignores the discussion of a common problem: acquistion and mergers > of companies. This is -not- an uncommon occurence and the new scheme > will nearly guarantee conflicts in such a case. I haven't heared about mergers of companies of any size yet where the internal networks of the merging companies were totally integrated immediately after the merger. Usually this process -if done at all- Involves considerable planning and re-engineering. Conflicts in this case are also not serious at the moment of the merger as the public parts of both networks can communicate before and after the merger. Daniel From GeertJan.deGroot at ripe.net Fri Mar 18 09:56:44 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 18 Mar 1994 09:56:44 +0100 Subject: Network-10 RFC is out! Message-ID: <9403180856.AA00642@belegen.ripe.net> At RIPE-17, there was some discussion on a proposal to use non-unique address space for places where global uniqueness isn't needed. Here is the annoncement of the resulting RFC1597. You might want to point people asking for large address space for internal networks to this document. Enjoy, Geert Jan -------------- next part -------------- An embedded message was scrubbed... From: "Joyce K. Reynolds" Subject: RFC1597 on Address Allocation for Private Internets Date: Thu, 17 Mar 94 13:06:58 PST Size: 3870 URL: From keith at pipex.net Tue Mar 22 14:06:06 1994 From: keith at pipex.net (Keith Mitchell) Date: Tue, 22 Mar 1994 13:06:06 +0000 Subject: Class C subnetting and Novell TCP/IP Message-ID: <199403221306.NAA21439@pipe.pipex.net> We've had a couple of registration requests recently, where a large number of Class Cs have been asked for for what is quite a small number of hosts, maybe 5-6 per Class C. Normally we would assign maybe 1 or 2 Class Cs in such a case, and suggest they subnet them. The justification offered for this is that the routing sotware for Novell servers and/or Novell Lan Workplace (their PC TCP/IP software) does not support subnetting of Class Cs. My initial reaction was disbelief that this sort of Dinosaur DNA is still so prevalent, but more than one offer of this sort of justification seems to suggest it is. So, the question is, what approach do we take. Do we make life easy for the applicants, and give them one Class C per subnet, or do we say no, this is a problem for the vendor, in order to put concerted pressure on Novell to do somehing about their "gas guzzlers" ? Suggestions welcome, Thanks, Keith Mitchell Network Manager Public IP Exchange keith at pipex.net 216 The Science Park keith at unipalm.co.uk Cambridge, UK Phone: +44 223-250120 Fax: +44 223-250121 PIPEX is part of the Unipalm Group From ih at chernikeeff.co.uk Tue Mar 22 14:56:01 1994 From: ih at chernikeeff.co.uk (Ian Harding) Date: Tue, 22 Mar 94 13:56:01 GMT Subject: Class C subnetting and Novell TCP/IP Message-ID: <9403221356.AA05520@chart.chernikeeff.co.uk> >The justification offered for this is that the routing sotware for >Novell servers and/or Novell Lan Workplace (their PC TCP/IP software) >does not support subnetting of Class Cs. My initial reaction was >disbelief that this sort of Dinosaur DNA is still so prevalent, but >more than one offer of this sort of justification seems to suggest >it is. Hmm, the Novell Netware Supervisor's Guide, Chapter 5 (Sample IP network configurations), Case 4, suggests subnetting is supported ... Ian. From Daniel.Karrenberg at ripe.net Tue Mar 22 15:17:48 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Mar 1994 15:17:48 +0100 Subject: Class C subnetting and Novell TCP/IP In-Reply-To: Your message of Tue, 22 Mar 1994 13:06:06 GMT. <199403221306.NAA21439@pipe.pipex.net> Message-ID: <9403221417.AA09706@reif.ripe.net> > keith at pipex.net (Keith Mitchell) writes: > > The justification offered for this is that the routing sotware for > Novell servers and/or Novell Lan Workplace (their PC TCP/IP software) > does not support subnetting of Class Cs. My initial reaction was > disbelief that this sort of Dinosaur DNA is still so prevalent, but > more than one offer of this sort of justification seems to suggest > it is. First of all we need to find out if this is really the case in the current software releases. My suspicion is that it is not. Then the case is closed. > So, the question is, what approach do we take. Do we make life easy > for the applicants, and give them one Class C per subnet, or do we > say no, this is a problem for the vendor, in order to put concerted > pressure on Novell to do somehing about their "gas guzzlers" ? Should this really be true we have a channel to Novell as they fund the NCC. Before generally accepting this as a good reason I would like to hear their response. Daniel From Ulf.Vedenbrant at mailbox.swip.net Tue Mar 22 15:32:41 1994 From: Ulf.Vedenbrant at mailbox.swip.net (Ulf Vedenbrant) Date: Tue, 22 Mar 94 15:32:41 +0100 Subject: Class C subnetting and Novell TCP/IP Message-ID: <199403221432.AA25734@mailbox.swip.net> >>The justification offered for this is that the routing sotware for >>Novell servers and/or Novell Lan Workplace (their PC TCP/IP software) >>does not support subnetting of Class Cs. My initial reaction was >>disbelief that this sort of Dinosaur DNA is still so prevalent, but >>more than one offer of this sort of justification seems to suggest >>it is. > >Hmm, the Novell Netware Supervisor's Guide, Chapter 5 (Sample IP network >configurations), Case 4, suggests subnetting is supported ... SWIPnet has a few customers that runs with Novell & subnetted class C's. As long as you don't try to use the first and last subnets it seems do work fine. They did the configuration whitout any special knowledge about Novell... They just read the manual first....;-) -- Uffe -- From bob at informatics.rutherford.ac.uk Tue Mar 22 14:51:10 1994 From: bob at informatics.rutherford.ac.uk (bob at informatics.rutherford.ac.uk) Date: Tue, 22 Mar 94 13:51:10 GMT Subject: Class C subnetting and Novell TCP/IP Message-ID: <9403221351.AA00229@buche> > The justification offered for this is that the routing sotware for > Novell servers and/or Novell Lan Workplace (their PC TCP/IP software) > does not support subnetting of Class Cs. My initial reaction was > disbelief that this sort of Dinosaur DNA is still so prevalent, but > more than one offer of this sort of justification seems to suggest > it is. If this is indeed true (and my reaction is a bit like Keith's) we certainly should put strong pressure on Novell to get this right. My view would be to give these applicants a "reasonable" number of Class C numbers so that they can get on today, but warn them that the same justification won't be accepted next time and that they must complain to Novell. In practice, though, I guess they'd "only" cut usage by a factor of 2 by using 4-bit subnets in this case. What I find more of a pain is that it may be difficult to connect a site to an external network via a Novell server and using a 2-bit subnet. (We do this with IP connections to JANET and I guess others do.) If the server couldn't support this we'd have to end up using a whole Class C for a point-to-point link. Bob Day From bob at informatics.rutherford.ac.uk Tue Mar 22 15:40:58 1994 From: bob at informatics.rutherford.ac.uk (bob at informatics.rutherford.ac.uk) Date: Tue, 22 Mar 94 14:40:58 GMT Subject: Class C subnetting and Novell TCP/IP Message-ID: <9403221440.AA00266@buche> Guys, I just got this from one of our Novell experts (we have a group of people working in this area). Sounds like Novell have got ot right, at least in the code. May be a documentation problem, I guess, if their customers are not understanding... Anyhow, I suggest that: (a) Keith rejects the reason, saying that it's understood that Novell do support this subnetting.... (b) if said customers persist perhaps Daniel could pursue this with his Novell contact to get a definitive statement? Bob ----- Begin Included Message ----- From DREW at uk.ac.ulst.infc.CAUSEWAY Tue Mar 22 15:29:25 1994 From: DREW at uk.ac.ulst.infc.CAUSEWAY (Andrew Gregg) Date: Tue, 22 Mar 1994 14:29:25 GMT Subject: Class C subnetting and Novell TCP/IP Message-ID: Novell Fileserver routing DOES support class C subnetting. Until this earlier this year we had a Novell Fileserver routing between a subnetted class C address... Class C subnetting using novell netware requires at least 2 bits mask bits in the class to allow for subnetworking. therefore our mask was FF.FF.FF.C0 and our IP numbers were assigned... nnn.nnn.nnn.128 to 190 for one sub net and 65-126 for the other. ===================================================================== Andrew Gregg | A.Gregg at ulst.ac.uk Faculty of Informatics | 100024.3074 at compuserve.com University of Ulster | Cromore Road, Coleraine, | Tel: 0265 44141 x 4243 Londonderry, N. Ireland. | FAX: 0265 40916 ====================================================================== ----- End Included Message ----- From keith at pipex.net Tue Mar 22 16:23:00 1994 From: keith at pipex.net (Keith Mitchell) Date: Tue, 22 Mar 1994 15:23:00 +0000 Subject: Class C subnetting and Novell TCP/IP In-Reply-To: <9403221440.AA00266@buche> Message-ID: <199403221523.PAA01952@pipe.pipex.net> Bob/Andrew, > From: "Andrew Gregg" > Date: Tue, 22 Mar 1994 14:29:25 GMT > Subject: Re: Class C subnetting and Novell TCP/IP > Reply-To: A.Gregg at uk.ac.ulst > Novell Fileserver routing DOES support class C subnetting. Until > this earlier this year we had a Novell Fileserver routing between a > subnetted class C address... > > Class C subnetting using novell netware requires at least 2 bits > mask bits in the class to allow for subnetworking. > > therefore our mask was FF.FF.FF.C0 and our IP numbers were > assigned... nnn.nnn.nnn.128 to 190 for one sub net and 65-126 for > the other. Thanks - this is exactly what I was looking for. Can I presume on your helpfulness one more bit, and ask if there are any particular version/revision levels this is available under, just in case they are running old software ? It would also be nice to get the definitive answer on the LAN Workplace product too, though if that is broken I guess proxy ARP is a possibility. > Anyhow, I suggest that: > > (a) Keith rejects the reason, saying that it's understood that Novell > do support this subnetting.... > > (b) if said customers persist perhaps Daniel could pursue this with his > Novell contact to get a definitive statement? > > Bob Sounds fine to me. Thanks to everyone who responded, Keith From Daniel.Karrenberg at ripe.net Tue Mar 22 16:50:37 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Mar 1994 16:50:37 +0100 Subject: Class C subnetting and Novell TCP/IP In-Reply-To: Your message of Tue, 22 Mar 1994 14:40:58 GMT. <9403221440.AA00266@buche> Message-ID: <9403221550.AA09947@reif.ripe.net> > bob at informatics.rutherford.ac.uk writes: > > Anyhow, I suggest that: > > (a) Keith rejects the reason, saying that it's understood that Novell > do support this subnetting.... > > (b) if said customers persist perhaps Daniel could pursue this with his > Novell contact to get a definitive statement? The customer's answer notwithstanding I have already started on b). Daniel From bob at informatics.rutherford.ac.uk Tue Mar 22 16:55:34 1994 From: bob at informatics.rutherford.ac.uk (bob at informatics.rutherford.ac.uk) Date: Tue, 22 Mar 94 15:55:34 GMT Subject: Class C subnetting and Novell TCP/IP Message-ID: <9403221555.AA00296@buche> Keith, > are running old software ? It would also be nice to get the definitive > answer on the LAN Workplace product too, though if that is broken > I guess proxy ARP is a possibility. I got a note in from John Williams at Aston saying they've used subnetting on LAN Workplace. Guess you could check version no. with him.... Bob ------------- From williamj at uk.ac.aston Tue Mar 22 16:21:12 1994 From: williamj at uk.ac.aston (John Williams) Date: Tue, 22 Mar 1994 15:21:12 +0000 Subject: Class C subnetting and Novell TCP/IP Message-ID: > Guys, > > Can any of you experts confirm/deny the suspicion voiced here about > Novell's less than useful abilities in subnettting? > > I found it difficult to believe but, if true, it's a significant > failing -- perhaps not so much in our community as elsewhere. > > Comments welcome. Please reply to me DIRECT as I'm not on the ning list. > > Thanks, > Bob Day > Bob, we use class C subnetting (on a subnetted class B network) and have for some time with packet drivers and LAN WorkPlace for DOS. What it doesn't do is arp properly and we have to use proxyarp. John extract from autoexec.ncf: file server name CHARLIE ipx internal net 86974c03 lo... load ne3200 frame=ethernet_ii slot=8 name=accente load c:smce32 frame=ethernet_ii port=1810 slot=1 name=519e load c:smce32 frame=ethernet_ii port=1820 slot=1 name=473475e load ne3200 frame=ethernet_ii slot=7 name=471480e bind ipx to accente frame=ethernet_ii net=5 bind ipx to 519e frame=ethernet_ii net=519 bind ipx to 473475e frame=ethernet_ii net=473475 bind ipx to 471480e ethernet_ii net=471480 load tcpip forward=yes rip=off load bootpfwd 134.151.79.14 bind ip to accente mask=255.255.255.192 addr=134.151.76.3 gate=134.151.79.27 bind ip to 473475e mask=255.255.255.192 addr=134.151.76.131 bind ip to 471480e mask=255.255.255.192 addr=134.151.76.67 bind ip to 519e mask=255.255.255.192 addr=134.151.76.195 rem load netshld load load remote everest786 load rspx load rdate /p 60 /v 1 134.151.79.14 rem load pserver charlie_qs1 load monitor p ns mount all load mercury load mercurys load mercuryc load lpr 4f142932 verbose ------------------------------------------------------------------- John Williams Software Support Manager Information Systems Aston University Birmingham B4 &ET UK +44 21-359-3611 X 5142 +44 21-359 6158 (FAX) j.williams at aston.ac.uk ------------------------------------------------------------------- From keith at pipex.net Wed Mar 23 15:50:56 1994 From: keith at pipex.net (Keith Mitchell) Date: Wed, 23 Mar 1994 14:50:56 +0000 Subject: Class C subnetting and Novell TCP/IP In-Reply-To: <9403221550.AA09947@reif.ripe.net> Message-ID: <199403231450.OAA25075@pipe.pipex.net> In <9403230932.AA00251 at buche>, wrote: > To all those that replied: many thanks, we seem to have unanimous agreement > that subnetting on any (legal) mask is indeed possible, and that perhaps > it's more a documentation/education problem. > > Keith's taking this back to those customers of his who started this > particular hare running. Well, I just have, and they were indeed trying to break the subnetting rules for Class Cs, this was their problem. Suddenly their existing allocation became enough. Thanks to everyone for clearing this up, particulary the JNT for usefully re-circulating my request, and Andrew Gregg at University of Ulster for hard exerience. In <9403221550.AA09947 at reif.ripe.net>, wrote: > > bob at informatics.rutherford.ac.uk writes: > > (b) if said customers persist perhaps Daniel could pursue this with his > > Novell contact to get a definitive statement? > > The customer's answer notwithstanding I have already started on b). My apologies for casting aspersions at Novell - if Daniel does have a word with them, it should probably be to the effect their documentation needs to be idiot-proofed a bit better. Keith (I have a short one-page guide which describes all the legal subnetting options for Class Cs that we give to customers. If there was interest, it might be a good idea to expand this to include the valid host address ranges associated with each mask, and make it available.) From nipper at xlink.net Wed Mar 23 16:18:44 1994 From: nipper at xlink.net (Arnold Nipper) Date: Wed, 23 Mar 1994 16:18:44 +0100 (MET) Subject: Class C subnetting and Novell TCP/IP In-Reply-To: <199403231450.OAA25075@pipe.pipex.net> from "Keith Mitchell" at Mar 23, 94 02:50:56 pm Message-ID: <"xlink100.x.909:23.02.94.15.18.44"@xlink.net> Keith Mitchell wrote: > > (I have a short one-page guide which describes all the legal > subnetting options for Class Cs that we give to customers. If there > was interest, it might be a good idea to expand this to include the > valid host address ranges associated with each mask, and make it > available.) Good idea. Regard, Arnold -- Arnold Nipper / email: nipper at xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany