draft-ietf-ipv6-dns-discovery-07.txt

bind-3.2.

   In this scenario, the home/small office network is connected to the
   ISP router (PE) via an edge router (CPE).

                                            -------------
                                           /            |
            --------           -----      /             |
            |ISP PE|           |CPE|     /    Customer  |
            |      |===========|   |====<     site      |
            |      |           |   |     \              |
            --------           -----      \             |
                                           \            |
                                            -------------


   The customer router CPE could be configured on its internal interface
   with one of the reserved site local addresses and listen for DNS
   queries. It would be configured to use one (or several) of the well
   known site local unicast addresses within the ISP's site to send its
   own queries to.  It would act as a DNS forwarder, forwarding queries
   received on its internal interface to the ISP's recursive DNS server.

                                                   -------------
                                                  /            |
        ----------           --------------      /             |
        |ISP     |           |         CPE|     /    Customer  |
        |DNS     |===========|         DNS|====<     site      |
        |server  |    <------|---forwarder|-----\----          |
        ----------           --------------      \             |
                                                  \            |
                                                   -------------

       In this configuration, the CPE is acting as a multi-sited router.


6.4 DNS forwarder with DHCPv6 interactions

   In this variant scenario, DHCPv6 is be used between the PE and CPE to
   do prefix delegation [DELEG] and recursive DNS server discovery.

                                                     -------------
                                                    /            |
            --------           --------------      /             |
            |ISP   |           |customer CPE|     /    Customer  |
            |DHCPv6|===========|      DHCPv6|====<     site      |
            |server|    <------|------client|     \              |
            --------           --------------      \             |
                                                    \            |
                                                     -------------

   This example will show how DHCPv6 and well known site local unicast
   addresses cooperate to enable the internal nodes to access DNS.

   The customer router CPE is configured on its internal interface with
   one of the reserved site local addresses and listen for DNS queries.
   It would act as a DNS forwarder, as in 5.2,  forwarding those queries
   to the recursive DNS server pointed out by the ISP in the DHCPv6
   exchange.

                                                   -------------
                                                  /            |
        ----------           --------------      /             |
        |ISP     |           |customer CPE|     /    Customer  |
        |DNS     |===========|         DNS|====<     site      |
        |resolver|    <------|---forwarder|-----\----          |
        ----------           --------------      \             |
                                                  \            |
                                                   -------------


   The same CPE router could also implement a local DHCPv6 server and
   advertizes itself as DNS forwarder.

                                                     -------------
                                                    /            |
            --------           --------------      /   Customer  |
            |ISP PE|           |customer CPE|     /    site      |
            |      |===========|DHCPv6      |====<               |
            |      |           |server------|-----\--->          |
            --------           --------------      \             |
                                                    \            |
                                                     -------------



   Within the site:

      a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
      DNS forwarder...

                                                   -------------
                                                  /            |
        ----------           --------------      /   Customer  |
        |ISP     |           |customer CPE|     /    site      |
        |DNS     |===========|         DNS|====<               |
        |resolver|    <------|---forwarder|-----\----DHCPv6    |
        ----------           --------------      \   client    |
                                                  \            |
                                                   -------------
          (The address of the DNS forwarder is acquired via DHCPv6.)


      b) other nodes simply send their DNS request to the reserved site
      local addresses.

                                                   -------------
                                                  /            |
        ----------           --------------      /   customer  |
        |ISP     |           |customer CPE|     /    site      |
        |DNS     |===========|         DNS|====<               |
        |resolver|    <------|---forwarder|-----\----non DHCPv6|
        ----------           --------------      \   node      |
                                                  \            |
                                                   -------------
          (Internal nodes use the reserved site local unicast address.)


   A variant of this scenario is the CPE can decide to pass the global
   address of the ISP recursive DNS server in the DHCPv6 exchange with
   the internal nodes.



7. IANA considerations

   The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
   of the site local fec0::/10 prefix.

   The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
   and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
   configuration.

   All other addresses within the fec0:0000:0000:ffff::/64 are reserved
   for future use and are expected to be assigned only with IESG
   approval.




8.  Security Considerations

   Ensuring that queries reach a legitimate DNS server relies on the
   security of the IPv6 routing infrastructure.  The issues here are the
   same as those for protecting basic IPv6 connectivity.

   IPsec/IKE can be used as the well known addresses are used as unicast
   addresses.

   The payload can be protected using standard DNS security techniques.
   If the client can preconfigure a well known private or public key
   then TSIG [TSIG] can be used with the same packets presented for the
   query.  If this is not the case, then TSIG keys will have to be
   negotiated using [TKEY].  After the client has the proper key then
   the query can be performed.

   The use of site local addresses instead of global addresses will
   ensure the DNS queries issued by host using this mechanism will not
   leak out of the site.




9.  References

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

   [ADDRCONF]
        Thomson, S., and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

   [MLD]
        Deering, S., Fenner, W., Haberman, B.,
        "Multicast Listener Discovery (MLD) for IPv6",
        RFC2710, October 1999.

   [TSIG]
        Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
        "Secret Key Transaction Authentication for DNS (TSIG)",
        RFC2845, May 2000.

   [TKEY]
        D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
        RFC2930, September 2000.

   [DHCPv6]
        Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
        Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
        (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
        Februray 2002.

   [DELEG]
        Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
        draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
        February 2002.




10.  Authors' Addresses

   Alain Durand
   SUN microsystems, inc.
   17 Network Circle, UMPK 17-202
   Menlo Park, CA 94025
   Email: [e-mail]

   Jun-ichiro itojun HAGINO
   Research Laboratory, Internet Initiative Japan Inc.
   Takebashi Yasuda Bldg.,
   3-13 Kanda Nishiki-cho,
   Chiyoda-ku, Tokyo 101-0054, JAPAN
   Email: [e-mail]

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, CA 98052, USA
   Email: [e-mail]




11.  Full Copyright Statement

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