📄 rfc1380.txt
字号:
- Changes required to operations tools (e.g., ping, trace- route, etc.) - Changes to operational and administration procedures The changes should also include if hosts and routers have their current IP addresses changed. The impact and changes to the existing set of TCP/IP protocols should be described. This should include at a minimum: - IP - ICMP - DNS - ARP/RARP - TCP - UDP - FTP - RPC - SNMP The impact on protocols which use IP addresses as data should be specifically addressed.Gross & Almquist [Page 17]RFC 1380 ROAD November 1992B.3 Implementation Experience A description of implementation experience with the proposal should be supplied. This should include the how much of the proposal was implemented and hard it was to implement. If it was implemented by modifying existing code, the extent of the modifications should be described.B.4 Large Internet Support The proposal should describe how it will scale to support a large internet of a billion networks. It should describe how the proposed routing and addressing architecture will work to support an internet of this size. This should include, as appropriate, a description of the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact (e.g., interior and exterior, or L1, L2, L3, etc.), and relationship between addressing and routing. The addressing proposed should include a description of how addresses will be assigned, who owns the addresses (e.g., user or service provider), and whether there are restrictions in address assignment or topology.B.5 Syntax and semantics of names, identifiers and addresses Proposals should address the manner in which data sources and sinks are identified and addressed, describe how current domain names and IP addresses would be used/translated/mapped in their scheme, how proposed new identifier and address fields and semantics are used, and should describe the issues involved in administration of these id and address spaces according to their proposal. The deployment plan should address how these new semantics would be introduced and backward compatibility maintained. Any overlays in the syntax of these protocol structures should be clearly identified and conflicts resulting from syntactic overlay of functionality should be clearly addressed in the discussion of the impact on administrative assignment.B.6 Performance Impact The performance impact of the new routing and addressing architecture should be evaluated. It should be compared against the current state of the art with the current IP. The performance evaluation for routers and hosts should include packets-per-second and memory usage projections, and bandwidth usage for networks. Performance should be evaluated for both high speed speed and low speed lines.Gross & Almquist [Page 18]RFC 1380 ROAD November 1992 Performance for routers (table size and computational load) and network bandwidth consumption should be projected based on the following projected data points: -Domains 10^3 10^4 10^5 10^6 10^7 10^8 -Networks 10^4 10^5 10^6 10^7 10^8 10^9 -Hosts 10^6 10^7 10^8 10^9 10^10 10^11B.7 Support for TCP/IP hosts than do not support the new architecture The proposal should describe how hosts which do not support the new architecture will be supported -- whether they receive full services and can communicate with the whole Internet, or if they will receive limited services. Also, describe if a translation service be provided between old and new hosts? If so, where will be this be done.B.8 Effect on User Community The large and growing installed base of IP systems comprises people, as well as software and machines. The proposal should describe changes in understanding and procedures that are used by the people involved in internetworking. This should include new and/or changes in concepts, terminology, and organization.B.9 Deployment Plan Description The proposal should include a deployment plan. It should include the steps required to deploy it. Each step should include the devices and protocols which are required to change and what benefits are derived at each step. This should also include at each step if hosts and routers are required to run the current and proposed internet protocol. A schedule should be included, with justification showing that the schedule is realistic.B.10 Security Impact The impact on current and future security plans should be addressed. Specifically do current security mechanisms such as address and protocol port filtering work in the same manner as they do today, and what is the effect on security and authentication schemes currently under development.B.11 Future Evolution The proposal should describe how it lays a foundation for solvingGross & Almquist [Page 19]RFC 1380 ROAD November 1992 emerging internet problems such as security/authentication, mobility, resource allocation, accounting, high packet rates, etc.Appendix C. BIBLIOGRAPHY-Documents and Information from IETF/IESG: [Ford92] Ford, P., and P. Gross, "Routing And Addressing Considerations", Proceedings of the Twenty-Third IETF, March 1992. [Gross92] Gross, P., "Chair's Message and Minutes of the Open IETF Plenary", Proceedings of the Twenty-Third IETF, March 1992. [Gross92a] Gross, P., "IESG Deliberations on Routing and Addressing", Electronic mail message to the Big-Internet mailing list, June 1992.-Documents directly resulting from the ROAD group: [Fuller92] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992. [Hinden92] Hinden, B., "New Scheme for Internet Routing and Addressing (ENCAPS)", Email message to Big-Internet mailing list, March 16, 1992. [Callon92a] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992 [Deering92] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP Allocation in the Internet", Email message to Big-Internet mailing list, January 7, 1992. [Callon92b] CNAT-Related Documents: [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible version of IP with Large Addresses", Work in Progress, June 1992. [Deering92b] Deering, S., "The Simple Internet Protocol", Big- Internet mailing list. [Stockman92] Karrenberg, D., and B. Stockman, "A Proposal for a Global Internet Addressing Scheme", Work in Progress, May 1992.Gross & Almquist [Page 20]RFC 1380 ROAD November 1992 [Rekhter92] Rekhter, Y., and T. Li, "Guidelines for IP Address Allocation", Work in Progress, May 1992. [Rekhter92b] Rekhter, Y., and T. Li, "The Border Gateway Protocol (Version 4)", Work in Progress, September 1992. [Rekhter92c] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol", Work in Progress, September 1992. [Gerich92] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1366, Merit, October 1992. [Solen92] Solensky, F., and F. Kastenholz, "A Revision to IP Address Classifications", Work in Progress, March 1992. [Wang92] Wany, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", RFC 1335, University College London, May 1992. [Callon91] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July 1991. [Tsuchiya92a] Tsuchiya, P., "The IP Network Address Translator (NAT): Preliminary Design", Work in Progress, April 1991. [Tsuchiya92b] Tsuchiya, P., "The 'P' Internet Protocol", Work in Progress, May 1992. [Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress, July 1991. [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.Security Considerations Security issues are discussed in sections 4.4, B.2, B.10, and B.11.Gross & Almquist [Page 21]RFC 1380 ROAD November 1992Authors' Addresses Phillip Gross, IESG Chair Advanced Network & Services 100 Clearbrook Road Elmsford, NY Phone: 914-789-5300 EMail: pgross@ans.net Philip Almquist Stanford University Networking Systems Pine Hall 147 Stanford, CA 94305 Phone: (415) 723-2229 EMail: Almquist@JESSICA.STANFORD.EDUGross & Almquist [Page 22]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -