rfc2775.txt

RFC 的详细文档！

   5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model
           in which address translation is replaced by systematic
           encapsulation of all packets for wide-area transport.  This
           model has never been fully developed, although it is
           completely compatible with end-to-end addressing.

5.2.2 Exhaustion

   Suppose that no mechanism is created to recover addresses (except
   perhaps black or open market trading). Sites with large address
   blocks keep them.  All the scenarios of 5.2.1 appear but are
   insufficient.  Eventually the global address space is no longer
   adequate.  This is a nightmare scenario - NATs appear within the
   "global" address space, for example at ISP-ISP boundaries. It is
   unclear how a global routing system and a global DNS system can be
   maintained; the Internet is permanently fragmented.

5.3 Partial deployment of IPv6

   In this scenario, IPv6 is completely implemented but only deploys in
   certain segments of the network (e.g. in certain countries, or in
   certain areas of application such as mobile hand-held devices).
   Instead of being transitional in nature, some of the IPv6 transition
   techniques become permanent features of the landscape. Sometimes
   addresses are 32 bits, sometimes they are 128 bits. DNS lookups may
   return either or both. In the 32 bit world, the scenarios 5.2.1 and
   5.2.2 may occur. IPSEC can only deploy partially.

6. Conclusion

   None of the above scenarios is clean, simple and straightforward.
   Although the pure IPv6 scenario is the cleanest and simplest, it is
   not straightforward to reach it. The various scenarios without use of
   IPv6 are all messy and ultimately seem to lead to dead ends of one
   kind or another. Partial deployment of IPv6, which is a required step
   on the road to full deployment, is also messy but avoids the dead
   ends.

7. Security Considerations

   The loss of transparency is both a bug and a feature from the
   security viewpoint. To the extent that it prevents the end-to-end
   deployment of IPSEC, it damages security and creates vulnerabilities.
   For example, if a standard NAT box is in the path, then the best that
   can be done is to decrypt and re-encrypt IP traffic in the NAT.  The
   traffic will therefore be momentarily in clear text and potentially
   vulnerable. Furthermore, the NAT will possess many keys and will be a
   prime target of attack.  In environments where this is unacceptable,



Carpenter                    Informational                     [Page 13]

RFC 2775                 Internet Transparency             February 2000


   encryption must be applied above the network layer instead, of course
   with no usage whatever of IP addresses in data that is
   cryptographically protected. See section 4 for further discussion.

   In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end-
   to-end IPSEC would become possible, especially using the "distributed
   firewalls" model advocated in [Bellovin].

   The loss of transparency at the Intranet/Internet boundary may be
   considered a security feature, since it provides a well defined point
   at which to apply restrictions. This form of security is subject to
   the "crunchy outside, soft inside" risk, whereby any successful
   penetration of the boundary exposes the entire Intranet to trivial
   attack. The lack of end-to-end security applied within the Intranet
   also ignores insider threats.

   It should be noted that security applied above the transport level,
   such as SSL, SSH, PGP or S/MIME, is not affected by network layer
   transparency issues.

Acknowledgements

   This document and the related issues have been discussed extensively
   by the IAB. Special thanks to Steve Deering for a detailed review and
   to Noel Chiappa. Useful comments or ideas were also received from Rob
   Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer
   Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne,
   Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern
   Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning
   Schulzrinne, Bill Sommerfeld, and George Tsirtsis.

References

   [Bellovin]    Distributed Firewalls, S. Bellovin, available at
                 http://www.research.att.com/~smb/papers/distfw.pdf or
                 http://www.research.att.com/~smb/papers/distfw.ps (work
                 in progress).

   [Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti,
                 HarperCollins, 1999, p 208.

   [Saltzer]     End-To-End Arguments in System Design, J.H. Saltzer,
                 D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4,
                 November 1984, pp 277-288.

   [IEN 48]      Cerf, V., "The Catenet Model for Internetworking,"
                 Information Processing Techniques Office, Defense
                 Advanced Research Projects Agency, IEN 48, July 1978.



Carpenter                    Informational                     [Page 14]

RFC 2775                 Internet Transparency             February 2000


   [CATENET]     Pouzin, L., "A Proposal for Interconnecting Packet
                 Switching Networks," Proceedings of EUROCOMP, Brunel
                 University, May 1974, pp. 1023-36.

   [STD 7]       Postel, J., "Transmission Control Protocol", STD 7, RFC
                 793, September 1981.

   [RFC 1546]    Partridge, C., Mendez, T. and  W. Milliken,  "Host
                 Anycasting Service", RFC 1546, November 1993.

   [RFC 1597]    Rekhter, Y., Moskowitz, B., Karrenberg, D. and G. de
                 Groot, "Address Allocation for Private Internets", RFC
                 1597, March 1994.

   [RFC 1633]    Braden, R., Clark, D. and S. Shenker, "Integrated
                 Services in the Internet Architecture: an Overview",
                 RFC 1633, June 1994.

   [RFC 1889]    Schulzrinne, H., Casner, S., Frederick, R. and V.
                 Jacobson, "RTP: A Transport Protocol for Real-Time
                 Applications", RFC 1889, January 1996.

   [BCP 5]       Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
                 G.  and E. Lear, "Address Allocation for Private
                 Internets", BCP 5, RFC 1918, February 1996.

   [RFC 1928]    Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
                 and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
                 March 1996.

   [RFC 1958]    Carpenter, B., "Architectural Principles of the
                 Internet", RFC 1958, June 1996.

   [RFC 2018]    Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
                 Selective Acknowledgement Options", RFC 2018, October
                 1996.

   [RFC 2052]    Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
                 the location of services (DNS SRV)", RFC 2052, October
                 1996.

   [RFC 2101]    Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
                 Address Behaviour Today", RFC 2101, February 1997.

   [RFC 2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
                 Services", RFC 2210, September 1997.





Carpenter                    Informational                     [Page 15]

RFC 2775                 Internet Transparency             February 2000


   [RFC 2309]    Braden, B., Clark, D., Crowcroft, J., Davie, B.,
                 Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
                 Minshall, G., Partridge, C., Peterson, L.,
                 Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
                 Zhang, "Recommendations on Queue Management and
                 Congestion Avoidance in the Internet", RFC 2309, April
                 1998.

   [RFC 2326]    Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
                 Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC 2401]    Kent, S. and R. Atkinson, "Security Architecture for
                 the Internet Protocol", RFC 2401, November 1998.

   [RFC 2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                 and W. Weiss, "An Architecture for Differentiated
                 Service", RFC 2475, December 1998.

   [RFC 2581]    Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                 Control", RFC 2581, April 1999.

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

   [NAT-PROT]    Holdrege, M. and P. Srisuresh, "Protocol Complications
                 with the IP Network Address Translator (NAT)", Work in
                 Progress.

   [SECMECH]     Bellovin, S., "Security Mechanisms for the Internet",
                 Work in Progress.

   [RSIP]        Lo, J., Borella, M. and D. Grabelsky, "Realm Specific
                 IP: A Framework", Work in Progress.

   [HIP]         Moskowitz, R., "The Host Identity Payload", Work in
                 Progress.















Carpenter                    Informational                     [Page 16]

RFC 2775                 Internet Transparency             February 2000


Author's Address

   Brian E. Carpenter
   IBM
   c/o iCAIR
   Suite 150
   1890 Maple Avenue
   Evanston, IL 60201
   USA

   EMail: [e-mail]








































Carpenter                    Informational                     [Page 17]

RFC 2775                 Internet Transparency             February 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.



















Carpenter                    Informational                     [Page 18]