rfc2956.txt

中、英文RFC文档大全打包下载完全版 .

3.5 Recommendations on DNS

   Operational stability of DNS is paramount, especially during a
   transition of the network layer, and both IPv6 and some network
   address translation techniques place a heavier burden on DNS.  It is
   therefore recommended to the IETF that, except for those changes that
   are already in progress and will support easier renumbering of
   networks and improved security, no fundamental changes or additions
   to the DNS be made for the foreseeable future.

   In order to encourage widespread deployment of IPsec, rapid
   deployment of DNSSEC is recommended to the operational community.




Kaat                         Informational                     [Page 11]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


3.6 Recommendations on Routing

   The only known addressing scheme which produces scalable routing
   mechanisms depends on topologically aggregated addresses, which
   requires that sites renumber when their position in the global
   topology changes.  Thus recommendation 3.3.1 is vital for routing
   IPv6.

   Although the same argument applies to IPv4, the installed base is
   simply too large and the PIER working group showed that little can be
   done to improve renumbering procedures for IPv4.  However, NAT and/or
   RSIP may help.

   In the absence of a new addressing model to replace topological
   aggregation, and of clear and substantial demand from the user
   community for a new routing architecture (i.e. path-selection
   mechanism) there is no reason to start work on standards for a "next
   generation" routing system in the IETF.  Therefore, we recommend that
   work should continue in the IRTF Routing Research Group.

3.7 Recommendations on Application layer and APIs

   Most current APIs such as sockets are an obstacle to migration to a
   new network layer of any kind, since they expose network layer
   internal details such as addresses.

   It is therefore recommended, as originally recommended in RFC 1900
   [3], that IETF protocols, and third-party applications, avoid any
   explicit awareness of IP addresses, when efficient operation of the
   protocol or application is feasible in the absence of such awareness.
   Some applications and services may continue to need to be aware of IP
   addresses.  Until we once again have a uniform address space for the
   Internet, such applications and services will necessarily have
   limited deployability, and/or require ALG support in NATs.

   Also we recommend an effort in the IETF to generalize APIs to offer
   abstraction from all network layer dependencies, perhaps as a side-
   effect of the namespace study of section 3.1.

4. Security Considerations

   The workshop did not address security as a separate topic, but the
   role of firewalls, and the desirability of end to end deployment of
   IPsec, were underlying assumptions.  Specific recommendations on
   security are covered in sections 3.4 and 3.5.






Kaat                         Informational                     [Page 12]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


References

   [1]   Carpenter, B., "Internet Transparency", RFC 2775, February
         2000.

   [2]   Hain, T., "Architectural Implications of NAT", Work in
         Progress.

   [3]   Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
         1900, February 1996.

   [4]   Ferguson, P and H. Berkowitz, "Network Renumbering Overview:
         Why would I want it and what is it anyway?", RFC 2071, January
         1997.

   [5]   M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang,
         "Separating Identifiers and Locators in Addresses: An Analysis
         of the GSE Proposal for IPv6", Work in Progress.

   [6]   Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6
         Address Aggregation and Renumbering", RFC 2874, July 2000.

   [7]   Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
         "DNS extensions to Network Address Translators (DNS_ALG)", RFC
         2694, September 1999.

   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [9]   M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific
         IP: Protocol Specification", Work in Progress.

   [10]  M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific
         IP: Framework", Work in Progress.

   [11]  G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec",
         Work in Progress.

   [12]  M. Holdrege, P. Srisuresh, "Protocol Complications with the IP
         Network Address Translator", Work in Progress.

   [13]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
         Protocol Translation (NAT-PT)", RFC 2766, February 2000.








Kaat                         Informational                     [Page 13]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   [14]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
         Hosts and Routers", RFC 2893, August 2000.

   [15]  B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
         Clouds", Work in Progress.














































Kaat                         Informational                     [Page 14]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


Appendix A. Participants

   Harald Alvestrand           [e-mail]
   Ran Atkinson                [e-mail]
   Rob Austein                 [e-mail]
   Steve Bellovin              [e-mail]
   Randy Bush                  [e-mail]
   Brian E Carpenter           [e-mail]
   Vint Cerf                   [e-mail]
   Noel Chiappa                [e-mail]
   Matt Crawford               [e-mail]
   Robert Elz                  [e-mail]
   Tony Hain                   [e-mail]
   Matt Holdrege               [e-mail]
   Erik Huizer                 [e-mail]
   Geoff Huston                [e-mail]
   Van Jacobson                [e-mail]
   Marijke Kaat                [e-mail]
   Daniel Karrenberg           [e-mail]
   John Klensin                [e-mail]
   Peter Lothberg              [e-mail]
   Olivier H. Martin           [e-mail]
   Gabriel Montenegro          [e-mail]
   Keith Moore                 [e-mail]
   Robert (Bob) Moskowitz      [e-mail]
   Philip J. Nesser II         [e-mail]
   Kathleen Nichols            [e-mail]
   Erik Nordmark               [e-mail]
   Dave Oran                   [e-mail]
   Yakov Rekhter               [e-mail]
   Bill Sommerfeld             [e-mail]
   Bert Wijnen                 [e-mail]
   Lixia Zhang                 [e-mail]

Author's Address

   Marijke Kaat
   SURFnet ExpertiseCentrum bv
   P.O. Box 19115
   3501 DC  Utrecht
   The Netherlands

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]






Kaat                         Informational                     [Page 15]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kaat                         Informational                     [Page 16]