Re: [homenet] Medius: additional DHCPv6 (PD) options needed?

Ted Lemon <mellon@fugue.com> Mon, 05 August 2013 14:37 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1623A21F9D1B for <homenet@ietfa.amsl.com>; Mon, 5 Aug 2013 07:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SClxLImIpvQk for <homenet@ietfa.amsl.com>; Mon, 5 Aug 2013 07:37:33 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D33E621F9F08 for <homenet@ietf.org>; Mon, 5 Aug 2013 07:37:32 -0700 (PDT)
Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 96FDF2380867; Mon, 5 Aug 2013 10:37:31 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CE2577F0.16ED3%c.grundemann@cablelabs.com>
Date: Mon, 05 Aug 2013 10:37:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <299A6036-19CD-4C54-BC85-143D43B5BDBB@fugue.com>
References: <CE2577F0.16ED3%c.grundemann@cablelabs.com>
To: Chris Grundemann <C.Grundemann@cablelabs.com>
X-Mailer: Apple Mail (2.1508)
Cc: "homenet@ietf.org Group" <homenet@ietf.org>, Michael Richardson <mcr@sandelman.ca>
Subject: Re: [homenet] Medius: additional DHCPv6 (PD) options needed?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 14:37:39 -0000

I think the configuration model here needs more thought.   The hipnet document talks about heuristics for figuring out that it's at the edge, but e.g. the /48 heuristic seems like it won't work.

What I would like to see is something like Fred Baker's draft (draft-baker-homenet-prefix-assignment-01), for any router that could be a CER.   Fred's document has a few omissions that would need to be dealt with:

(1) It doesn't describe how DHCP relay works.   A non-CER relays to the CER, the IP address of which it got in the CER option.   If the non-CER knows of more than one CER, it relays to all CERs.
(2) A router can be both CER and non-CER, in a multihoming situation, in which case it both answers and relays all DHCP messages.   This is slightly weird, but the DHCP protocol allows multiple servers to respond, so it should be okay.
(3) routers that get multiple offers of different prefixes have to configure both prefixes, not just one, so that multihome prefixes propagate into the network.   This is not what RFC3315 and RFC 3633 advise; doing what they advise will result in a network that is multihomed at the edge, but not in the center.
(4) routers that relay DHCP messages sniff for routes on the replies, and use them to populate their routing tables.
(5) Fred's draft suggests that two routers advertising prefixes on the same link is an error, and that one of the routers needs to let the other win, but this misses the dual-home dual-CER case, where the prefixes being advertised are from different providers.   So the draft needs to be narrowed to the case where both prefixes come from the same provider, which probably means that prefixes need to be labeled as to the provider with a new DHCP option.
(6) I'm probably missing some routing subtlety here.

This sounds complicated, but I think it's simpler than it sounds.   However, I think the current state of the CER and hipnet specs is _too_ simple, and will not actually work.   You have to solve the problem that Fred's draft solves, and Fred's draft is actually pretty close.