Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Nov 1998 20:37:13 -0500 (EST)
From:      User MAT <mat@blondie.ottawa.cc>
To:        Jesper Skriver <jesper@skriver.dk>
Cc:        Leif Neland <root@swimsuit.internet.dk>, freebsd-isp@FreeBSD.ORG
Subject:   Re: two routers back to back: Do they need real ip-adresses?
Message-ID:  <Pine.BSF.4.05.9811132029500.17115-100000@blondie.ottawa.cc>
In-Reply-To: <19981113090526.A10967@skriver.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811132029500.17115-100000>