Network Working Group                                         F. Templin
Internet-Draft                              Boeing Research & Technology
Updates: 5214 (if approved)                             December 8, 2009
Intended status: Standards Track
Expires: June 11, 2010


 Dynamic Host Configuration Protocol (DHCPv4) Option for the Intra-Site
             Automatic Tunnel Addressing Protocol (ISATAP)
                    draft-templin-isatap-dhcp-06.txt

Abstract

   This document specifies a Dynamic Host Configuration Protocol
   (DHCPv4) option for nodes that implement the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP).

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 June 11, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Templin                   Expires June 11, 2010                 [Page 1]


Internet-Draft             ISATAP DHCP Option              December 2009


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology and Requirements  . . . . . . . . . . . . . . . . . 3
   3.  ISATAP DHCPv4 Option  . . . . . . . . . . . . . . . . . . . . . 3
   4.  ISATAP Client Behavior  . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Backward Compatibility . . . . . . . . . . . . . . . . 5
   Appendix B.  Anycast Services . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7




























Templin                   Expires June 11, 2010                 [Page 2]


Internet-Draft             ISATAP DHCP Option              December 2009


1.  Introduction

   This document specifies a Dynamic Host Configuration Protocol option
   [RFC2131][RFC2132] for nodes that implement the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP) [RFC5214].  The option encodes
   configuration information used by clients to initialize the Potential
   Router List as specified in [RFC5214], section 8.3.2.  The option
   format is similar to that specified in [RFC3361], and includes a list
   of IPv4 addresses and domain names that form the Potential Router
   List.


2.  Terminology and Requirements

   The terminology of ISATAP [RFC5214] applies to this document.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].


3.  ISATAP DHCPv4 Option

   The ISATAP DHCPv4 option encodes a list of IPv4 addresses followed by
   a list of DNS [RFC1035] fully-qualified domain names (FQDNs) using
   the following format:

       Code  Len   N   <- IPv4 addr's ->   <-   FQDN's    ->
      +----+----+----+----+----+----+----+----+----+----+----+
      | TBD| Len|  N | a1 | a2 | ...| aN | f1 | f2 | ...| fM |
      +----+----+----+----+----+----+----+----+----+----+----+

                   Figure 1: ISATAP DHCPv4 Option Format

   As shown in Figure 1, the DHCPv4 option code is followed immediately
   by a 'Len' octet that indicates the total number of option octets
   that follow.  The 'Len' octet is followed by an 'N' octet with a
   value (0 <= N <= 255) that indicates the total number of 4-octet IPv4
   addresses in the list that follows.  The final IPv4 address is
   followed by a list of 'M' DNS FQDNs encoded exactly as specified in
   Section 3.1 of [RFC1035], where M is implicitly derived by parsing
   the remaining portion of the option beyond the final IPv4 address.

   For example, if the administrator wishes to advertise the IPv4
   addresses '192.0.2.3' and '192.0.2.3', and the FQDNs "isatap.com",
   "isatap.org" and "isatap.net", the DHCPv4 option is encoded as shown
   in Figure 2 (with numeric values represented as decimal):




Templin                   Expires June 11, 2010                 [Page 3]


Internet-Draft             ISATAP DHCP Option              December 2009


      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |TBD| 45| 2 |192| 00| 02| 02|192| 00| 02| 03| 6 |'i'|'s'|'a'|
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |'t'|'a'|'p'| 3 |'c'|'o'|'m'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'|
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      | 3 |'o'|'r'|'g'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'| 3 |'n'|'e'|
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |'t'| 0 |
      +---+---+

                  Figure 2: ISATAP DHCPv4 Option Example

   If the length of the ISATAP DHCPv4 Option exceeds 254 octets, the
   option is encoded as for DHCP long options as specified in [RFC3396].


4.  ISATAP Client Behavior

   ISATAP clients use the information encoded in the ISATAP DHCPv4
   option to initialize the Potential Router List as specified in
   Section 8.3.2 of [RFC5214].  The ISATAP client itself (i.e., and not
   the DHCP server) resolves each FQDN into a list of IPv4 addresses,
   since the name resolution service available to the ISATAP client may
   in some cases be more responsive to dynamic updates than the name
   resolution service available to the DHCP server.

   After the ISATAP client initializes the Potential Router List, it
   performs router and prefix discovery as specified in Sections 8.3.3
   and 8.3.4 of [RFC5214].


5.  IANA Considerations

   A new DHCPv4 option number for ISATAP is requested.


6.  Security Considerations

   The security considerations in [RFC2131] apply.


7.  Acknowledgments

   The following individuals are acknowledged for their contributions:
   Jim Bound, Ralph Droms, Ted Lemon, Mohan Parthasarathy, Pekka Savola.


8.  References



Templin                   Expires June 11, 2010                 [Page 4]


Internet-Draft             ISATAP DHCP Option              December 2009


8.1.  Normative References

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

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

8.2.  Informative References

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCP-for-IPv4) Option for Session Initiation Protocol
              (SIP) Servers", RFC 3361, August 2002.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.


Appendix A.  Backward Compatibility

   The ISATAP DHCP option can be used in the presence of legacy ISATAP
   clients, which typically construct a FQDN for the Potential Router
   List by concatenating the string "isatap" with a connection-specific
   DNS suffix "example.com" received from the DHCP server (e.g., as
   "isatap.example.com").  Administrators should therefore ensure that
   the Potential Router List discovered by clients that implement the
   ISATAP DHCP option is consistent with the Potential Router List
   discovered by legacy clients.


Appendix B.  Anycast Services

   Some of the IPv4 addresses that appear in the Potential Router List
   may be anycast addresses, i.e., they may be configured on the ISATAP



Templin                   Expires June 11, 2010                 [Page 5]


Internet-Draft             ISATAP DHCP Option              December 2009


   interfaces of multiple routers.  In that case, each ISATAP router
   interface that configures the same anycast address must provide
   equivalent packet forwarding and IPv6 Neighbor Discovery services.

   Use of an anycast address as the IP destination address of tunneled
   packets can have subtle interactions with tunnel path MTU and
   neighbor discovery.  For example, if the initial fragments of a
   fragmented tunneled packet with an anycast IP destination address are
   routed to different egress tunnel endpoints than the remaining
   fragments, the multiple endpoints will be left with incomplete
   reassembly buffers.  This issue can be mitigated by ensuring that
   each egress tunnel endpoint implements a proactive reassembly buffer
   garbage collection strategy.  Additionally, ingress tunnel endpoints
   that send packets with an anycast IP destination address must use the
   minimum path MTU for all egress tunnel endpoints that configure the
   same anycast address as the tunnel MTU.  Finally, ingress tunnel
   endpoints must treat ICMP unreachable messages from a router within
   the tunnel as at most a weak indication of neighbor unreachability,
   since the failures may only be transient and quickly corrected
   through reconvergence of the underlying routing protocol.

   Use of an anycast address as the IP source address of tunneled
   packets can lead to more serious issues.  For example, when the IP
   source address of a tunneled packet is anycast, ICMP messages
   produced by routers within the tunnel might be delivered to different
   ingress tunnel endpoints than the ones that produced the packets.  In
   that case, functions such as path MTU discovery and neighbor
   unreachability detection may experience non-deterministic behavior
   that can lead to communications failures.  Additionally, the
   fragments of multiple tunneled packets produced by multiple ingress
   tunnel endpoints may be delivered to the same reassembly buffer at a
   single egress tunnel endpoint.  In that case, data corruption may
   result due to fragment misassociation during reassembly.

   In view of these considerations, ISATAP routers that configure an
   anycast address should also configure one or more unicast addresses
   from the Potential Router List; they should further accept tunneled
   packets destined to any of their anycast or unicast addresses, but
   should send tunneled packets using a unicast address as the source
   address.  The sole exception to this rule is that ISATAP routers
   should respond to unicast IPv6 Neighbor and Router Solicitation
   messages by using the destination address of the solicitation as the
   source address for the corresponding advertisement messages, i.e.,
   whether the address is anycast or unicast.

   In order to influence traffic to use an anycast route (and thereby
   leverage the natural fault tolerance afforded by anycast), ISATAP
   routers should set higher preferences on the default routes they



Templin                   Expires June 11, 2010                 [Page 6]


Internet-Draft             ISATAP DHCP Option              December 2009


   advertise using an anycast address as the source and set lower
   preferences on the default routes they advertise using a unicast
   address as the source (see: [RFC4191]).


Author's Address

   Fred L. Templin
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org





































Templin                   Expires June 11, 2010                 [Page 7]