rfc3053.txt

最新的RFC

   entities in the Tunnel Broker architecture is outside of the scope of
   the present framework document.  Nevertheless, in the reminder of
   this section some viable technical alternatives to support client-TB,
   TB-TS and TB-DNS interactions are briefly described in order to help
   future implementation efforts or standardization initiatives.

   The interaction between the TB and the user could be based on http.
   For example the user could provide the relevant configuration
   information (i.e., the IPv4 address of the client side of the tunnel,
   etc.) by just filling up some forms on a Web server running on the
   TB.  As a result the server could respond with an html page stating
   that the server end-point of the tunnel is configured and displaying
   all the relevant tunnel information.

   After that, the most trivial approach would be to leave the user to
   configure the client end-point of the tunnel on his own.  However, it
   should be highly valuable to support a mechanism to automate this
   procedure as much as possible.

   Several options may be envisaged to assist the Tunnel Broker user in
   the configuration of his dual-stack equipment.  The simplest option
   is that the TB could just prepare personalized activation and de-
   activation scripts to be run off-line on the client machine to
   achieve easy set-up of the client side tunnel end-point.  This



Durand, et al.               Informational                      [Page 7]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   solution is clearly the easiest to implement and operate in that it
   does not require any software extension on the client machine.
   However, it raises several security concerns because it may be
   difficult for the user to verify that previously downloaded scripts
   do not perform illegal or dangerous operations once executed.

   The above described security issues could be elegantly overcome by
   defining a new MIME (Multipurpose Internet Mail Extension) content-
   type (e.g., application/tunnel) [4,5] to be used by the TB to deliver
   the tunnel parameters to the client.  In this case, there must be a
   dedicated agent running on the client to process this information and
   actually set-up the tunnel end-point on behalf of the user.  This is
   a very attractive approach which is worth envisaging.  In particular,
   the definition of the new content-type might be the subject of a
   future ad-hoc document.

   Several options are available also to achieve proper interaction
   between the broker and the Tunnel Servers.  For example a set of
   simple RSH commands over IPsec could be used for this purpose.
   Another alternative could be to use SNMP or to adopt any other
   network management solution.

   Finally, the Dynamic DNS Update protocol [6] should be used for
   automatic DNS update (i.e., to add or delete AAAA, A6 and PTR records
   from the DNS zone reserved for Tunnel Broker users) controlled by the
   TB.  A simple alternative would be for the TB to use a small set of
   RSH commands to dynamically update the direct and inverse databases
   on the authoritative DNS server for the Tunnel Broker users zone
   (e.g.  broker.isp-name.com).

2.7 Open issues

   Real usage of the TB service may require the introduction of
   accounting/billing functions.

3. Known limitations

   This mechanism may not work if the user is using private IPv4
   addresses behind a NAT box.

4. Use of the tunnel broker concept in other areas

   The Tunnel Broker approach might be efficiently exploited also to
   automatically set-up and manage any other kind of tunnel, such as a
   multicast tunnel (e.g., used to interconnect multicast islands within
   the unicast Internet) or an IPsec tunnel.





Durand, et al.               Informational                      [Page 8]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   Moreover, the idea of deploying a dedicated access-control server,
   like the TB, to securely authorize and assist users that want to gain
   access to an IPv6 network might prove useful also to enhance other
   transition mechanisms.  For example it would be possible to exploit a
   similar approach within the 6to4 model to achieve easy relay
   discovery.  This would make life easier for early 6to4 adopters but
   would also allow the ISPs to better control the usage of their 6to4
   relay facilities (e.g., setting up appropriate usage policies).

5. Security Considerations

   All the interactions between the functional elements of the proposed
   architecture need to be secured:

      -  the interaction between the client and TB;

      -  the interaction between the TB and the Tunnel Server;

      -  the interaction between the TB and the DNS.

   The security techniques adopted for each of the required interactions
   is dependent on the implementation choices.

   For the client-TB interaction, the usage of http allows the
   exploitation of widely adopted security features, such as SSL (Secure
   Socket Layer) [7], to encrypt data sent to and downloaded from the
   web server.  This also makes it possible to rely on a simple
   "username" and "password" authentication procedure and on existing
   AAA facilities (e.g., RADIUS) to enforce access-control.

   For the TB-TS interaction secure SNMP could be adopted [8,9,10].  If
   the dynamic DNS update procedure is used for the TB-DNS interaction,
   the security issues are the same as discussed in [11].  Otherwise, if
   a simpler approach based on RSH commands is used, standard IPsec
   mechanisms can be applied [12].

   Furthermore, if the configuration of the client is achieved running
   scripts provided by the TB, these scripts must be executed with
   enough privileges to manage network interfaces, such as an
   administrator/root role.  This can be dangerous and should be
   considered only for early implementations of the Tunnel Broker
   approach.  Transferring tunnel configuration parameters in a MIME
   type over https is a more secure approach.

   In addition a loss of confidentiality may occur whenever a dial-up
   user disconnects from the Internet without tearing down the tunnel
   previously established through the TB.  In fact, the TS keeps
   tunneling the IPv6 traffic addressed to that user to his old IPv4



Durand, et al.               Informational                      [Page 9]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   address regardless of the fact that in the meanwhile that IPv4
   address could have been dynamically assigned to another subscriber of
   the same dial-up ISP.  This problem could be solved by implementing
   on every tunnel the keep-alive mechanism outlined in section 2.5 thus
   allowing the TB to immediately stop IPv6 traffic forwarding towards
   disconnected users.

   Finally TBs must implement protections against denial of service
   attacks which may occur whenever a malicious user exhausts all the
   resources available on the tunnels server by asking for a lot of
   tunnels to be established altogether.  A possible protection against
   this attack could be achieved by administratively limiting the number
   of tunnels that a single user is allowed to set-up at the same time.

6. Acknowledgments

   Some of the ideas refining the tunnel broker model came from
   discussion with Perry Metzger and Marc Blanchet.

7. References

   [1]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
        Hosts and Routers", RFC 1933, April 1996.

   [2]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
        Domains without Explicit Tunnels", RFC 2529, March 1999.

   [3]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
        Clouds without Explicit Tunnels", Work in Progress.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies,
        RFC 2045, November 1996.

   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

   [6]  Vixie, P., Editor, Thomson, T., Rekhter, Y. and J. Bound,
        "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC
        2136, April 1997.

   [7]  Guttman, E., Leong, L. and G. Malkin, "Users' Security
        Handbook", FYI 34, RFC 2504, February 1999.

   [8]  Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for
        Describing SNMP Management Frameworks", RFC 2571, April 1999.




Durand, et al.               Informational                     [Page 10]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   [9]  Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", RFC 2574, April 1999.

   [10] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
        Control Model (VACM) for the Simple Network Management Protocol
        (SNMP)", RFC 2575, April 1999.

   [11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
        2137, April 1997.

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






































Durand, et al.               Informational                     [Page 11]

RFC 3053                   IPv6 Tunnel Broker               January 2001


8. Authors' Addresses

   Alain Durand
   SUN Microsystems, Inc
   901 San Antonio Road
   MPK17-202
   Palo Alto, CA 94303-4900
   USA

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


   Paolo Fasano S.p.A.
   CSELT S.p.A.
   Switching and Network Services - Networking
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy

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


   Ivano Guardini
   CSELT S.p.A.
   Switching and Network Services - Networking
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy

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


   Domenico Lento
   TIM
   Business Unit Project Management
   via Orsini, 9
   90100 Palermo
   Italy

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







Durand, et al.               Informational                     [Page 12]

RFC 3053                   IPv6 Tunnel Broker               January 2001


9. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Durand, et al.               Informational                     [Page 13]