From owner-freebsd-isp Fri Nov 13 12:38:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25869 for freebsd-isp-outgoing; Fri, 13 Nov 1998 12:38:06 -0800 (PST) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from blondie.ottawa.cc (blondie.ottawa.cc [209.112.49.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25857 for ; Fri, 13 Nov 1998 12:38:02 -0800 (PST) (envelope-from mat@blondie.ottawa.cc) Received: from localhost (mat@localhost) by blondie.ottawa.cc (8.9.1/8.9.1) with ESMTP id UAA17123; Fri, 13 Nov 1998 20:37:13 -0500 (EST) (envelope-from mat@blondie.ottawa.cc) Date: Fri, 13 Nov 1998 20:37:13 -0500 (EST) From: User MAT To: Jesper Skriver cc: Leif Neland , freebsd-isp@FreeBSD.ORG Subject: Re: two routers back to back: Do they need real ip-adresses? In-Reply-To: <19981113090526.A10967@skriver.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The "ethernet", which is only a crossed 10BT cable between the two > > routers, does it need real ip adresses? > > > > > > +-----------+ +-----------+ +----+ ----- > > --our net---+ E0 E1 +------+ E0 S0 |-----+ | \ > > 3C's | 1605 | | 100x | | +---- > > +-----------+ ^ +-----------+ +----+ > > | > > Can I use 192.168.1.0-adresses here? > > Or even unnumbered ip? > > > > Our uplink isp wants us to subnet one of our C's in a /30, is this really > > nessecary? > > You can't use unnumbered on broadcast media aka ethernet, so you need to > assign addresses to the interfaces, but these can be RFC1918 addresses, > that is if your ISP is willing to accept this. If you read the quote below, the third paragraph states that private IP's cannot have direct contact to the Internet. So IHO, the answer is no, you have to use a Globally un-Ambigous address. Mathew Quote from RFC 1918: (pg4..pg5, please excuse formating errors) 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, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet. 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 blocks defined 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 and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. [HERE-> However, they cannot have IP connectivity to any host outside of the enterprise. [<- HERE] While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be 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 public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message