[mif] New Version Notification for draft-stenberg-mif-mpvd-dns-00.txt

internet-drafts@ietf.org Thu, 15 October 2015 11:22 UTC

Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: internet-drafts@ietf.org
Resent-From: Markus Stenberg <markus.stenberg@iki.fi>
Date: Thu, 15 Oct 2015 04:11:34 -0700
Content-Transfer-Encoding: quoted-printable
Resent-Date: Thu, 15 Oct 2015 14:21:57 +0300
Resent-To: "mif@ietf.org List" <mif@ietf.org>
Message-Id: <20151015111134.31835.34636.idtracker@ietfa.amsl.com>
To: Markus Stenberg <markus.stenberg@iki.fi>, Steven Barth <cyrus@openwrt.org>
Resent-Message-Id: <20151015112158.BB90D1B2B32@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/cqAFMFYWsHpKL317YbvNWZ6Yud8>
Subject: [mif] New Version Notification for draft-stenberg-mif-mpvd-dns-00.txt
Precedence: list

Here’s our (mine and Steven’s) proposal on how to transfer PVD data. 

Here’s pros and cons of our design from the appendix of the draft:

— snip —

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.

— snip —

Cheers,

-Markus and Steven


A new version of I-D, draft-stenberg-mif-mpvd-dns-00.txt
has been successfully submitted by Markus Stenberg and posted to the
IETF repository.

Name:		draft-stenberg-mif-mpvd-dns
Revision:	00
Title:		Multiple Provisioning Domains using Domain Name System
Document date:	2015-10-15
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-stenberg-mif-mpvd-dns-00.txt
Status:         https://datatracker.ietf.org/doc/draft-stenberg-mif-mpvd-dns/
Htmlized:       https://tools.ietf.org/html/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.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

[mif] New Version Notification for draft-stenberg… internet-drafts