From d1b6f62893fa0cb8038687d77f4a22de7566935d Mon Sep 17 00:00:00 2001 From: Onur Date: Thu, 6 Feb 2025 19:52:35 +0100 Subject: [PATCH] Add Search and Replace --- session-1/AMail.txt | 507 ++++++++++++++++++++++++++++++++ session-1/rfc1819.txt | 507 ++++++++++++++++++++++++++++++++ session-1/search-and-replace.py | 10 + 3 files changed, 1024 insertions(+) create mode 100644 session-1/AMail.txt create mode 100644 session-1/rfc1819.txt create mode 100644 session-1/search-and-replace.py diff --git a/session-1/AMail.txt b/session-1/AMail.txt new file mode 100644 index 0000000..7ca2151 --- /dev/null +++ b/session-1/AMail.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group Y. Rekhter +Request for Comments: 1918 Cisco Systems +Obsoletes: 1627, 1597 B. Moskowitz +BCP: 5 Chrysler Corp. +Category: Best Current Practice D. Karrenberg + RIPE NCC + G. J. de Groot + RIPE NCC + E. Lear + Silicon Graphics, Inc. + February 1996 + + + Address Allocation for Private Internets + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +1. Introduction + + For the purposes of this document, 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. + + This document describes address allocation for private internets. The + allocation permits full network layer connectivity among all hosts + inside an enterprise as well as among all public hosts of different + enterprises. The cost of using private internet address space is the + potentially costly effort to renumber hosts and networks between + public and private. + +2. 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 Internet has grown beyond anyone's expectations. Sustained + exponential growth continues to introduce new challenges. One + challenge is a concern within the community that globally unique + address space will be exhausted. A separate and far more pressing + concern is that the amount of routing overhead will grow beyond the + + + +Rekhter, et al Best Current Practice [Page 1] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + capabilities of Internet Service Providers. Efforts are in progress + within the community to find long term solutions to both of these + problems. Meanwhile it is necessary to revisit address allocation + procedures, and their impact on the Internet routing system. + + To contain growth of routing overhead, an Internet Provider obtains a + block of address space from an address registry, and then assigns to + its customers addresses from within that block based on each customer + requirement. The result of this process is that routes to many + customers will be aggregated together, and will appear to other + providers as a single route [RFC1518], [RFC1519]. In order for route + aggregation to be effective, Internet providers encourage customers + joining their network to use the provider's block, and thus renumber + their computers. Such encouragement may become a requirement in the + future. + + With the current size of the Internet and its growth rate it is no + longer realistic to assume that by virtue of acquiring globally + unique IP addresses out of an Internet registry an organization that + acquires such addresses would have Internet-wide IP connectivity once + the organization gets connected to the Internet. To the contrary, it + is quite likely that when the organization would connect to the + Internet to achieve Internet-wide IP connectivity the organization + would need to change IP addresses (renumber) all of its public hosts + (hosts that require Internet-wide IP connectivity), regardless of + whether the addresses used by the organization initially were + globally unique or not. + + It has been typical to assign globally unique addresses to all hosts + that use TCP/IP. In order to extend the life of the IPv4 address + space, address registries are requiring more justification than ever + before, making it harder for organizations to acquire additional + address space [RFC1466]. + + Hosts within enterprises that use IP can be partitioned into three + categories: + + Category 1: hosts that do not require access to hosts in other + enterprises or the Internet at large; hosts within + this category may use IP addresses that are + unambiguous within an enterprise, but may be + ambiguous between enterprises. + + Category 2: hosts that need access to a limited set of outside + services (e.g., E-mail, FTP, netnews, remote login) + which can be handled by mediating gateways (e.g., + application layer gateways). For many hosts in this + category an unrestricted external access (provided + + + +Rekhter, et al Best Current Practice [Page 2] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + 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. + + Category 3: hosts that need network layer access outside the + enterprise (provided via IP connectivity); hosts in + the last category require IP addresses that are + globally unambiguous. + + We will refer to the hosts in the first and second categories as + "private". We will refer to the hosts in the third category as + "public". + + Many applications require connectivity only within one enterprise and + do not need external (outside the enterprise) 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 organizations 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 equipment at clerical positions rarely need + to have such connectivity. + + - For security reasons, many enterprises use application + layer gateways 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 + gateways are visible from the Internet. In this case, the + internal network can use non-unique IP network numbers. + + - Interfaces of routers on an internal network usually do not + need to be directly accessible from outside the enterprise. + + + + + + +Rekhter, et al Best Current Practice [Page 3] + +RFC 1918 Address Allocation for Private Internets February 1996 + + +3. Private Address Space + + The Internet Assigned Numbers Authority (IANA) has reserved the + following three blocks of the IP address space for private internets: + + 10.0.0.0 - 10.255.255.255 (10/8 prefix) + 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) + 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) + + We will refer to the first block as "24-bit block", the second as + "20-bit block", and to the third as "16-bit" block. Note that (in + pre-CIDR notation) the first block is nothing but a single class A + network number, while the second block is a set of 16 contiguous + class B network numbers, and third block is a set of 256 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, 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. However, they cannot + have IP connectivity to any host outside of the enterprise. 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. + + + + + +Rekhter, et al Best Current Practice [Page 4] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + Moving a host from private to public or vice versa involves a change + of IP address, changes to the appropriate DNS entries, and changes to + configuration files on other hosts that reference the host by 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 + + 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 been 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. If such an enterprise + would later connects to the Internet, this could potentially create + very serious problems, as IP routing cannot provide correct + operations in presence of ambiguous addressing. Although in principle + Internet Service Providers should guard against such mistakes through + the use of route filters, this does not always happen in practice. + Using private address space provides a safe choice for such + enterprises, avoiding clashes once outside connectivity is needed. + + + + + +Rekhter, et al Best Current Practice [Page 5] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + A major drawback to the use of private address space is that it may + actually reduce an enterprise's flexibility to access the Internet. + Once one commits to using a private address, one is committing to + renumber part or all of an enterprise, should one decide to provide + IP connectivity between that part (or all of the enterprise) and the + Internet. Usually the cost of renumbering can be measured by + counting the number of hosts that have to transition from private to + public. As was discussed earlier, however, even if a network uses + globally unique addresses, it may still have to renumber in order to + acquire Internet-wide IP connectivity. + + Another drawback to the use of private address space is that it may + require renumbering when merging several private internets into a + single private internet. If we review the examples we list in Section + 2, we note that companies tend to merge. If such companies prior to + the merge maintained their uncoordinated internets using private + address space, then if after the merge these private internets would + be combined into a single private internet, some addresses within the + combined private internet may not be unique. As a result, hosts with + these addresses would need to be renumbered. + + The cost of renumbering may well be mitigated by development and + deployment of tools that facilitate renumbering (e.g. Dynamic Host + Configuration Protocol (DHCP)). When deciding whether to use private + addresses, we recommend to inquire computer and software vendors + about availability of such tools. A separate IETF effort (PIER + Working Group) is pursuing full documentation of the requirements and + procedures for renumbering. + +5. Operational Considerations + + One possible 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 does not need to be fixed permanently. If a group of one + or more hosts requires to change their status (from private to public + or vice versa) later, this can be accomplished by renumbering only + the hosts involved, and changing physical connectivity, if needed. In + locations where such changes can be foreseen (machine rooms, etc.), + it is advisable to configure separate physical media for public and + private subnets to facilitate such changes. In order to avoid major + network disruptions, it is advisable to group hosts with similar + connectivity needs on their own subnets. + + + + + + +Rekhter, et al Best Current Practice [Page 6] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + If a suitable subnetting scheme can be designed and is supported by + the equipment concerned, it is advisable to use the 24-bit block + (class A network) of private address space and make an addressing + plan with a good growth path. If subnetting is a problem, the 16-bit + block (class C networks), or the 20-bit block (class B networks) of + private address space can be used. + + One might be tempted to have both public and private addresses on the + same physical medium. While this is possible, there are pitfalls to + such a design (note that the pitfalls have nothing to do with the use + of private addresses, but are due to the presence of multiple IP + subnets on a common Data Link subnetwork). We advise caution when + proceeding in this area. + + 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. + + It is possible for two sites, who both coordinate their private + address space, to communicate with each other over a public network. + To do so they must use some method of encapsulation at their borders + to a public network, thus keeping their private addresses private. + + If two (or more) organizations follow the address allocation + specified in this document and then later wish to establish IP + connectivity with each other, then there is a risk that address + uniqueness would be violated. To minimize the risk it is strongly + recommended that an organization using private IP addresses choose + randomly from the reserved pool of private addresses, when allocating + sub-blocks for its internal allocation. + + If an enterprise uses the private address space, or a mix of private + and public address spaces, then DNS clients outside of the enterprise + should not see addresses in the private address space used by the + enterprise, since these addresses would be ambiguous. One way to + ensure this is to run two authority servers for each DNS zone + containing both publically and privately addressed hosts. One server + would be visible from the public address space and would contain only + the subset of the enterprise's addresses which were reachable using + public addresses. The other server would be reachable only from the + private network and would contain the full set of data, including the + private addresses and whatever public addresses are reachable the + private network. In order to ensure consistency, both servers should + be configured from the same data of which the publically visible zone + + + +Rekhter, et al Best Current Practice [Page 7] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + only contains a filtered version. There is certain degree of + additional complexity associated with providing these capabilities. + +6. Security Considerations + + Security issues are not addressed in this memo. + +7. 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. However, use of private addressing requires that an + organization renumber part or all of its enterprise network, as its + connectivity requirements change over time. + +8. Acknowledgments + + We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- + Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN + Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne + Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), + Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), + Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush + (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg + Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), + Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet + Software Consortium) for their review and constructive comments. + +9. References + + [RFC1466] Gerich, E., "Guidelines for Management of IP Address + Space", RFC 1466, Merit Network, Inc., May 1993. + + [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address + Allocation with CIDR", RFC 1518, September 1993. + + [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + + + + + + + +Rekhter, et al Best Current Practice [Page 8] + +RFC 1918 Address Allocation for Private Internets February 1996 + + +10. Authors' Addresses + + Yakov Rekhter + Cisco systems + 170 West Tasman Drive + San Jose, CA, USA + Phone: +1 914 528 0090 + Fax: +1 408 526-4952 + AMail: yakov@cisco.com + + + 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 + AMail: rgm3@is.chrysler.com + + + Daniel Karrenberg + RIPE Network Coordination Centre + Kruislaan 409 + 1098 SJ Amsterdam, the Netherlands + Phone: +31 20 592 5065 + Fax: +31 20 592 5090 + AMail: 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 + AMail: GeertJan.deGroot@ripe.net + + + Eliot Lear + Mail Stop 15-730 + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + Mountain View, CA 94043-1389 + Phone: +1 415 960 1980 + Fax: +1 415 961 9584 + AMail: lear@sgi.com + + + + +Rekhter, et al Best Current Practice [Page 9] + diff --git a/session-1/rfc1819.txt b/session-1/rfc1819.txt new file mode 100644 index 0000000..43c0b2f --- /dev/null +++ b/session-1/rfc1819.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group Y. Rekhter +Request for Comments: 1918 Cisco Systems +Obsoletes: 1627, 1597 B. Moskowitz +BCP: 5 Chrysler Corp. +Category: Best Current Practice D. Karrenberg + RIPE NCC + G. J. de Groot + RIPE NCC + E. Lear + Silicon Graphics, Inc. + February 1996 + + + Address Allocation for Private Internets + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +1. Introduction + + For the purposes of this document, 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. + + This document describes address allocation for private internets. The + allocation permits full network layer connectivity among all hosts + inside an enterprise as well as among all public hosts of different + enterprises. The cost of using private internet address space is the + potentially costly effort to renumber hosts and networks between + public and private. + +2. 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 Internet has grown beyond anyone's expectations. Sustained + exponential growth continues to introduce new challenges. One + challenge is a concern within the community that globally unique + address space will be exhausted. A separate and far more pressing + concern is that the amount of routing overhead will grow beyond the + + + +Rekhter, et al Best Current Practice [Page 1] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + capabilities of Internet Service Providers. Efforts are in progress + within the community to find long term solutions to both of these + problems. Meanwhile it is necessary to revisit address allocation + procedures, and their impact on the Internet routing system. + + To contain growth of routing overhead, an Internet Provider obtains a + block of address space from an address registry, and then assigns to + its customers addresses from within that block based on each customer + requirement. The result of this process is that routes to many + customers will be aggregated together, and will appear to other + providers as a single route [RFC1518], [RFC1519]. In order for route + aggregation to be effective, Internet providers encourage customers + joining their network to use the provider's block, and thus renumber + their computers. Such encouragement may become a requirement in the + future. + + With the current size of the Internet and its growth rate it is no + longer realistic to assume that by virtue of acquiring globally + unique IP addresses out of an Internet registry an organization that + acquires such addresses would have Internet-wide IP connectivity once + the organization gets connected to the Internet. To the contrary, it + is quite likely that when the organization would connect to the + Internet to achieve Internet-wide IP connectivity the organization + would need to change IP addresses (renumber) all of its public hosts + (hosts that require Internet-wide IP connectivity), regardless of + whether the addresses used by the organization initially were + globally unique or not. + + It has been typical to assign globally unique addresses to all hosts + that use TCP/IP. In order to extend the life of the IPv4 address + space, address registries are requiring more justification than ever + before, making it harder for organizations to acquire additional + address space [RFC1466]. + + Hosts within enterprises that use IP can be partitioned into three + categories: + + Category 1: hosts that do not require access to hosts in other + enterprises or the Internet at large; hosts within + this category may use IP addresses that are + unambiguous within an enterprise, but may be + ambiguous between enterprises. + + Category 2: hosts that need access to a limited set of outside + services (e.g., E-mail, FTP, netnews, remote login) + which can be handled by mediating gateways (e.g., + application layer gateways). For many hosts in this + category an unrestricted external access (provided + + + +Rekhter, et al Best Current Practice [Page 2] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + 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. + + Category 3: hosts that need network layer access outside the + enterprise (provided via IP connectivity); hosts in + the last category require IP addresses that are + globally unambiguous. + + We will refer to the hosts in the first and second categories as + "private". We will refer to the hosts in the third category as + "public". + + Many applications require connectivity only within one enterprise and + do not need external (outside the enterprise) 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 organizations 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 equipment at clerical positions rarely need + to have such connectivity. + + - For security reasons, many enterprises use application + layer gateways 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 + gateways are visible from the Internet. In this case, the + internal network can use non-unique IP network numbers. + + - Interfaces of routers on an internal network usually do not + need to be directly accessible from outside the enterprise. + + + + + + +Rekhter, et al Best Current Practice [Page 3] + +RFC 1918 Address Allocation for Private Internets February 1996 + + +3. Private Address Space + + The Internet Assigned Numbers Authority (IANA) has reserved the + following three blocks of the IP address space for private internets: + + 10.0.0.0 - 10.255.255.255 (10/8 prefix) + 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) + 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) + + We will refer to the first block as "24-bit block", the second as + "20-bit block", and to the third as "16-bit" block. Note that (in + pre-CIDR notation) the first block is nothing but a single class A + network number, while the second block is a set of 16 contiguous + class B network numbers, and third block is a set of 256 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, 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. However, they cannot + have IP connectivity to any host outside of the enterprise. 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. + + + + + +Rekhter, et al Best Current Practice [Page 4] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + Moving a host from private to public or vice versa involves a change + of IP address, changes to the appropriate DNS entries, and changes to + configuration files on other hosts that reference the host by 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 + + 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 been 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. If such an enterprise + would later connects to the Internet, this could potentially create + very serious problems, as IP routing cannot provide correct + operations in presence of ambiguous addressing. Although in principle + Internet Service Providers should guard against such mistakes through + the use of route filters, this does not always happen in practice. + Using private address space provides a safe choice for such + enterprises, avoiding clashes once outside connectivity is needed. + + + + + +Rekhter, et al Best Current Practice [Page 5] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + A major drawback to the use of private address space is that it may + actually reduce an enterprise's flexibility to access the Internet. + Once one commits to using a private address, one is committing to + renumber part or all of an enterprise, should one decide to provide + IP connectivity between that part (or all of the enterprise) and the + Internet. Usually the cost of renumbering can be measured by + counting the number of hosts that have to transition from private to + public. As was discussed earlier, however, even if a network uses + globally unique addresses, it may still have to renumber in order to + acquire Internet-wide IP connectivity. + + Another drawback to the use of private address space is that it may + require renumbering when merging several private internets into a + single private internet. If we review the examples we list in Section + 2, we note that companies tend to merge. If such companies prior to + the merge maintained their uncoordinated internets using private + address space, then if after the merge these private internets would + be combined into a single private internet, some addresses within the + combined private internet may not be unique. As a result, hosts with + these addresses would need to be renumbered. + + The cost of renumbering may well be mitigated by development and + deployment of tools that facilitate renumbering (e.g. Dynamic Host + Configuration Protocol (DHCP)). When deciding whether to use private + addresses, we recommend to inquire computer and software vendors + about availability of such tools. A separate IETF effort (PIER + Working Group) is pursuing full documentation of the requirements and + procedures for renumbering. + +5. Operational Considerations + + One possible 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 does not need to be fixed permanently. If a group of one + or more hosts requires to change their status (from private to public + or vice versa) later, this can be accomplished by renumbering only + the hosts involved, and changing physical connectivity, if needed. In + locations where such changes can be foreseen (machine rooms, etc.), + it is advisable to configure separate physical media for public and + private subnets to facilitate such changes. In order to avoid major + network disruptions, it is advisable to group hosts with similar + connectivity needs on their own subnets. + + + + + + +Rekhter, et al Best Current Practice [Page 6] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + If a suitable subnetting scheme can be designed and is supported by + the equipment concerned, it is advisable to use the 24-bit block + (class A network) of private address space and make an addressing + plan with a good growth path. If subnetting is a problem, the 16-bit + block (class C networks), or the 20-bit block (class B networks) of + private address space can be used. + + One might be tempted to have both public and private addresses on the + same physical medium. While this is possible, there are pitfalls to + such a design (note that the pitfalls have nothing to do with the use + of private addresses, but are due to the presence of multiple IP + subnets on a common Data Link subnetwork). We advise caution when + proceeding in this area. + + 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. + + It is possible for two sites, who both coordinate their private + address space, to communicate with each other over a public network. + To do so they must use some method of encapsulation at their borders + to a public network, thus keeping their private addresses private. + + If two (or more) organizations follow the address allocation + specified in this document and then later wish to establish IP + connectivity with each other, then there is a risk that address + uniqueness would be violated. To minimize the risk it is strongly + recommended that an organization using private IP addresses choose + randomly from the reserved pool of private addresses, when allocating + sub-blocks for its internal allocation. + + If an enterprise uses the private address space, or a mix of private + and public address spaces, then DNS clients outside of the enterprise + should not see addresses in the private address space used by the + enterprise, since these addresses would be ambiguous. One way to + ensure this is to run two authority servers for each DNS zone + containing both publically and privately addressed hosts. One server + would be visible from the public address space and would contain only + the subset of the enterprise's addresses which were reachable using + public addresses. The other server would be reachable only from the + private network and would contain the full set of data, including the + private addresses and whatever public addresses are reachable the + private network. In order to ensure consistency, both servers should + be configured from the same data of which the publically visible zone + + + +Rekhter, et al Best Current Practice [Page 7] + +RFC 1918 Address Allocation for Private Internets February 1996 + + + only contains a filtered version. There is certain degree of + additional complexity associated with providing these capabilities. + +6. Security Considerations + + Security issues are not addressed in this memo. + +7. 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. However, use of private addressing requires that an + organization renumber part or all of its enterprise network, as its + connectivity requirements change over time. + +8. Acknowledgments + + We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- + Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN + Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne + Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), + Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), + Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush + (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg + Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), + Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet + Software Consortium) for their review and constructive comments. + +9. References + + [RFC1466] Gerich, E., "Guidelines for Management of IP Address + Space", RFC 1466, Merit Network, Inc., May 1993. + + [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address + Allocation with CIDR", RFC 1518, September 1993. + + [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + + + + + + + +Rekhter, et al Best Current Practice [Page 8] + +RFC 1918 Address Allocation for Private Internets February 1996 + + +10. Authors' Addresses + + Yakov Rekhter + Cisco systems + 170 West Tasman Drive + San Jose, CA, USA + Phone: +1 914 528 0090 + Fax: +1 408 526-4952 + EMail: yakov@cisco.com + + + 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: rgm3@is.chrysler.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 + + + Eliot Lear + Mail Stop 15-730 + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + Mountain View, CA 94043-1389 + Phone: +1 415 960 1980 + Fax: +1 415 961 9584 + EMail: lear@sgi.com + + + + +Rekhter, et al Best Current Practice [Page 9] + diff --git a/session-1/search-and-replace.py b/session-1/search-and-replace.py new file mode 100644 index 0000000..dd905ae --- /dev/null +++ b/session-1/search-and-replace.py @@ -0,0 +1,10 @@ +infile = open("session-1/rfc1819.txt") +text = infile.readlines() +infile.close() +text = "".join(text) +text = text.replace("EMail", "AMail") +print(text) + +outfile = open("session-1/AMail.txt","w") +outfile.write(text) +outfile.close() \ No newline at end of file