Internet Engineering Task Force                         A.Durand
INTERNET-DRAFT                             SUN Microsystems,inc.
June, 24, 2004Network Working Group                                          F. Parent
Expires December 23, 2004
Internet-Draft                                                    Hexago

                  Requirements
Expires: April 1, 2005                                         A. Durand
                                                   SUN Microsystems,inc.
                                                               A. Baudot
                                                      France Telecom R&D
                                                                Oct 2004

                Goals for assisted tunneling
       <draft-ietf-v6ops-assisted-tunneling-requirements-00.txt> Registered Assisted Tunneling
          draft-ietf-v6ops-assisted-tunneling-requirements-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of RFC2026.
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 28, 2004. April 1, 2005.

Copyright Notice

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

Abstract

   This document defines requirements for a tunnel set-up protocol that
   could be used by an ISP to jumpstart its IPv6 offering to its
   customers by providing them IPv6 connectivity without having to
   upgrade its access network. through tunneling.

Table of Contents

   1.  Goal and Scope of the Document . . . . . . . . . . . . . . . .  3
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements for Simplicity  . . . . . . . . . . . . . . . . .  5
   4.  Protocol Requirements  . . . . . . . . . . . . . . . . . . . .  5
     4.1   Address and Prefix Delegation  . . . . . . . . . . . . . .  6
     4.2   Registration . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3   Authentication . . . . . . . . . . . . . . . . . . . . . .  6
     4.4   Confidentiality  . . . . . . . . . . . . . . . . . . . . .  7
     4.5   Service Discovery  . . . . . . . . . . . . . . . . . . . .  7
     4.6   NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  7
     4.7   Firewall Traversal . . . . . . . . . . . . . . . . . . . .  7
     4.8   Accounting . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  General Requirements . . . . . . . . . . . . . . . . . . . . .  8
     5.1   Scalability  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2   NAT Considerations . . . . . . . . . . . . . . . . . . . .  8
     5.3   Keep-alive . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4   Security . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.5   Traceability . . . . . . . . . . . . . . . . . . . . . . .  9
     5.6   Phase Out  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.7   Extensibility  . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Compatibility with other Transition Mechanisms . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Changes from version 00  . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14

1.  Goal and Scope of the Document

   The v6ops working group has worked on requirements and scenarios for
   IPv6 deployment by soliciting input from network operators.  This
   work has identified a need for an "assisted tunneling" mechanism.
   For example, an ISP starting its IPv6 offering to its customers
   without upgrading its access network to support IPv6 could use a
   "tunnel brokering solution" [ISP, section 5.1.] (section 5.1
   [I-D.ietf-v6ops-isp-scenarios-analysis]) a la [3053]. [RFC3053].  What has
   been identified as missing from that RFC document is a tunnel set-up
   protocol.

   In an ISP network, getting IPv6 connectivity to the customers
   involves upgrading the access network to support IPv6, which can take
   a long time and/or be costly.  A tunneled infrastructure can be used
   as a low cost migration path [ISP, section 5.1]. (section 5.1
   [I-D.ietf-v6ops-isp-scenarios-analysis]).

   With such an infrastructure, the ISP can connect its customers to its
   IPv6 network using its production IPv6 address space, thus
   facilitating migration towards native IPv6 deployment.  The IPv6
   deployment roadmap for connecting customers becomes:

      - may become:

   o  assisted tunneling infrastructure to early adopters,
      -

   o  native IPv6 to customers where economically justified,
      -

   o  native IPv6 to all customers.

   Note that, as

   Contrary to automatic tunneling mechanism where the IPv4 address is
   embedded inside the IPv6 address, no special format are imposed on
   the IPv6 address used in assisted tunneling.  Prefix delegation is
   also possible.  As the addressing space used during the transition to
   native remains the same same, the customer routing, filtering, accounting
   [ISP, section 5.]
   stay the same, and there is no need to maintain any kind of relay.

   "Assisted tunneling" is used in this document to described describe a
   transition mechanism where the parameters to configure a bi-
   directional
   bi-directional tunnel between an end-node (or leaf network) and a
   router in the core of an ISP are exchanged through a tunnel set-up
   protocol.  Although this exchange can be automated, this remains
   different from transition mechanisms like 6to4 that is fully automatic. 6to4, Teredo and
   ISATAP, on the other hand, practically require receiving information
   about the available prefix or address from the server/router,
   comparable to the most simple form of assisted tunneling. ISATAP.  In
   particular, the 'registered' mode defined in section 4 assisted tunneling enables explicit access control to the
   tunneled IPv6 connectivity, where the other transion mechanisms have
   to rely on other kinds of control (e.g., access control based on the
   IPv4 address).  Also, assisted tunneling protocol negotiate the
   tunnel parameters and does not depend on having the IPv4 address
   inside the IPv6 address, for example.

   This document analyze analyzes the requirements for such a tunnel set-up
   protocol.  The v6ops WG scenario and evaluation documents for
   deploying IPv6 within common network environments are used as input
   to this document.

2.  Applicability

   Assisted tunneling is applicable in different IPv6 transition
   scenarios.  The focus of this document is to define the requirements
   to apply this mechanism in the IPv4 ISP context making the following
   assumptions:

      -

   o  ISP is offering IPv6 connectivity to its customers initially using
      controlled tunneling infrastructure [ISP,
      [I-D.ietf-v6ops-isp-scenarios-analysis], section 5.1 Steps "Steps in
      Transitioning Customer Connection Networks]

      - The customer configuration may be diverse, and not necessarily
      predictable by the ISP. Networks"

   o  Provider network where deployment of IPv6 is done in a more
      controlled manner or when the provider cannot rely on IPv4 related
      authentication (e.g.  roaming customers, users not connected to
      ISP access network).  In such networks, ease of debugging,
      traceability, filtering and so on are important features.

   o  The customer configuration may be diverse, and not necessarily
      predictable by the ISP.  The protocol must be able to adapt to the
      following cases, for example by choosing the most optimal tunnel
      encapsulation depending on the presence of a NAT.
         -

      *  a single node,
         -

      *  a leaf network,
         -

      *  using a globally routable IPv4 address,
         -

      *  behind a NAT (customer or ISP owned),
         -

      *  using dynamic IPv4 address (internally or externally to the
         NAT)

   There are actually two cases where the IPv4 address of the customer
   tunnel end point can be dynamic, and both must be supported:

      -

   o  The device used as tunnel end point is using a dynamic IPv4
      address provided by the ISP.
      -

   o  The device used as tunnel end point is located behind a customer
      owned NAT box that is also acting as a local DHCP server.  In that
      case, the device IPv4 address may change after a reboot.

   Althought the main focus of this document is the ISP scenario,
   assisted tunneling is applicable in all the other scenarios:
   unmanaged, enterprise and 3GPP.

   In unmanaged networks, networks [RFC3904], assisted tunneling is applicable in
   the case A
   (a where a gateway which does not provide IPv6 at all) [UNMANAGED, section 3] all (section 3),
   and case C (a where a dual-stack gateway is connected to an IPv4-only ISP)
   [UNMANAGED, section 5].
   ISP (section 5).

   In 3GPP networks, the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted
   tunneling can be used in the context of
   dual stack UE to support remote users connecting to IPv6 nodes through a 3GPP the
   enterprise network that
   only supports IPv4 PDP contexts [3GPP, 3.1]. (section 7.5.2).

3.  Requirements for Simplicity

   The tunnel set-up protocol must be simple to implement and easy to
   deploy.  In particular, it should not depend on any complex, yet to
   be designed, protocols or infrastructure pieces.

   This protocol is a transition mechanism, thus does not need to be
   perfect.  As a matter of fact, making it perfect would be counter
   productive, at it would first delay its definition, then make its
   deployment more cumbersome and, last but not least, diminish the
   incentives to deploy native IPv6.

4.  Protocol Requirements

   Assisted tunneling can be provided in two different modes. "Non-
   registered" mode is a simple mode with no user registration,
   essentially deployed in a controlled and "authenticated" environment
   where the service is made available to all the IPv4 customers..  The
   "registered" mode is aimed at production deployment which requires
   the user to be authenticated. authenticated (such as using a shared secret mechanism
   Section 4.3).  This mode can be used to offer the tunneling service to roaming
   users or (users that are not directly connected to the ISP access
   network), and/or restrict the service to specific (authenticated) users. The tunnel set-up protocol must
   support both modes, however ISP deploying it may choose to only
   support one mode of operation.

   Assisted tunneling in the non-registered mode is defined for simple
   "plug & play" scenarios. In this mode, the tunnel establishment is
   triggered through the execution of

   From a simple program, without any pre-
   configuration or pre-registration user point of view, an initial registration process may be
   required from the end-user.

   The tunnel established is "anonymous" in a sense as the end-user does
   not register explicitly to the server. An ISP before using the protocol in service.  If the service provider uses an
   existing authentication database (Section 4.2), this mode step may not be offering
   needed.

   From an ISP point of view, this makes a free service clear link between a tunnel
   and doesn't wish a user (account).  It provides some means to require
   any form of registration. This free :

   o  meet requirements such as tracing (section 5.4
      [I-D.ietf-v6ops-isp-scenarios-analysis])

   o  control service can also be used provision to offer
   trial IPv6 service limited valid and/or identified or even
      selected users (section 5.2
      [I-D.ietf-v6ops-isp-scenarios-analysis])

   o  less prone to the ISP customers by relying on IPv4
   access control.

   The registered mode offers some extra features documented in latter
   sections. This mode is most valuable in a provider network where
   deployment denial of IPv6 service attacks: Since every tunnel
      request are authenticated, it is done in a more controlled manner or when difficult to request
      multiple tunnels to saturate the
   provider cannot rely on IPv4 related authentication (e.g. roaming
   customers). In such networks, ease of debugging, traceability,
   filtering and so on are important features.

4.1. service.

   o  stay in touch with users

4.1  Address and Prefix Delegation

   Assignment

   The protocol must support delegation of an IPv6 address (/128) to prefix.  The length
   of the end-node IPv6 prefix delegated must be
   supported in both modes.

   In non-registered mode, the IPv6 address is "transient" and may
   change, but configurable on the protocol SHOULD offer a mechanism to provide IPv6
   address stability in this mode (e.g. cookie mechanism). server.  The
   implementation of this mechanism MUST allow this feature to be turned
   off.  In registered mode, the
   protocol MUST must be able to support
   servers willing to offer stable IPv6 prefixes to the
   authenticated customers.

   The registered mode MUST support delegation

   Assignment of a single an IPv6 address or a
   whole prefix. The length of (/64) to the IPv6 prefix delegated MUST end-node must be
   configurable on
   supported.

   Since no special address format is imposed, the server. The non-registered mode MAY support
   prefix delegation.

   See section 5.9 for DNS considerations. ISP's address space
   can be used in the delegation (section 5.1
   [I-D.ietf-v6ops-isp-scenarios-analysis])

4.2  Registration

   The registration of credentials is external to the protocol. A  The
   user may require registration prior to using this service (through
   some web based service or other means).  Or service provider may use
   an existing authentication database to pre-register its users.

   In order to allow a service provider SHOULD be able to use its existing
   authentication
   database. If necessary, database, an implementation may provide hooks to
   facilitate integration with the ISP management infrastructure (e.g.
   RADIUS for AAA, billing). billing) ([I-D.ietf-v6ops-isp-scenarios-analysis],
   section 5.2).

   The protocol MAY may send information about registration procedure when a
   non-registered client requests registered mode (ex: URL to provider
   registration web page).

4.3.

4.3  Authentication

   Authentication can be used to control user has access to the IPv6
   services (section 5.2 [I-D.ietf-v6ops-isp-scenarios-analysis])

   The authentication mechanism supported should be compatible with
   standardized methods that are generally deployed.  In order to assure
   interoperability, at least one common authentication method MUST must be
   supported.  Other authentication MAY may be supported and should be
   negotiated between the client and server (e.g., SASL [2222]).

4.4. Service Discovery

   In order to offer "plug & play", the implementation SHOULD allow a
   mechanism to discover [RFC2222]).

4.4  Confidentiality

   Assisted tunneling can be used across networks which are not under
   the service provider control (e.g., roaming users).  The tunnel
   set-up protocol should allow protection of the authentication data
   Section 4.3.  This can be achieve by selecting an authentication
   mechanism that protects the credentials (e.g., digest-md5).

   Protecting the tunneled data (IPv6 in this case) should be possible.
   A possible usage scenario is when an enterprise's users is working
   off-site and tunneling to the enterprise network (7.5.2
   [I-D.ietf-v6ops-ent-analysis]).  Mechanisms do exist to make this
   possible, such as using IPsec over IPv6 [RFC2401].
   [I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is
   not analysed further.

4.5  Service Discovery

   In order to facilitate deployment, the implementation should allow a
   mechanism to discover the address of the server that will provide the
   tunnel connectivity.

   This discovery should be automatic when the protocol is used within
   an ISP network.

4.5.  There is no service discovery requirements when used
   outside the provider network (roaming users, 3rd party ISP).

   Tunnel end-point discovery mechanism work
   ([I-D.palet-v6ops-tun-auto-disc] may be applicable here.

4.6  NAT Traversal

   Tunneling through IPv4 NAT MUST must be supported.  The protocol should
   detect if an IPv4 NAT is in the path during the set-up phase (section
   5.3). (Section
   5.2).  If a NAT is present, an extra level of encapsulation is
   necessary to tunnel IPv6 across the NAT.  If no NAT is detected,
   IPv6-over-IPv4 tunneling (IP protocol 41) is enough.

4.6. usually enough (see also
   Section 4.7).

   NAT traversal is identified as a requirement in ISP scenarios
   (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged
   scanarios (section 7, Recommendation 1 [RFC3904])

4.7  Firewall Traversal

   Even if no NAT is in the tunnel path, there may be a firewall which
   prohibits IP protocol 41.  In such case, the tunnel encapsulation
   selection based on NAT detection (section 5.3) (Section 5.2) will select a tunnel
   that will not work.
   The

   In some cases, when the firewall is managed by the ISP or customer,
   it can be configured to allow IP protocol 41.  In such cases this may
   not be an issue (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis])

   But in order to be functional in any situation (e.g., firewall
   lacking feature), the assisted tunneling implementation MUST must allow a
   user to explicitly specify the desired tunnel encapsulation,
   regardless of the NAT detection process.

4.7.

4.8  Accounting

   The assisted tunneling should include tools for managing and
   monitoring the provided service.  Such information can be used to
   plan service capacity (traffic load) or billing information.

   Some useful accounting data are (not exhaustive list):
      -

   o  Tunnel counters (traffic in/out)
      -

   o  User utilization (tunnel uptime)
      -

   o  System logging (authentication failures, resource exhaustion,
      etc.)

   The interface used to provide such information can be through SNMP or
   an AAA protocol (e.g., RADIUS accounting).

4.8. Security Threat Analysis

   The non registered mode does not require explicit authentication of
   the user. Access control may be performed using e.g., IPv4 address.

5.  General Requirements

5.1  Scalability

   The mode essentially offer the IPv6 service to any of its IPv4
   customers.  Deployment of the service with this mode must be done
   carefully. In particular, security considerations tunnel set-up protocol must be taken into
   account.

   Non registered service scalable.  Typically, this
   protocol should be limited deployable in an ISP or enterprise network.

   A scalability requirement which is not related to the provider network,
   where access of the service can be controlled based on the IPv4
   address of the users (filtering).  If specific filtering is not in
   place in the ISP core network, anyone on the Internet could start
   using its tunneling infrastructure to get free IPv6 connectivity,
   transforming effectively the ISP into a IPv6 transit provider.

   If IPv4 address spoofing protocol itself
   is possible within the access network, a
   number of DoS attack can happen. For example, customer A can
   impersonate someone else's IPv4 address during the set-up phase and
   redirect a tunnel to that IP address. A then can, for example, start
   a high bandwidth multimedia flow across that tunnel and saturate its
   victim's up-link.

   But even with filtering in place, the non registered mode is
   vulnerable be able to denial of service attacks: a customer A behind a NAT
   can use a large number of (private) IPv4 addresses and request deploy multiple tunnels.That would quickly saturate servers inside the ISP tunnel server
   infrastructure. In order to minimize such attacks, IPv4 return
   routability checks could help blocking many DoS attack. Also, network.  To
   do so, the server implementation should offer a way to throttle and limit the
   number of tunnel established to the same (non-private) IPv4 address.

   In registered mode, the protocol must make sure that the tunnel is
   established to the legitimate would possibly need some load
   balancing feature and authenticated destination, again to
   avoid having someone establish a tunnel to a potential victim. IPv4
   return routability checks could help block possible DoS attacks.

5. General Requirements

5.1 Scalability

   The tunnel set-up protocol must be scalable. Typically, this protocol
   should be deployable in broadband ISP. an IPv6 IGP.

5.2 Service discovery requirements

   The discovery part of the tunnel set-up protocol should be as
   automatic as possible.

   The discovery mechanism must be able to scale for large ISP who cover
   different geographical areas and/or have a large number of customers.

   Customers may very well try to use this tunnel set-up protocol even
   if their ISP is not offering the service. In this case, without any
   previous action taken by their ISP, the discovery part of the tunnel
   set-up protocol must be able to abort immediately and display the
   customers a message explaining that no service is available.

5.3  NAT Considerations

   The assisted tunnel established by the protocol to be designed must
   work with the existing infrastructure, in particular it must be
   compatible with the various customer premise equipments available
   today.  This means that, in particular, the tunnels must be able to
   traverse one or many NAT boxes of different kinds.  There is no
   requirement for any particular NAT traversal technology.  However, as
   NAT traversal usually requires an extra layer of encapsulation, the
   tunnel set-up protocol SHOULD should be able to detect automatically the
   presence of one or more NAT boxes in the path.

   The implementation MUST implementation¬ must provide an option to to turn on extra
   encapsulation manually.  In order to assure interoperability, at
   least one common tunnel encapsulation type MUST must be supported.

5.4

5.3  Keep-alive

   When a tunnel has to cross a NAT box, the mapping established by the
   NAT must be preserved as long as the tunnel is in use.  This is
   usually achieved by sending keep alive messages across the tunnel.
   Also, the same keep alive messages can enable the ISP tunnel end
   point to perform garbage collection of its resources when tunnels are
   not in use anymore.  To enable those two functionalities, the tunnel
   set-up protocol must include the transmission of keep-alive messages.
   A client MAY may choose not to send those messages (for example on ISDN
   type links), but should then expect that the tunnel may be
   disconnected at any time by links).  In this case, the ISP and client should be prepared able to restart the
   set-up phase.

5.5 Latency in Set-up Phases

   In certain type of networks, keeping tunnels active all the time is
   not possible (e.g., limited number of tunnels on server) or simply
   too expensive (e.g., wireless environments where periodic
   transmission is expensive). In those environments, the protocol must handle a
   tunnel disconnect event and be able to set-up tunnels on demand of restart the IPv6 applications
   requiring external connectivity.

   The tunnel set-up protocol must then have a low enough latency phase to
   enable quasi-instant configuration.  Latency is usually a function of
   re-establish the number of packet exchanges required, so minimizing this parameter
   is important.

5.6 tunnel.

5.4  Security

   The tunnel set-up protocol must not introduce any new vulnerability
   to the network.

5.7  See security considerations in Section 7.

5.5  Traceability

   In some production environment, traceability is an important
   consideration.
   consideration ([I-D.ietf-v6ops-isp-scenarios-analysis], section 5.4).
   The tunnel set-up protocol must be instrumentable to enable the
   collection of usage data that can be used, for example, for capacity
   planning.

5.8

5.6  Phase Out

   This assisted tunneling mode is only a transition mechanism to enable
   ISP to jump start IPv6 service without requiring an immediate global
   upgrade of access networks and instead enabling a progressive roll
   out.  Once IPv6 is available natively in the access network
   connecting a customer, there is no reason to keep using tunnels.  So
   the implementation SHOULD should have a provision to enable the ISP to
   signal the user to use native IPv6 instead.

5.9

5.7  Extensibility

   The protocol MUST must be extensible to support tunnel encapsulation other
   than IPv6 over IPv4 and IPv6 over transport over IPv4.  In
   particular, encapsulation of IPv4 over IPv6 (section 7
   [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section
   6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined.

5.10 DNS considerations

   It should be possible to have the server side of the protocol
   automatically register the assigned IPv6 address in the DNS system
   (AAAA and PTR records) using the ISP name space. Nothing specific is
   required in the protocol to support this.  The details can be
   implementation specific.

   If stable prefix delegation is done, it is expected that the DNS
   delegation of the associated reverse DNS zone will be also stable and
   thus can be performed out of band, so there is no requirement to
   perform this delegation at the tunnel set-up time.

6.  Compatibility with other Transition Mechanisms

6.1 TSP

   The tunnel set-up protocol is not required to be compatible with TSP
   [TSP] or any particular implementation of the tunnel broker model
   [3053].
   existing transition mechanism.  Although, a great deal of experience
   can be drawn from the operation of tunnel brokers currently using the
   TSP protocol.

6.2 TEREDO

   There is a large number of Teredo clients already deployed, the
   tunnel set-up protocol should explore the avenue of providing a
   compatibility mode with Teredo, at least in the 'simple' mode
   described in section 4. However, it may turn out that supporting a
   compatibility mode with Teredo either requires to change the Teredo
   specifications and/or implement Teredo on the tunnel server side. In
   that case, it might be simpler to say that the compatibility mode
   should be manage on the client side instead of the server side, that
   is leave it up to the client to use either one of them.

6.3 ISATAP

   Similar considerations as Teredo, section 6.2, applies to Isatap.
   However, as Isatap can not work accross NAT, it is of much less
   interest in the framework of this document. [I-D.blanchet-v6ops-tunnelbroker-tsp].

7.  Security Considerations

   The establishment of a tunnel can be compared to Mobile IP
   technology, where traffic can be redirected to go from one place to
   another one.  So similar threats exists.  In particular, when a
   customer is asking for the set-up of a tunnel ending at IP address X,
   the ISP should check:
      -

   o  the customer is allowed to set-up this tunnel, i.e.  he "owns" the
      IPv6 prefix.
      -

   o  the customer is allowed to terminate the tunnel where he said he
      would, i.e.  he "owns" the IPv4 tunnel endpoint.

   The first check is simply an authentication issue.  The second may be more complex, but can be omitted if strict ingress filtering
   complex.  The protocol must make sure that the tunnel is in
   place in established
   to the access network, i.e. legitimate and authenticated destination.  IPv4 return
   routability checks could help this validation.  Also, when the customer user
   is effectively
   prevented within the ISP access network, strict ingress filtering can help
   prevent IPv4 address spoofing.

8.  Acknowlegements

   This draft has greatly benefited from substantial inputs by Pekka
   Savola.

   The following people provided feedback on this work (in no particular
   order): Carl Williams, Brian Carpenter, Christian Huitema, Jordi
   Palet, Jeroen Massar, Erik Nordmark, Soohong Daniel Park, Suresh
   Satapati, Fred Tremplin, Karim El-Malki, Tim Chown, Gert Doering,
   Soliman Hesham.

   Thanks to Mark Prior and Bernard Tuy for providing input from sending packet with an IPv4 source address he does not
   own.

   See section 4.4 for specific security consideration in the non-
   authenticated mode.

8. Acknowlegements ISP
   perspective to validate many requirements.

9. Author Addresses

   Alain Durand
   SUN Microsystems, Inc
   17 Network circle UMPK17-202
   Menlo Park, CA, 94025
   USA
   Mail: Alain.Durand@sun.com

   Florent Parent
   Hexago
   2875 boul. Laurier, bureau 300
   Sainte-Foy, QC  G1V 2M2
   Canada
   Mail: Florent.Parent@hexago.com

10.  References

9.1  Normative References

   [2119]

   [I-D.ietf-v6ops-ent-analysis]
              Bound, J., "IPv6 Enterprise Network Analysis",
              draft-ietf-v6ops-ent-analysis-00 (work in progress),
              September 2004.

   [I-D.ietf-v6ops-isp-scenarios-analysis]
              Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola,
              "Scenarios and Analysis for Introducing IPv6 into ISP
              Networks", draft-ietf-v6ops-isp-scenarios-analysis-03
              (work in progress), June 2004.

   [RFC2119]  Bradner, S., "Key Words words for Use use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [3053] A.

   [RFC3053]  Durand, P. A., Fasano, I. P., Guardini, I. and D. Lento., Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [ISP]  Lind, M., "Scenarios and Analysis for Introducing IPv6
          into ISP Networks",
          draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
          progress), February 2004.

   [UNMANAGED]

   [RFC3904]  Huitema, C., Austein, R., Satapati, S. and R. van der Pol,
              "Evaluation of IPv6 Transition Mechanisms for Unmanaged
              Networks", draft-ietf-v6ops-unmaneval-01 RFC 3904, September 2004.

9.2  Informative References

   [I-D.blanchet-v6ops-tunnelbroker-tsp]
              Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
              Tunnel Setup Protocol(TSP)",
              draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
              progress), February June 2004.

   [3GPP] J. Wiljakka, "Analysis on

   [I-D.huitema-v6ops-teredo]
              Huitema, C., "Teredo: Tunneling IPv6 Transition in 3GPP Networks",
          draft-ietf-v6ops-3gpp-analysis-09 over UDP through
              NATs", draft-huitema-v6ops-teredo-02 (work in progress), March
              June 2004.

11. Informative References

   [2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
          Mechanism", RFC 2831, May 2000.

   [2222] Myers, J., "Simple Authentication and Security Layer (SASL)",
          RFC2222, October 1997.

   [ISATAP]

   [I-D.ietf-ngtrans-isatap]
              Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", draft-ietf-ngtrans-isatap-21 draft-ietf-ngtrans-isatap-22 (work in
              progress), April May 2004.

   [TEREDO] Huitema, C., "Teredo:

   [I-D.palet-v6ops-tun-auto-disc]
              Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery
              for Tunneling IPv6 over UDP through
          NATs", draft-huitema-v6ops-teredo-01 Mechanisms",
              draft-palet-v6ops-tun-auto-disc-01 (work in progress),
          February
              June 2004.

   [TSP]  Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup
          Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00

   [I-D.tschofenig-v6ops-secure-tunnels]
              Tschofenig, H., "Using IPsec to Secure IPv6-over-IPv4
              Tunnels", draft-tschofenig-v6ops-secure-tunnels-01 (work
              in progress), February July 2004.

Appendix 1. Summary of

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the Protocol Requirements

   The non registered mode:
      - MUST be supported by
              Internet Protocol", RFC 2401, November 1998.

   [RFC2831]  Leach, P. and C. Newman, "Using Digest Authentication as a
              SASL Mechanism", RFC 2831, May 2000.

Authors' Addresses

   Florent Parent
   Hexago
   2875 boul. Laurier, suite 300
   Sainte-Foy, QC  G1V 2M2
   Canada

   EMail: Florent.Parent@hexago.com

   Alain Durand
   SUN Microsystems,inc.
   17 Network circle UMPK17-202
   Menlo Park, CA  94025
   USA

   EMail: Alain.Durand@sun.com

   Alain Baudot
   France Telecom R&D
   42, rue des coutures
   14066 Caen,
   France

   EMail: alain.baudot@rd.francetelecom.com

Appendix A.  Changes from version 00
   o  Non-registered mode removed (now covered in generic zero-conf
      tunneling draft).  Text throughout the protocol to be designed
      - RECOMMENDED to be implemented on client and servers/brokers
      - implementation SHOULD turn it on be default
      - implementation MUST allow it document changed to be turned off
      - MUST support single address assignment
      - SHOULD support stable IPv6 address
      - MAY support prefix delegation

   The registered mode:
      - MUST be supported by the protocol
      - RECOMMENDED reflect
      this.

   o

   o  Renamed title from "requirements" to be implemented on clients and servers/brokers
      - implementation SHOULD turn it off "goals"

   o  Changed imperatives to lowercase

   o  /128 endpoints replaced by default
      - implementation MUST allow it to be turned on
      - MUST support single address assignment
      - MUST support stable IPv6 address
      - MUST support prefix delegation, SHOULD be able /64

   o  Removed DNS considerations

   o  Added many references to turn off
   The registered part of other v6ops scenario documents

   o  Removed the appendix on protocol SHOULD not be too different from
   the non registered one, so as requirements summary

   o  Removed references to minimize code difference between the
   two modes

12. Full Copyright Statement 3GPP scenario

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 at
   ietf-ipr@ietf.org.

Disclaimer 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 assignees. Validity

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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