Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

Daniel Migault wrote:
> Hi,
>
> Please find the new version of DHCP Options for Homenet Naming 
> Architecture 
> <https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/>.
>
> The issue raised on the previous version was how these options were 
> compatible with multiple ISPs. This use case is illustrated in section 
> A. 4 multiple ISPs.
>
> BR,
> Daniel
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Tue, Feb 17, 2015 at 8:33 PM
> Subject: [homenet] I-D Action: 
> draft-ietf-homenet-naming-architecture-dhc-options-01.txt
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> Cc: homenet@ietf.org <mailto:homenet@ietf.org>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Home Networking Working Group of the 
> IETF.
>
>         Title           : DHCP Options for Homenet Naming Architecture
>         Authors         : Daniel Migault
>                           Wouter Cloetens
>                           Chris Griffiths
>                           Ralf Weber
>         Filename        : 
> draft-ietf-homenet-naming-architecture-dhc-options-01.txt
>         Pages           : 28
>         Date            : 2015-02-16
>
> Abstract:
>    CPEs are usually constraint devices with reduced network and CPU
>    capacities.  As such, a CPE hosting on the Internet the authoritative
>    naming service for its home network may become vulnerable to resource
>    exhaustion attacks.  One way to avoid exposing CPE is to outsource
>    the authoritative service to a third party.  This third party can be
>    the ISP or any other independent third party.
>
>    Outsourcing the authoritative naming service to a third party
>    requires setting up an architecture which may be unappropriated for
>    most end users.  To leverage this issue, this document proposes DHCP
>    Options so any agnostic CPE can automatically proceed to the
>    appropriated configuration and outsource the authoritative naming
>    service for the home network.  This document shows that in most
>    cases, these DHCP Options make outsourcing to a third party (be it
>    the ISP or any ISP independent service provider) transparent for the
>    end user.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-01
>
>
> 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 
> <http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org <mailto:homenet@ietf.org>
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> -- 
> Daniel Migault
> Ericsson
I finally got around to reading this draft. It's been on my todo list 
for some time,

It looks very good, but I am missing the detail of how a renumbering 
event would be handled.

Is that the same process as adding a new Homenet CPE?

Worst case would seem to be where a user chooses scenario A3, but the 
ISP initiates a renumbering event without warning/coordination (new PD 
prefix).

My understanding of the plumbing is that something like BIND running on 
the Public Authoritative Master(s)  (slaves) would be hard-coded with a 
fixed IP addresses pointing at the hidden master running on the Homenet.
Configuring multiple masters is possible in BIND, so that's not an 
insurmountable barrier, and it would be possible to run with both 
addresses from the old and new prefixes simultaneously, and let BIND 
work out which one was reachable.

But maybe if the NOTIFY process in Section 5.1.1 from the CPE to the 
Public Authoritative Master(s) anyway already contains the address from 
the new prefix, and the process already checks validity and reachability 
of the hidden master before replacing the old entry, then maybe there's 
no need to run with multiple masters for any overlapping time at all.

The timing intrigues me.

-- 
Regards,
RayH