[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

DHC                                                         T. Mrugalski
Internet-Draft                                                       ISC
Intended status: Standards Track                           July 02, 2011
Expires: January 3, 2012


           DHCPv6 Options for IPv4 Residual Deployment (4rd)
                   draft-mrugalski-dhc-dhcpv6-4rd-00

Abstract

   This document specifies DHCPv6 options which are meant to be used by
   4rd Customer Edge (CE) to obtain necessary parameters to configure
   their 4rd automatic tunnels.  The 4rd architecture is defined in
   [I-D.despres-intarea-4rd].  Since specification of 4rd is still
   expected to evolve, DHCPv6 options may have to evolve too to fit the
   revised 4rd specification.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 3, 2012.

Copyright Notice

   Copyright (c) 2011 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
   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



Mrugalski                Expires January 3, 2012                [Page 1]


Internet-Draft             4rd DHCPv6 Options                  July 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  DHCPv6 Options Format  . . . . . . . . . . . . . . . . . . . .  3
     3.1.  4rd Options Cardinality  . . . . . . . . . . . . . . . . .  4
     3.2.  4rd Mapping Rule Option  . . . . . . . . . . . . . . . . .  4
     3.3.  CE IPv6 Prefix Option  . . . . . . . . . . . . . . . . . .  5
     3.4.  CE IPv6 Prefix Length Option . . . . . . . . . . . . . . .  6
     3.5.  Domain 4rd Prefix Option . . . . . . . . . . . . . . . . .  6
     3.6.  Domain IPv6 Suffix Option  . . . . . . . . . . . . . . . .  7
     3.7.  BR Anycast Option  . . . . . . . . . . . . . . . . . . . .  8
   4.  4rd Options Example  . . . . . . . . . . . . . . . . . . . . .  8
   5.  DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . .  8
   6.  DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11


























Mrugalski                Expires January 3, 2012                [Page 2]


Internet-Draft             4rd DHCPv6 Options                  July 2011


1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Introduction

   IPv4 Residual Deployment across IPv6-Service networks (4rd)
   [I-D.despres-intarea-4rd] is an automatic tunneling mechanism for
   providing IPv4 connectivity service to end users over a service
   provider's IPv6 network.  To operate properly, 4rd Customer Edge (CE)
   requires one or more mapping rules configured.  One mapping rule
   constists of the following parameters: Length of CE IPv6 Prefix,
   Domain IPv6 Prefix, Domain 4rd Prefix, and optionally Domain IPv6
   suffix.  Also, Anycast BR IPv6 address must be configured for proper
   operation.  This document defines several DHCPv6 options that allow
   delivery of required information to configure CE.  Definitions of
   enumerated parameters are provided in [I-D.despres-intarea-4rd].
   Since specification of 4rd is still expected to evolve, DHCPv6
   options may have to evolve too to fit the revised 4rd specification.


3.  DHCPv6 Options Format

   To configure CE equipment remotely, DHCPv6 should be used.  Several
   new options are defined for that purpose.  Their format and usage is
   defined in the following sections.

   Discussion: Proposed layout assumes that several simple options are
   used.  Such approach simplifies implementation as it is much easier
   for implementors to reuse existing code handling such options.  This
   design choice comes at a cost, however.  Clients must perform checks
   if provided set of options is complete.  Alternatively, it would be
   possible to define one complex option that contains all mandatory
   parameters.  Nevertheless, since postfix parameter is optional, it
   would still require sub-options (or conditional formatting that is
   strongly not recommended [I-D.ietf-dhc-option-guidelines]).

   Discussion: It has also been proposed that since 3 mandatory
   parameters - Domain IPv6 Prefix, Length of the CE IPv6 Prefix (note:
   these are different prefixes), and Domain 4rd prefix - are always
   present, they may be grouped together.







Mrugalski                Expires January 3, 2012                [Page 3]


Internet-Draft             4rd DHCPv6 Options                  July 2011


3.1.  4rd Options Cardinality

   To properly configure 4rd infrastructure, following parameters are
   required:

      Exactly one Anycast BR IPv6 Address.

      One or more 4rd mapping rules.  Each 4rd mapping rule consists of
      exactly one 4rd CE prefix, exactly one CE IPv6 prefix length, and
      exactly one 4rd prefix.  Each mapping rule may contain zero or one
      Domain IPv6 Suffix.

3.2.  4rd Mapping Rule Option

   The 4rd Mapping Rule Option does not convey any information on its
   own, but rather is used to group options that represent parameteres
   of a single mapping rule. 4rd architecture allows more than one
   mapping rules, therefore the 4rd Mapping Rule Option MAY appear more
   than once in a DHCPv6 message.

   The format of the 4rd Mapping Rule Option is shown in Figure 1.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-------------------------------+-------------------------------+
     |     OPTION_4RD_RULE (TBD)     |          option-len           |
     +-------------------------------+-------------------------------+
     |                                                               |
     |                          sub-options                          |
     |                                                               |
     +---------------------------------------------------------------+

      option-code: OPTION_4RD_RULE (TBD)

       option-len: Length of all sub-options.

      sub-options: options defining Mapping Rule parameters

                     Figure 1: 4rd Mapping Rule Option

   The 4rd Mapping Rule Option consists of option-code and option-len
   fields (as all DHCPv6 options do), and a variable length sub-options
   field that contains rule parameters.

   The 4rd Mapping Rule Option SHOULD NOT appear in any other than the
   following DHCPv6 messages: Solicit, Advertise, Request, Renew,
   Rebind, Information-Request and Reply.  The 4rd Rule Option may
   appear more than once in each message.



Mrugalski                Expires January 3, 2012                [Page 4]


Internet-Draft             4rd DHCPv6 Options                  July 2011


   Each 4rd Mapping Rule Option MUST contain exactly one 4rd CE Prefix
   Option, exactly one CE IPv6 Prefix Length Option, exactly one 4rd
   Prefix Option and zero or one Domain IPv6 Suffix Option.  Option that
   does not meet this criteria is invalid and MUST be ignored.

   4rd Mapping Rule Option may contain additional options.

   Discussion: Defined format does not allow referencing rules, i.e. if
   there are several rules, there is no rule 1, rule 2 etc.  DHCPv6
   protocol does not allow leveraging order in which options appear in
   the message.  If rule indentification is useful, a small ID field may
   be added to the 4rd Mapping Rule Option.

3.3.  CE IPv6 Prefix Option

   CE IPv6 Prefix Option conveys information about domain IPv6 prefix
   that is going to be used by requesting client (CE).

   The format of the CE IPv6 Prefix Option is defined in Figure 2.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-------------------------------+-------------------------------+
       |      OPTION_4RD_PREFIX6       |          option-len           |
       +-------------------------------+-------------------------------+
       |                                                               |
       |                      domain-ipv6-prefix                       |
       |                                                               |
       |                                                               |
       +---------------------------------------------------------------+

            option-code: OPTION_4RD_PREFIX6 (TBD)

             option-len: Length of Domain IPv6 Prefix in octets (16)

     domain-ipv6-prefix: 4rd Domain IPv6 Prefix

                      Figure 2: CE IPv6 Prefix Option

   The CE IPv6 Prefix Option consists of option-code and option-len
   fields (as all DHCPv6 options do), and 16 octets long Domain IPv6
   Prefix field.

   The CE IPv6 Prefix Option MUST NOT appear in DHCPv6 message directly.
   It MUST NOT appear in any option other than 4rd Mapping Rule Option.






Mrugalski                Expires January 3, 2012                [Page 5]


Internet-Draft             4rd DHCPv6 Options                  July 2011


3.4.  CE IPv6 Prefix Length Option

   The CE IPv6 Prefix Length Option defines length of the prefix
   assigned to specific CE.  It is expected to be used together with CE
   IPv6 Prefix Option, defined in Section Section 3.3.

   The format of the CE Prefix Length Option is shown in Figure 3.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-------------------------------+-------------------------------+
     |    OPTION_4RD_PREFIX6_LEN     |          option-len           |
     +-------------------------------+-------------------------------+
     |  prefix len   |
     +---------------+

       option-code: OPTION_4RD_PREFIX6_LEN: (TBD)

        option-len: Length of the prefix-len field in octets (1)

        prefix-len: Length of Domain IPv6 Prefix

                  Figure 3: CE IPv6 Prefix Length Option

   The CE IPv6 Prefix Length Option consists of option-code and option-
   len fields (as all DHCPv6 options do), and 1 octet long Domain IPv6
   Prefix Length field that specifies length in bits (0-64).

   The CE IPv6 Prefix Length Option MUST NOT appear in DHCPv6 message
   directly.  It MUST NOT appear in any option other than 4rd Mapping
   Rule Option.

3.5.  Domain 4rd Prefix Option

   The Domain 4rd Prefix Option contains IPv4 address.  Depending on its
   length it is IPv4 prefix, an IPv4 address, or a shared IPv4 address
   followed by Port-set ID.

   The format of the Domain 4rd Prefix Option is shown in Figure
   Figure 4.











Mrugalski                Expires January 3, 2012                [Page 6]


Internet-Draft             4rd DHCPv6 Options                  July 2011


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-------------------------------+-------------------------------+
       |      OPTION_4RD_PREFIX4       |          option-len           |
       +-------------------------------+-------------------------------+
       |                      domain-4rd-prefix                        |
       +-------------------------------+-------------------------------+
       | 4rd-prefix-len|
       +---------------+
        OPTION_4RD_PREFIX: (TBD)

               option-len: 7

        domain-4rd-prefix: Domain 4rd Prefix (an IPv4 address)

           4rd-prefix-len: Length of Domain IPv6 Prefix (in bits)

                    Figure 4: Domain 4rd Prefix Option

   The Domain 4rd Prefix Option consists of option-code and option-len
   fields (as all DHCPv6 options do), four octets long domain-4rd-prefix
   field that contains IPv4 address and one octect long 4rd-prefix-len.

   Depending on 4rd-prefix-len value, actual 4rd Prefix may be range of
   IPv4 addresses (part of domain-4rd-prefix), a single IPv4 address
   (specified by domain-4rd-prefix) or IPv4 address+port range
   (specified by domain-4rd-prefix and Port-set ID).  Port-Set ID is
   derived from CE Index, as explained in see Section 4.3.3 in
   [I-D.despres-intarea-4rd].

3.6.  Domain IPv6 Suffix Option

   TODO: I don't understand what this suffix is.
   [I-D.despres-intarea-4rd] is unclear.  My understanding is that
   suffix are bits that are appended to Domain IPv6 Prefix + CE Index
   and they together form CE IPv6 Prefix.  It is only used when Domain
   IPv6 Prefix and CE Index are short enough.  On the other hand, slide
   4 of http://tools.ietf.org/agenda/80/slides/dhc-6.pdf suggests that
   suffix defines something that is appended after CE IPv6 Prefix.

   Discussion: Wouldn't it be better to just use Domain IPv6 Prefix as a
   template with CE Index inserted at appropriate offset?  This would
   make configuration simpler (one less option) and also validation of
   received option would be much more straightforward.







Mrugalski                Expires January 3, 2012                [Page 7]


Internet-Draft             4rd DHCPv6 Options                  July 2011


3.7.  BR Anycast Option

   The BR Anycast Option specifies an IPv6 anycast address that should
   be used to reach nearest Border Relay.

   The format of the BR Anycast Option is shown in Figure 5.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-------------------------------+-------------------------------+
       |         OPTION_4RD_BR         |          option-len           |
       +-------------------------------+-------------------------------+
       |                                                               |
       |                         br-anycast-addr                       |
       |                                                               |
       |                                                               |
       +---------------------------------------------------------------+

        option-code: OPTION_4RD_BR (TBD)

         option-len: Length of BR IPv6 Anycast Prefix (16)

    br-anycast-addr: Border Relay IPv6 Anycast Address

                     Figure 5: BR IPv6 Address Option

   The BR IPv6 Address Option consists of option-code and option-len
   fields (as all DHCPv6 options do), and a 16 octets long br-anycast-
   addr field that specifies Border Relay IPv6 Anycast address.

   The BR Anycast Option SHOULD NOT appear in any other than the
   following DHCPv6 messages: Solicit, Advertise, Request, Renew,
   Rebind, Information-Request and Reply.

   The BR Anycast Option MAY appear zero or one time in a single
   message.


4.  4rd Options Example

   TODO: Provide an example here.  Possibly reuse example from Remi's
   presentation from IETF80.


5.  DHCPv6 Server Behavior

   Server conformant to this specification MUST allow configuration of
   one or more Mapping Rule Options.



Mrugalski                Expires January 3, 2012                [Page 8]


Internet-Draft             4rd DHCPv6 Options                  July 2011


   Server MUST transmist all configured instances of the Mapping Rule
   Options with all sub-options, if client requested it using
   OPTION_4RD_RULE in ORO.

   RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and
   server negotiate configuration values using the Option Request Option
   (OPTION_ORO).  As a convenience to the reader, we mention here that a
   server will not reply with a 4rd Mapping Rule Option if the client
   has not explicitly enumerated it on its Option Request Option.


6.  DHCPv6 Client Behavior

   Although other use cases are allowed, in typical use case CE will act
   as DHCPv6 client and will request 4rd configuration to be assigned by
   the DHCPv6 server located in the ISP network.  A client that supports
   4rd CE functionality and conforms to this specfication MUST include
   OPTION_4RD_RULE in its ORO.

   Client SHOULD request 4rd options in SOLICIT, REQUEST, RENEW, REBIND
   and INFORMATION-REQUEST messages.

   If the client receives OPTION_4RD_RULE option, it must verify the
   option contents, as described in Section 3.2.  In case of failved
   verification, client MUST discard invalid option and continue
   processing any following options, including other instances of 4rd
   options.

   If client receives more than one OPTION_4RD_RULE, it MUST use all
   received instances.  It MUST NOT use only the first one, while
   discarding remaining ones.

   Note that system implementing 4rd CE functionality may have multiple
   network interfaces, and these interfaces may be configured
   differently; some may be connected to networks that call for 4rd, and
   some may be connected to networks that are using normal dual stack or
   other means.  The 4rd CE system should approach this specification on
   an interface-by-interface basis.  For example, if the CE system is
   attached to multiple networks that provide the 4rd Mapping Rule
   Option, then the CE system MUST configure a 4rd tunnel for each
   interface separately as each 4rd provides IPv4 connectivity for each
   distinct interface.  Means to bind a 4rd configuration to a given
   interface in a multiple interfaces device are out of scope of this
   document.







Mrugalski                Expires January 3, 2012                [Page 9]


Internet-Draft             4rd DHCPv6 Options                  July 2011


7.  Security Considerations

   Implementation of this document does not present any new security
   issues, but as with all DHCPv6-derived configuration state, it is
   completely possible that the configuration is being delivered by a
   third party (Man In The Middle).  As such, there is no basis to trust
   that the access the 4rd can be trusted, and it should not therefore
   bypass any security mechanisms such as IP firewalls.

   Section 23 of [RFC3315] discusses DHCPv6-related security issues.

   Section 6 of [I-D.despres-intarea-4rd] discusses 4rd related security
   issues.


8.  IANA Considerations

   IANA is requested to allocate DHCPv6 option codes referencing this
   document, delineating OPTION_4RD_RULE, OPTION_4RD_PREFIX6,
   OPTION_4RD_PREFIX6_LEN, OPTION_4RD_PREFIX and OPTION_4RD_BR option
   names.


9.  Acknowledgements

   This document would not have been possible without support from Remi
   Despres, Satoru Matsushima, Ole Troan and Tetsuya Murakami.


10.  References

10.1.  Normative References

   [I-D.despres-intarea-4rd]
              Despres, R., Matsushima, S., Murakami, T., and O. Troan,
              "IPv4 Residual Deployment across IPv6-Service networks
              (4rd) ISP-NAT's made optional",
              draft-despres-intarea-4rd-01 (work in progress),
              March 2011.

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.





Mrugalski                Expires January 3, 2012               [Page 10]


Internet-Draft             4rd DHCPv6 Options                  July 2011


10.2.  Informative References

   [I-D.ietf-dhc-option-guidelines]
              Hankins, D., "Guidelines for Creating New DHCP Options",
              draft-ietf-dhc-option-guidelines-06 (work in progress),
              March 2010.


Author's Address

   Tomasz Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   USA

   Phone: +1 650 423 1345
   Email: tomasz.mrugalski@gmail.com

































Mrugalski                Expires January 3, 2012               [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/