MIF/MPVD using reverse DNS (and special purpose prefixes)

[Steven Barth <[e-mail]>]

Hey everyone,

Markus and I have been thinking about an alternative solution to do
multiple interfaces / multiple provisioning domains. Contrary to
previous solutions, this one only defines one additional (and even
optional) flag to RAs and keeps the actual information out-of-band.

This draft has some implications wrt. host behavior and multi-homing
so we are x-posting this here. Let us know if you have any comments
and if there is general interest we could request a slot as well.

Draft: https://datatracker.ietf.org/doc/draft-stenberg-mif-mpvd-dns/
Abstract & comparison to previous MIF approaches below.


Cheers,

Steven & Markus


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.



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.

   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.