[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: April 24, 2005                                      Consulintel
                                                        October 24, 2004



          IPv6 Tunnel End-point Automatic Discovery Mechanism
            draft-palet-v6ops-solution-tun-auto-disc-01.txt


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of 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
   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.


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


   This Internet-Draft will expire on April 24, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   Tunneling is commonly used by several IPv6 transition mechanisms.  To
   be able to automate setting up tunnels, one critical component is a
   solution to automatically discover the tunnel end-point (TEP) for the
   transition mechanism.


   This memo proposes a solution for discovering the IPv6 TEP in a
   simple an efficient way.




Palet & Diaz             Expires April 24, 2005                 [Page 1]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview and Rationale . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Implementation  . . . . . . . . . . . . . . . . . . .  4
     3.1   SRV RR . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2   A/CNAME RR for Unicast . . . . . . . . . . . . . . . . . .  5
     3.3   Shared Anycast . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Solution Description . . . . . . . . . . . . . . . . . . . . .  6
   5.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1   ISP offering transition service(s) with SRV support on
           its DNS server . . . . . . . . . . . . . . . . . . . . . .  8
     5.2   ISP offering transition service(s) without SRV support
           on its DNS server  . . . . . . . . . . . . . . . . . . . .  9
     5.3   ISP offering transition service(s) by means of third
           parties  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4   ISP offering transition service(s) only to own
           customers  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.5   ISP offering transition service(s) to external users . . . 10
     5.6   ISP does not offer transition service at all . . . . . . . 10
     5.7   Increased Scalability and Automation . . . . . . . . . . . 11
   6.  Alternative DHCP-based Solution  . . . . . . . . . . . . . . . 11
   7.  Service Names for Transition Mechanisms  . . . . . . . . . . . 12
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 12
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 13
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15




















Palet & Diaz             Expires April 24, 2005                 [Page 2]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



1.  Introduction


   During the IPv6 transition stage, it is foreseen that different
   transition mechanisms are used.  Most of them are tunnel-based and it
   is critically important to ensure that the setup of the IPv6
   connectivity is simple, so that it can be done also by non-technical
   users, or even completely transparently, without the user recognizing
   that IPv6 connectivity has been obtained.


   A critical piece in the automated set-up is discovering the tunnel
   end-point (TEP), also known as tunnel-server (TS), for the transition
   mechanism that will be used by the client (or rather, their operating
   system).  Note that the tunnel end-point at the server side (TS)
   typically also needs to have a mean to configure the client (tunnel)
   end-point, but that is assumed to be transition mechanism specific,
   and beyond the scope of this memo.


   In this memo an elegant and simple solution for the TEP
   auto-discovery is described, which fits in all the scenarios analyzed
   in [1].  The solution offers the following features:


   1.  It is simple.


   2.  It can be easily deployed.


   3.  It is scalable.


   4.  It is topologically correct: Provides the nearest TEP to the user
       in terms of IP hops.


   5.  Applies to all the existing transition mechanisms (and possibly
       future ones), without any need for modifying them.


   6.  It is based on a combination of DNS and anycast (shared unicast
       according to some terminology [2]) approach.


   7.  It offers certain degree of redundancy: It would work if either
       the DNS or the anycast support fail.


   8.  It offers load balancing capability in order to share all the
       known TEPs among all the clients willing to get IPv6 connectivity
       through them.


   9.  It is fast and does not add significant overhead into the
       transition mechanism setup process.







Palet & Diaz             Expires April 24, 2005                 [Page 3]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



2.  Overview and Rationale


   As pointed out at [1], the DNS is globally deployed and easy to use.
   By means of prefixing the search path one can look up for a specific
   service that is a specific TEP or transition mechanism server [3].


   On the other hand, shared anycast is also a very useful approach
   since it can globally identify a specific service (TEP or transition
   mechanism).  It is even easier and simpler than the DNS approach.
   However anycast routes not always are well configured and stable, so
   connection with the server belonging to an anycast group might not be
   always possible, which means that is not necessarily the most
   topologically correct.  Moreover, consecutive datagrams sent from the
   same host towards the same anycast address have no guarantee at all
   that they are going to be delivered to the same anycast node.


   For this reason, the anycast approach is only considered as a
   complementary backup solution when prefixing the search path on DNS
   has negative replies.


   In addition, both approaches offer the possibility of pointing
   directly to the TEP or alternatively to an intermediate node (i.e.
   Tunnel Broker, TB) where to start the signaling handshake for setting
   up the tunnel.


   The idea that the auto-discovery solution exploits is that the client
   willing to use a transition mechanism will first make one or several
   DNS queries.  The DNS will redirect to a TEP (or alternatively a TB
   if more sophistication is required) located within the ISP or a third
   party (other near ISP, roaming TEP service, etc.), if possible.
   Alternatively, the DNS could also reply with an anycast address for
   the searched TEP.


   The solution consequently makes use of existing protocols, not
   requiring modifications or any new protocol.


   Details of how the DNS queries are made and how the prefix search
   path is used are presented below.


3.  Solution Implementation


   The solution requires the implementation, at the ISP willing to offer
   the service, of one or several new configurations of existing
   services (namely DNS and anycast), as explained in the following
   sub-sections.


   Note that the solution will work with just of those configurations,
   but all them together provide a more complete approach, which is




Palet & Diaz             Expires April 24, 2005                 [Page 4]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   better explained looking at the Case Studies section.


   For the client is required that the three are actually implemented,
   in the sequence below introduced, so the client will always succed,
   regardless of what the ISP to which they are connected actually has
   configured.


3.1  SRV RR


   The DNS server of the ISP deploying a specific transition mechanism
   should use SRV RR to announce the transition mechanism service.


   According to [4] the SRV RR for a specific transition mechanism
   should have the following format:


   _Service._Proto.Name TTL Class SRV Priority Weight Port Target


   Please refer to [4] for a detailed explanation of each field in DNS
   SRV RRs.


   The service name for the auto-discovery purpose should be
   standardized for each transition mechanism.


   _transition-mechanism_srv._protocol.ispname.com


   (assuming that the domain name of a ISP is ispname.com).


   For example the records for 6in4, tsp, teredo, isatap and 6to4 would
   result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com,
   _teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com,
   _6to4_srv._ipv4.ispname.com, etc.


   Some illustrative examples of specific transition mechanisms
   configured as SRV RRs in the DNS server are:


   _6to4_srv._ipv4   SRV  0  1  10000  server1.ispname.com
   _tsp_srv._tcp     SRV  1  2  80     server2.ispname.com
   _teredo_srv._udp  SRV  2  1  3456   server3.ispname.com



3.2  A/CNAME RR for Unicast


   A standardized A/CNAME RR for each supported transition mechanisms
   within the domain of the ISP, using the same nomenclature as
   introduced in the previous section, in the form:


   _transition-mechanism_srv._protocol.ispname.com





Palet & Diaz             Expires April 24, 2005                 [Page 5]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   (assuming that the domain name of a ISP is ispname.com).


   For example the records for 6in4, tsp, teredo, isatap and 6to4 would
   result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com,
   _teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com,
   _6to4_srv._ipv4.ispname.com, etc.


   Note: The use of the underscore character minimizes the probability
   of conflict with DNS names already defined.


3.3  Shared Anycast


   Each transition mechanism could have assigned and implemented a
   shared anycast address, such as in the case of the 6to4 transition
   mechanism [5].


   The anycast prefix/address for each transition mechanism is listed
   below (TBD by IANA):


   Transition Mechanism    Anycast Prefix/Adddress


   TBD


4.  Solution Description


   The ideal situation is to implement all the points indicated in the
   previous section.  Under that scenario, the auto-discovery mechanism
   would offer the best functionality and all the features described
   above.


   However, it is not mandatory that all them are fulfilled in order to
   provide a functional auto-discovery mechanism, but at least one must
   be implemented.  In this way the auto-discovery mechanism will work
   during all the deployment stages (auto-discovery not yet
   standardized, auto-discovery already standardized but less deployed,
   auto-discovery highly deployed).  As many are implemented, more
   functional the auto-discovery mechanism is.


   When looking for a specific TEP within the ISP the user belongs to,
   the first step is always the same because the user does not know (and
   neither has to know) which is the transition mechanism deployment
   status within its ISP, so the application/stack always query firstly
   for a DNS SRV RR to its ISP DNS server.


   To do that, the ISP's domain name is essential for prefixing the DNS
   search path, so the client (or rather the operating system) firstly
   learns the domain name of the ISP.  There are several ways to do it,
   but in general it will be learned by making NS RR queries to the DNS.




Palet & Diaz             Expires April 24, 2005                 [Page 6]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   The ISP's domain name will be the base string for the prefixing of
   the DNS search path.  Once the client has discovered it, a first
   attempt to find the TEP of the specific transition mechanism is made
   by building a SRV RR query (i.e.  _tsp_srv._tcp.ispname.com) to the
   DNS server belonging to the ISP.


   Next it is shown an example of how the DNS SRV RRs would be used to
   query the ISP DNS server.  To discover the specific TEP within the
   ISP domain (say, ispname.com), the client (rather the operating
   system) makes a DNS query [6][7] for
   QNAME=_teredo_srv._udp.ispname.com, QCLASS=IN, and QTYPE=SRV


   If the DNS server matches the query, it returns the proper reply with
   all the possible targets defined for that query, so the client will
   receive a list of DNS SRV RRs in a DNS reply, which gives all the
   teredo TEPs in the ISP domain ispname.com, such as:


       ;;                             Priority Weight Port     Target
   _teredo_srv._udp.ispname.com IN SRV   0        0   4500  tep1.ispname.com
   _teredo_srv._udp.ispname.com IN SRV   0        1   4000  tep2.ispname.com
   _teredo_srv._udp.ispname.com IN SRV   1        0   5000  host.other_ispname.com
   _teredo_srv._udp.ispname.com IN SRV   2        0   5000  tepnode.other-domain.com


   When there are more than one TEP, all of them could be assigned with
   different priority and weight parameters in order to do load
   balancing.  Even some of them could be located outside the ISP.  The
   client will try all the obtained TEP according to the SRV RR
   information (priority and weight) until it gets connected to one of
   them.  At this point the auto-discovery function ends.


   If no DNS SRV RR reply is obtained (either because the DNS
   administrator did not created DNS SRV RR entries for the requested
   transition mechanism or either the DNS server or client resolver has
   not SRV RR support), then an A/CNAME query is built by the client by
   appending the standardized service name to the ISP domain name in
   accordance with the what has been indicated at the "A/CNAME RR for
   Anycast" section (i.e.  _teredo_srv._udp.ispname.com).


   Follows an example of how the DNS A/CNAME RRs would be used to query
   the ISP DNS server.  To discover the specific TEP within the ISP's
   domain (say, ispname.com), the client (rather the operating system)
   makes a DNS query [6][7] for QNAME=_teredo_srv._udp.ispname.com,
   QCLASS=IN, and QTYPE=A or QTYPE=CNAME.


   If there is a TEP deployed within the ISP (or a third party one),
   then the DNS reply redirects the client to it and the auto-discovery
   function ends in this point.





Palet & Diaz             Expires April 24, 2005                 [Page 7]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   Finally if there is not a valid A/CNAME RR matching the client query,
   then the client will directly refer to the standardized "Shared
   Anycast" address regarding the searched TEP.  This allows the
   provision of the service, for free, by third parties, when the own
   ISP does not provide it (i.e.  nomadic users), and doesn't require
   any configuration in the ISP infrastructure.  In this point the
   auto-discovery function ends.


   Although by using the standardized shared anycast address the client
   always will contact to one TEP (assuming BGP routes are well
   configured, it could be within the own-ISP infrastructure), the use
   of the shared anycast address is preferred as the last option after
   DNS SRV RR and DNS A/CNAME RR fails.  This is because by means of DNS
   RR, administrators will always configure nearest TEP hosts (within
   the client ISP) for own-customers and load balancing can be better
   done (in case of DNS SRV RR).  Consequently, the shared anycast
   option is used only as backup solution and also to provide service to
   external users.


5.  Case Studies


   In order to clarify the behavior of this solution, some case studies
   are presented below.  It also shows how flexible is the solution and
   how it can be used depending on the deployment stage at the ISP or
   even its willingness to provide service only to own-customers or
   external ones.


5.1  ISP offering transition service(s) with SRV support on its DNS
    server


   Many ISPs could offer IPv6 transition service(s) by deploying one or
   several TEPs in its own infrastructure.  It is also possible that
   ISPs are interested to offer IPv6 transition mechanisms by means of
   third party agreements or even through well known and convenient
   nearby TEPs or which are free of charge.


   In this case, the ISP could setup the DNS server with SRV RRs with
   the "Target" parameter pointing be the TEPs deployed either inside
   that ISP or the third party one.  Several SRV RRs can be configured
   for each specific transition mechanism service available.


   If the ISP DNS server has SRV RRs matching the client query, then it
   will reply with all the SRV records matching that query.


   The "Priority" parameter of the SRV record could be used to
   prioritize the own TEPs.  If the higher priority TEP does not
   respond, the client will attempt the next one, and so on.





Palet & Diaz             Expires April 24, 2005                 [Page 8]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   Some load balancing among TEPs is possible by using the "Weight"
   field as suggested by [4].


   The standardized shared anycast address for each specific mechanism
   TEP could be added as target to the DNS SRV RR.  In that case it
   should have the lowest priority in order to redirect the client
   always to local TEP as a first option.


5.2  ISP offering transition service(s) without SRV support on its DNS
    server


   Even if unusual is possible that the DNS servers doesn't support SRV
   RR or that the ISP does not wish to configure SRV RR, for whatever
   reason.  Even do, the ISP may be interested in offering transition
   services to its customers, and several TEPs, for different transition
   mechanism will be deployed.


   In this case the best solution for announcing local TEPs within the
   ISP is by means of DNS A/CNAME RR.  Clients will always try to get a
   valid DNS SRV RR reply, but once it fails a valid DNS SRV A/CNAME
   will be queried.


   However, in this case the load-balancing feature is somehow limited,
   based only on round-robin RR techniques, according to the
   capabilities of the DNS server.


5.3  ISP offering transition service(s) by means of third parties


   In initial early deployment stages, it is possible that ISPs can not
   offer this service by themselves (either because business
   considerations or because lack of resources, knowledge, etc.)..
   However, they can agree with third parties for offering the service
   to theirs customers.  They can even facilitate their customers the
   auto-discovery of free TEPs located in other domains.


   In this case, they can proceed as already indicated in the previous
   cases which mention how a third party TEP can be announced by the
   DNS.


5.4  ISP offering transition service(s) only to own customers


   The solution indicated in the previous cases is available to any
   client that use the a DNS server which has been configured to
   advertise the TEPs, even to external users (non-customers) using that
   DNS server.


   If an ISP wants to ensure that only own-customers automatically
   discover the advertised TEPs, it could configure the DNS server(s) to




Palet & Diaz             Expires April 24, 2005                 [Page 9]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   send different replies (views), either DNS SRV or A/CNAME RRs, based
   on the IP address of the incoming queries.


   According to this, a SRV or A/CNAME RR query coming from a customer
   (the IP will belong to the ISP allocations), could have a reply
   containing the information regarding the requested TEPs deployed
   within the ISP, the TEPs deployed by associated third parties, the
   anycast address of the TEP or any combination of these options.  On
   the other hand, if the same query is coming from outside the ISP
   network, then the DNS reply could only contain the TEPs deployed by
   associated third parties or the anycast TEP or nothing.


   Unlimited configurations are possible.  This view functionality
   strongly depends on the DNS server implementation that is being used
   within the ISP.


   Similarly the anycast advertising can be limited by proper
   configuration of BGP, in order to avoid the TEPs being automatically
   discovered by non-customers.


   Avoiding the automatic discovery of the TEPs (by means of either DNS
   or anycast) will actually not avoid them being used, but only its
   auto-discovery, because they can be manually discovered/configured by
   the users.  But is also possible to limit the access to the TEPs by
   means of filtering options, for example, to avoid any communication
   being initiated to them by IP addresses not belonging to that ISP.


5.5  ISP offering transition service(s) to external users


   If an ISP is willing to offer transition service(s) to external
   customers, the best option for facilitating the auto-discovery of the
   TEPs, is the configuration of the "Shared Anycast" as already
   previously described, for each of the transition mechanism supported.


5.6  ISP does not offer transition service at all


   In case an ISP does not deploy any transition mechanisms, and wish no
   support their customers for using external services, they may
   auto-discover available TEPs as indicated in the previous case.


   In this case, the client willing to use a specific TEP firstly will
   try to get a valid DNS SRV RR reply.  However it will fail because
   the ISP DNS server will not have any entry for it.  Once it fails, a
   DNS SRV A/CNAME will be also queried, which also will fail due to the
   same reason.  This is the expected behavior of the auto-discovery
   mechanism and the reason for the Shared Anycast option.  So, after
   both types of DNS queries have failed, client will try the
   standardized shared anycast address to get connected to the required




Palet & Diaz             Expires April 24, 2005                [Page 10]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



   TEP, which will be located out the ISP network.


   The only requirement for this to actually work, is that the ISP
   routes to the standardized shared anycast addresses have to be
   allowed within the ISP, so the foreign TEPs are reachable.  This is
   currently a the normal situation, fulfilled by most of the ISPs, as
   proven with the 6to4 anycast address [5].


5.7  Increased Scalability and Automation


   In order to provide a more automated service, or even increased
   scalability, a "Tunnel End-Broker" (TEB) service could be defined and
   deployed.


   The basic idea is to have a broker server (for instance
   _teb_srv._ipv4.ispname.com) that will add more sophistication to the
   system, but also increase the complexity of the implementation.  In
   this case, the transition mechanism will require a signaling higher
   layer, that could also provide authenticated transition services and
   enhanced roaming features.


   In this scenario, the client will always try first _teb_srv._ipv4
   (SRV, A/CNAME) or the corresponding anycast address, automatically
   discover the adequate transition mechanism and the correct TEP, and
   then pass the information to the transition mechanism itself to
   establish the tunnel.


   At this way, the auto-discovery may be complemented with the
   auto-transition as described in [8].


6.  Alternative DHCP-based Solution


   Although the use of DHCP options to provide the TEP [9] has some
   drawbacks, as analyzed in [1], it is proven that in some scenarios it
   is useful, so it could be considered as a backup solution under
   certain scenarios when communication with the specific TEP is not
   possible due to whatever reason.


   Scenarios where DHCP applies are typically within enterprise
   networks, and users could use the information provided by the DHCP
   server to contact a 6in4 TEP.


   In this way, DHCP is an alternative basically when the enterprise
   wish to ensure a managed transition related to the DHCP usage,
   instead of the ISP provision, and has no control over DNS and/or BGP
   configurations.






Palet & Diaz             Expires April 24, 2005                [Page 11]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



7.  Service Names for Transition Mechanisms


   This section list the transition mechanisms and the service names to
   be used:


   Transition Mechanism    Service Name
   6in4 (RFCxxxx)          6in4
   tsp (RFCxxxx)           tsp
   teredo (RFCxxxx)        teredo
   isatap (RFCxxxx)        isatap
   6to4 (RFCxxxx)          6to4
        ...                                                                             ...


   TBD.


8.  Conclusions


   In order to take advantage of the auto-discovery solution, the
   configuration scripts of the transition mechanisms should use the DNS
   RRs introduced in this document, always preferring SRV versus
   A/CNAME.  Anycast could be used as the last option.


   DNS views and filtering can be configured by ISPs to avoid the
   auto-discovery working for non-customers and to avoid the access to
   the TEPs by clients using IP addresses not belonging to the ISP.


   Those ISPs willing to provide service to external users, should
   properly configure Shared Anycast.


   Can/should we use this document also for auto-discovering IPv4 in
   IPv6 tunnels ? TBD.


9.  Security Considerations


   TBD.


10.  IANA Considerations


   Can we assign an anycast address for each transition mechanism ? TBD.


11.  Acknowledgements


   The authors would like to acknowledge inputs from Alvaro Vives, Pekka
   Savola, Antonio Skarmeta and the European Commission support in the
   co-funding of the Euro6IX project, where this work is being
   developed.






Palet & Diaz             Expires April 24, 2005                [Page 12]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



12.  References


12.1  Normative References


12.2  Informative References


   [1]  Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for
        Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work
        in progress), June 2004.


   [2]  Hagino, J. and K. Ettican, "An analysis of IPv6 anycast",
        draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress),
        June 2003.


   [3]  Faltstrom, P. and R. Austein, "Design Choices When Expanding
        DNS", draft-iab-dns-choices-00 (work in progress), October 2004.


   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.


   [5]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
        3068, June 2001.


   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.


   [7]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.


   [8]  Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition
        Algorithm", draft-palet-v6ops-auto-trans-01 (work in progress),
        July 2004.


   [9]  Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4
        Tunnels", draft-daniel-dhc-ipv6in4-opt-05 (work in progress),
        October 2004.















Palet & Diaz             Expires April 24, 2005                [Page 13]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



Authors' Addresses


   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain


   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: jordi.palet@consulintel.es



   Miguel Angel Diaz Fernandez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain


   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: miguelangel.diaz@consulintel.es






























Palet & Diaz             Expires April 24, 2005                [Page 14]

Internet-Draft    IPv6 Tunnel End-point Auto-Discovery Mechanism        October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made 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 implementers or users of this
   specification can be obtained from the IETF 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 that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein 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 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.





Palet & Diaz             Expires April 24, 2005                [Page 15]

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/