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

Versions: 00

MIF Working Group                                            M. Stenberg
Internet-Draft                                                  S. Barth
Intended status: Standards Track                             Independent
Expires: April 17, 2016                                 October 15, 2015


         Multiple Provisioning Domains using Domain Name System
                     draft-stenberg-mif-mpvd-dns-00

Abstract

   This document describes a mechanism to transmit and secure
   provisioning domain information for IPv6 and IPv4 addresses by using
   reverse DNS resolution.  In addition it specifies backwards-
   compatible extensions to IPv6 host configuration to support special-
   purpose global IPv6 prefixes which can only be used to access certain
   isolated services.

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 April 17, 2016.

Copyright Notice

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




Stenberg & Barth         Expires April 17, 2016                 [Page 1]


Internet-Draft               MPVD using DNS                 October 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  PVD information discovery using DNS . . . . . . . . . . . . .   3
     3.1.  PVD TXT Record Fomat  . . . . . . . . . . . . . . . . . .   4
     3.2.  PVD TXT Record Keys . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  Reachable Services  . . . . . . . . . . . . . . . . .   4
       3.2.2.  DNS Configuration . . . . . . . . . . . . . . . . . .   5
       3.2.3.  Connectivity Characteristics  . . . . . . . . . . . .   5
       3.2.4.  Private Extensions  . . . . . . . . . . . . . . . . .   6
   4.  Special-purpose IPv6 prefixes . . . . . . . . . . . . . . . .   6
     4.1.  Extensions to Stateless Address Autoconfiguration . . . .   6
     4.2.  Extensions to DHCPv6  . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative references  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative references  . . . . . . . . . . . . . . . . .  11
   Appendix A.  This solution compared to doing this in DHCPv6/NDP
                [RFC                     Editor: please remove]  . .  11
   Appendix B.  Discussion Points [RFC Editor: please remove]  . . .  12
   Appendix C.  Changelog [RFC Editor: please remove]  . . . . . . .  13
   Appendix D.  Draft Source [RFC Editor: please remove] . . . . . .  13
   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Given multiple address prefixes or multiple interfaces, hosts require
   more information to make educated choices about the interfaces and
   addresses to use.  [RFC7556] describes the provision domains (PVDs)
   that provide the additional information the hosts need.

   This document describes where and how the provision domain
   information is encoded in the Domain Name System (DNS).  For optional
   authentication DNSSEC is used.

   A backwards compatible way of adding IPv6 prefixes without generic
   internet connectivity is also provided so that the hosts that are not
   aware of the provisioning domain prefixes do not inadvertly use those
   for general network access.





Stenberg & Barth         Expires April 17, 2016                 [Page 2]


Internet-Draft               MPVD using DNS                 October 2015


2.  Terminology

   PVD               a provisioning domain, usually with a set of
                     provisioning domain information; for more
                     information, see [RFC7556].
   special-purpose   a global IPv6 source prefix that cannot be used to
   IPv6 prefix       reach the public IPv6 internet but instead only
                     allows access to certain special services (e.g.,
                     VoIP, IPTV).

2.1.  Requirements Language

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

3.  PVD information discovery using DNS

   Each PVD is stored within the DNS, encoded as a single TXT record
   [RFC1035].  Section 3.1 describes the syntax and Section 3.2 the
   semantics of the enclosed data.

   To find the per-PVD TXT records that apply to a source address, the
   host queries the DNS for PTR records of the domain _pvd.<domain>.
   <domain> is a .arpa domain for reverse lookups derived from the
   respective prefix or subnet the source address is assigned from and
   generated as specified in [RFC3596] for IPv6 addresses and [RFC1034]
   for IPv4 addresses respectively.  If the query returned any PTR
   records the host then subsequently queries the DNS for TXT records
   located in each domain indicated in the PTR records and handles their
   contents as individual PVDs.

   As prefixes can be sub-delegated arbitrarily, PTR records SHOULD be
   provided for any subprefixes contained within a particular prefix.
   For example, given a prefix 2001:db8:8765:4321::/64, a host with an
   address of 2001:db8:8765:4321:1234:5678:abcd:beef queries for PTR
   records in _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.2.3.4.5.6.7.8.8.b.d
   .0.1.0.0.2.ip6.arpa However, if the address is assigned from
   2001:db8:8765:4321:1234::/80, the request would be made for _pvd.0.0.
   0.0.0.0.0.0.0.0.0.0.4.3.2.1.1.2.3.4.5.6.7.8.8.b.d.0.1.0.0.2.ip6.arpa
   instead.

   If for example, the retrieved PTR record is assumed to point at the
   FQDN _pvd.example.com.  The next query is then sent for TXT records
   in this domain, and if successful, the node has retrieved up-to-date
   information about PVDs applicable to that particular address.




Stenberg & Barth         Expires April 17, 2016                 [Page 3]


Internet-Draft               MPVD using DNS                 October 2015


   A host MUST support handling multiple PTR records for the initial
   .arpa domain as well as multiple TXT records for all domains pointed
   to by the PTR records.  This facilitates handling of multiple PVDs
   with minimal amount of state in the network.  A host MUST honor both
   the time-to-live of the received records, and negative replies that
   conform to [RFC2308].  A host MUST NOT use addresses from a prefix as
   the source for new packet flows once the TTL has passed until it did
   successfully retrieve updated PVD information.

3.1.  PVD TXT Record Fomat

   PVD information within DNS is encoded using TXT records, similar to
   those of DNS-SD [RFC6763] and defined as follows.  TXT records
   consist of key/value pairs, each encoded as a string of up to 255
   octets preceded by a length byte storing the number of octets.  The
   strings are in the form "key=value" or simply "key" (without
   quotation marks) where everything up to the first '=' character (if
   any, otherwise the whole string) is the key and everything after it
   (if any, including subsequent '=' characters) is the value.  Due to
   the use of a length byte, quotation marks or similar are not required
   around the value.  Keys are case-sensitive.  Hosts MUST ignore TXT
   records which do not conform to these rules.

3.2.  PVD TXT Record Keys

   The following keys are defined to be used inside PVD TXT records.
   Unknown keys inside PVD Information MUST be ignored.

3.2.1.  Reachable Services

   The following set of keys can be used to specify the set of services
   for which the respective PVD should be used.  If present they MUST be
   honored by the client, i.e., if the PVD is marked as not usable for
   internet access it MUST NOT be used for internet access, if the
   usability is limited to a certain set of domain or address prefixes,
   then a different PVD MUST be used for other destinations.















Stenberg & Barth         Expires April 17, 2016                 [Page 4]


Internet-Draft               MPVD using DNS                 October 2015


   +-----+---------------+-----------------+---------------------------+
   | Key | Description   | Value           | Example                   |
   +-----+---------------+-----------------+---------------------------+
   | n   | User-visible  | human-readable  | n=Foobar Service          |
   |     | service name  | UTF-8 string    |                           |
   | s   | Internet      | (none)          | s                         |
   |     | inaccessible  |                 |                           |
   | z   | DNS zones     | comma-separated | z=foo.com,sub.bar.com     |
   |     | accessible    | list of DNS     |                           |
   |     |               | zone            |                           |
   | 6   | IPv6-prefixes | comma-separated | 6=2001:db8:a::/48,2001:db |
   |     | accessible    | list of IPv6    | 8:b:c::/64                |
   |     |               | prefixes        |                           |
   | 4   | IPv4-prefixes | comma-separated | 4=1.2.3.0/24,2.3.0.0/16   |
   |     | accessible    | list of IPv4    |                           |
   |     |               | prefixes in     |                           |
   |     |               | CIDR            |                           |
   +-----+---------------+-----------------+---------------------------+

3.2.2.  DNS Configuration

   The following set of keys can be used to specify the DNS
   configuration for the respective PVD.  If present, they MUST be
   honored and used by the client whenever it wishes to access a
   resource of the PVD.

   +-----+-------------+---------------------+-------------------------+
   | Key | Description | Value               | Example                 |
   +-----+-------------+---------------------+-------------------------+
   | r   | Recursive   | comma-separated     | r=2001:db8::1,192.0.2.2 |
   |     | DNS server  | list of IPv6 and    |                         |
   |     |             | IPv4 addresses      |                         |
   | d   | DNS search  | comma-separated     | d=foo.com,sub.bar.com   |
   |     | domains     | list of search      |                         |
   |     |             | domains             |                         |
   +-----+-------------+---------------------+-------------------------+

3.2.3.  Connectivity Characteristics

   The following set of keys can be used to signal certain
   characteristics of the connection towards the PVD.










Stenberg & Barth         Expires April 17, 2016                 [Page 5]


Internet-Draft               MPVD using DNS                 October 2015


   +-----+------------------+---------------------------+--------------+
   | Key | Description      | Value                     | Example      |
   +-----+------------------+---------------------------+--------------+
   | bw  | Maximum          | 1 symmetrical or 2 comma- | bw=5000 or   |
   |     | achievable       | separated ingress, egress | bw=1000,100  |
   |     | bandwidth        | values in kilobits per    |              |
   |     |                  | second                    |              |
   | lt  | Minimum          | 1 symmetrical or 2 comma- | lt=20 ot     |
   |     | achievable       | separated ingress, egress | lt=20,100    |
   |     | latency          | values in milliseconds    |              |
   | rl  | Maximum          | 1 symmetrical or 2 comma- | rl=1000 or   |
   |     | achievable       | separated ingress, egress | rl=900,800   |
   |     | reliability      | values in 1/1000          |              |
   | tm  | Traffic metered  | (none) or traffic         | tm or        |
   |     | (cut-off /       | threshold in kilobytes    | tm=1000000   |
   |     | limited over     |                           |              |
   |     | threshold)       |                           |              |
   | cp  | Captive portal   | (none)                    | cp           |
   | nat | IPv4 NAT in      | (none)                    | nat          |
   |     | place            |                           |              |
   +-----+------------------+---------------------------+--------------+

3.2.4.  Private Extensions

   keys starting with "x-" are reserved for private use and can be
   utilized to provide vendor-, user- or enterprise-specific
   information.  It is RECOMMENDED to use one of the patterns "x-FQDN-
   KEY[=VALUE]" or "x-PEN-KEY[=VALUE]" where FQDN is a fully qualified
   domain name or PEN is a private enterprise number [PEN] under control
   of the author of the extension to avoid collisions.

4.  Special-purpose IPv6 prefixes

   A service provider might wish to assign certain global unicast
   address prefixes which can be used to reach a limited set of services
   only.  In the presence of legacy hosts it must be ensured however
   that these prefixes are not mistakenly used as source addresses for
   other destinations.  This section therefore defines optional
   extensions to NDP [RFC4861], DHCPv6 [RFC3315] and DHCPv6-PD [RFC3633]
   to indicate this state.

4.1.  Extensions to Stateless Address Autoconfiguration

   NDP [RFC4861] defines the Prefix Information option to announce
   prefixes for stateless address configuration.  The "A-bit" is set,
   whenever hosts may autonomously derive addresses from a given prefix.
   For special-purpose prefixes this document defines the first bit of
   the Reserved1-field as the "S-Bit".



Stenberg & Barth         Expires April 17, 2016                 [Page 6]


Internet-Draft               MPVD using DNS                 October 2015


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |L|A|S|Reserved1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

   The following additional requirements apply to hosts intending to
   support global special-purpose IPv6 prefixes:

      Upon reception of a Prefix Information Option with the S-Bit set,
      it should behave as if the A-Bit was set, however (unless the
      A-Bit was actually set by the sending router) it MUST delay using
      any addresses derived from the prefix until it has queried,
      retrieved and honored (see Section 3) at least all mandatory
      provisioning domain information related to the given prefix.

      A host SHOULD NOT interpret the S-Bit being clear as an indicator
      that no provisioning domain information is available for a given
      prefix.

   The following additional requirements apply to routers:

      A router MUST NOT set the A-Bit for global unicast address
      prefixes which cannot be used to reach the public IPv6 internet.

      A router SHOULD use the S-Bit to indicate that PVD-aware hosts can
      statelessly assign themselves addresses from a given prefix.  It
      MAY use the S-Bit in addition to the A-Bit to indicate that a
      prefix usable to reach the public IPv6 internet has additional
      (optional) provisioning domain information.

      A router announcing one or more Prefix Information options with
      the S-Bit set MUST also announce one or more recursive DNS servers
      using a Recursive DNS Server Option [RFC6106].  If none of the
      Prefix Information Options it announces have the A-Bit set then at
      least one of these recursive DNS servers MUST be reachable using a
      link-local address.

4.2.  Extensions to DHCPv6

   Using DHCPv6 [RFC3315] and DHCPv6-PD [RFC3633] servers can actively
   decide which addresses or prefixes are assigned to clients and
   requesting routers, however a mechanism is needed to distinguish PVD-
   aware devices and in the same sense PVD-aware devices need to be able
   to detect which prefixes and addresses are special-purpose.
   Therefore, a zero-length DHCPv6 option OPTION_SPECIAL_PURPOSE is




Stenberg & Barth         Expires April 17, 2016                 [Page 7]


Internet-Draft               MPVD using DNS                 October 2015


   defined to be added as a suboption to OPTION_IAADDR and
   OPTION_IAPREFIX options.

   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_SPECIAL_PURPOSE (TBD)  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following additional requirements apply to clients and requesting
   routers intending to support global special-purpose IPv6 prefixes via
   DHCPv6:

      A client or requesting router MUST include the option code
      OPTION_SPECIAL_PURPOSE in an option OPTION_ORO in its SOLICIT and
      REQUEST messages, whenever it wishes to accept special-purpose
      prefixes in its identity associations.

      Upon reception of an OPTION_IAADDR or OPTION_IAPREFIX option
      having an embedded OPTION_SPECIAL_PURPOSE option it MUST delay
      using any addresses derived from the prefix as source address for
      its own communication until it has queried, retrieved and honored
      (see Section 3) at least all mandatory provisioning domain
      information related to the given prefix or address.  If it is a
      requesting router, it MAY however subdelegate prefixes or assign
      addresses from special-purpose prefixes to clients without doing
      so as long as the requirements in the following paragraph are
      honored.

   The following additional requirements apply to routers assigning
   addresses from or delegating (parts of) special-purpose prefixes
   using DHCPv6:

      A router MUST include a zero-length suboption of type
      OPTION_SPECIAL_PURPOSE in every OPTION_IAADDR and OPTION_IAPREFIX
      option it assigns or delegates containing a global unicast address
      or prefix which cannot be used to reach the public IPv6 internet.
      It MUST NOT assign or delegate such an address or prefix to a
      client or requesting router not including the option code of
      OPTION_SPECIAL_PURPOSE inside an OPTION_ORO option.

      A router announcing one or more addresses or prefixes with an
      embedded OPTION_SPECIAL_PURPOSE option MUST also announce one or
      more recursive DNS servers using a OPTION_DNS_SERVERS option
      [RFC3646].  If all of the addresses in a DHCPv6 reply carry the
      embedded OPTION_SPECIAL_PURPOSE option then at least one of the
      announced recursive DNS servers MUST be reachable using a link-
      local address.



Stenberg & Barth         Expires April 17, 2016                 [Page 8]


Internet-Draft               MPVD using DNS                 October 2015


5.  Security Considerations

   The security implications of using PVDs in general depend on two
   factors: what they are allowed to do, and whether or not the
   authentication and authorization of the PVD information received is
   sufficient for the particular usecase.  As the defined scheme uses
   DNS for retrieval of the connection parameters, the retrieval of both
   the PTR and the TXT records should be secured, if they are to be
   trusted.  The PVD information allows for the following types of
   attacks:

   o  Traffic redirection, both by providing custom DNS server, as well
      as actual potentially different next-hop and/or source address
      selection.

   o  Faking of connection capabilities to e.g. prefer some connection
      fraudulently over others.

   If a host requires DNSSEC authentication and the retrieved
   information is not sufficiently secured, they MUST be ignored as the
   defined way of using them in Section 3.2 requires honoring the
   supplied information.

   Security properties of NDP and DHCPv6 are inherited for the
   respective extensions, therefore relevant sections of [RFC4861] and
   [RFC3315] should be consulted.  In any case, signaling addresses and
   prefixes to be special-purpose does not have a significant impact on
   the underlying assignment and delegation mechanisms.

6.  IANA Considerations

   IANA is requested to setup a PVD DNS TXT Record Key registry with the
   initial types: s, z, 6, 4 (Section 3.2.1); r, d (Section 3.2.2); bw,
   lt, rl, tm, cp, nat (Section 3.2.3) and a prefix x- (Section 3.2.4)
   for Private Use [RFC5226].  The policy for further additions to the
   registry is requested to be RFC Required [RFC5226].

   This document defines a new bit for the NDP Prefix Information Option
   (the S-bit).  There is currently no registration procedure for such
   bits, so IANA should not take any action on this matter.

   IANA should assign a DHCPv6 option code OPTION_SPECIAL_PURPOSE to the
   DHCPv6 option code space defined in [RFC3315].








Stenberg & Barth         Expires April 17, 2016                 [Page 9]


Internet-Draft               MPVD using DNS                 October 2015


7.  References

7.1.  Normative references

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <http://www.rfc-editor.org/info/rfc2308>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <http://www.rfc-editor.org/info/rfc3646>.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, DOI 10.17487/RFC6106, November 2010,
              <http://www.rfc-editor.org/info/rfc6106>.






Stenberg & Barth         Expires April 17, 2016                [Page 10]


Internet-Draft               MPVD using DNS                 October 2015


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <http://www.rfc-editor.org/info/rfc7556>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596, DOI
              10.17487/RFC3596, October 2003,
              <http://www.rfc-editor.org/info/rfc3596>.

7.2.  Informative references

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

   [PEN]      IANA, "Private Enterprise Numbers",
              <https://www.iana.org/assignments/enterprise-numbers>.

Appendix A.  This solution compared to doing this in DHCPv6/NDP [RFC
             Editor: please remove]

   The angle of attack of the MIF work to date (autumn 2015) has been to
   add container options and their transfer mechanisms to DHCPv6 and
   NDP.  This document details a different approach, and therefore it is
   sensible to compare it to to the existing solutions in terms of
   (highly subjective) pros and cons.  The authors consider pros of this
   proposal to be:

   o  No overhead for hosts that do not care (possibly most; no spurious
      RA options, ...)

   o  No problems with relaying data; if the first-hop device does not
      care, DNS requests propagate onward.

   o  Little/no changes to DHCP, DHCPv6, DHCPv6-PD or RA.

   o  Much more scalable; no worries about multicast packet size limits.

   o  No duplication of specifications / TLVs for DHCP, DHCPv6 and RA.

   o  Solves m:n prefix <-> PVD elegantly: no need to either duplicate
      applying prefix for each PVD or duplicate each PVD for each
      applying prefix.



Stenberg & Barth         Expires April 17, 2016                [Page 11]


Internet-Draft               MPVD using DNS                 October 2015


   o  Easily extensible (TXT records, no TLV definitions, parsing and
      generation necessary)

   o  Probably not affected by IPR on draft-ietf-mif-mpvd-dhcp-support

   o  Reuses the existing reverse DNS infrastructure

   The authors consider cons of this proposal to be:

   o  This scheme requires DNS servers 'close' on the path to the user,
      if changed information is to be sent; otherwise centralized
      solution would work (with some synthesized records).

   o  Security using either DNSSEC or in-band hashes is rather painful
      (but possibly not more than the scheme in the current DHCP/RA
      drafts), so the default would most likely be insecure.  That is
      not much different from DHCP*/RA, which are also 99.999...% of the
      time not secured.

Appendix B.  Discussion Points [RFC Editor: please remove]

   o  Besides special purpose prefixes, it might be desirable to have
      special purpose routers which only provide access to certain
      services but not the entire internet.  These services could be
      announced by only using more-specific routes, however if the
      destination addresses are possibly changing, extension of the RIO
      mechanism might be needed.  One possibility would be to add a new
      RIO S-flag with semantics like: "When the host receives a Route
      Information Option with the S-Bit set, it MUST ignore the value in
      the Prf-field (even if it is (10)) and instead assume the
      preference to have a value greater than (11).  However, it MUST
      only use the route for packets having a source prefix announced by
      the same router.".  This would allow selective routes (Prf=(10))
      only applying to MIF-hosts.

   o  DNSSEC delegation of reverse zones might be difficult in some
      cases.  It is debatable, whether we want a complementary in-band
      signing mechanism as well, e.g., pre-shared public keys associated
      the domain name of the TXT records and "sig-X=..." keys (where X
      identifies the specific key) and ... is an EdDSA or ECDSA
      signature over all records not starting with "sig-".  Care would
      need to be taken wrt.  TTL and negative caching though.

   o  Should PVD-aware hosts be recommended or even required to always
      prefer routers that announced the respective source address in a
      PIO over those that didn't when making routing decisions?  This
      takes on the points made in draft-baker-6man-multi-homed-host.




Stenberg & Barth         Expires April 17, 2016                [Page 12]


Internet-Draft               MPVD using DNS                 October 2015


Appendix C.  Changelog [RFC Editor: please remove]

   draft-stenberg-mif-mpvd-dns-00:

   o  Initial version.

Appendix D.  Draft Source [RFC Editor: please remove]

   As usual, this draft is available at https://github.com/fingon/ietf-
   drafts/ in source format (with nice Makefile too).  Feel free to send
   comments and/or pull requests if and when you have changes to it!

Appendix E.  Acknowledgements

   Thanks to Eric Vyncke for the original idea of using DNS for
   transmitting PVD information.

Authors' Addresses

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi


   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org


















Stenberg & Barth         Expires April 17, 2016                [Page 13]


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