In English please!

Kunskapsdatabas

Grundläggande TCP/IP

IP adresser i privata nätverk

Information för administratörer av interna nätverk som använder TCP/IP och inte är anslutna till Internet.

Detta är ett uttdrag från RFC 1597 fritt översatt av oss. För en komplett beskrivning se "Complete RFC list"

March 1994

Detta dokuments status

Detta dokument innehåller riktlinjer för Internetanvändning.
Dokumentet anger inte en standard för internet
Detta dokument får distribueras fritt.

1. Introduktion

Detta dokument beskriver metoder att spara på IP adresser genom att inte tilldela unika IP adresser till maskiner som saknar anslutning till Internet.

Författarna hoppas att detta skall medföra att stora adressområden skall kunna frigöras. Ett företag som använder TCP/IP och inte är anslutet till internet kan med hjälp av detta dokument bestämma en adresseringsplan för sitt nätverk.

2. Motivation

I och med att TCP/IP vunnit i popularitet även utanför Internet har ett stort antal nätverk börjat använda TCP/IP för intern kommunikation och för kommunikation mellan nätverk utan planer på, framtida internetanslutning.

Det finns också farhågor att TCP/IP adresserna ska ta slut. Detta medför att det har blivit svårare att erhålla adresser. Dessa regler är ofta restrektivare än vad som önskas av företag i behov av adresser.

Maskiner inom ett företag som använder IP kan klassas i tre olika kategorier.

• maskiner som inte behöver komma åt internet eller nätverk utanför det egna företaget.
• maskiner som behöver en begränsad möjlighet att kommunicera med maskiner utanför det egna nätverket. Detta kan vara e-mail, FTP, netnews och hanteras lämpligen av gateways.
• maskiner som behöver direkt access till maskiner utanför det egna nätverket.

För maskiner från den andra gruppen är en direkt förbindelse till Internet obehövlig och ibland till och med oönskad med tanke på säkerhet etc. Sådana maskiner kan med fördel använda adresser som inte är unika så länge dessa är unika inom företaget.

Endast maskiner i den sista gruppen behöver använda adresser som är unika.

Många applikationer arbetar bara mot maskiner som finns inom det egna företaget utan anslutningar till andra nät. Inom ett företag är det ofta relativt enkelt att identifiera dessa maskiner.

3. Private Address Space

Internet Assigned Numbers Authority (IANA) har reserverat följande adressområden för privata nätverk:

Det första blocket kommer att nämnas som ett 24 bitars block, det andra området som ett 20 bitars block och det tredje som ett 16 bitars block. Observer att det första är inget annat än ett enda CLass A nät medan det andra blcoket består av 16 stycken Class B nät intill varandra och det tredje blocket består av 255 intillvarandra liggande Class C nät. En nätverksadministratör kan välja att använda vilka adresser som helst inom ovanstående område utan att behöva registrera adresserna hos IANA eller motsvarande registerorganisation. Adresser inom ovanstående område kommer bara att vara unika inom den egna verksamheten.

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. Such hosts will be called private hosts, and will use the private address space defined 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.

4. Advantages and Disadvantages of Using Private Address Space

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 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.

5. Operational Considerations

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.

Att använda flera IP (sub)nät på ett och samma fysiska nät har många fallgropar. Detta bör undvikas utom i de fall då förståelse för hela problematiken finns och all utrustning bevisligen fungerar i en sådan miljö.

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 common 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 using 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.

6. Referenser

[1] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993.

7. Säkerhetsaspekter

Trots att användning av privata adressområden kan öka säkerheten är det inte en ersättning för sedvanliga säkerhetsåtgärder.

8. Conclusion

9. Acknowledgments

Vi vill tacka 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) för deras medverkan och konstruktiva kritik.

10. Authors' 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@watson.ibm.com

Robert G Moskowitzv
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@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@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@ripe.net