Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

Ted Lemon <mellon@fugue.com> Tue, 12 November 2013 17:38 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC311E8142; Tue, 12 Nov 2013 09:38:33 -0800 (PST)
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 ZdbJq7YIzpqc; Tue, 12 Nov 2013 09:38:19 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DE97311E8138; Tue, 12 Nov 2013 09:38:18 -0800 (PST)
Received: from [IPv6:2001:470:88a3::b4f4:5f0a:2fa8:4a70] (unknown [IPv6:2001:470:88a3:0:b4f4:5f0a:2fa8:4a70]) by toccata.fugue.com (Postfix) with ESMTPSA id 87D932381D72; Tue, 12 Nov 2013 12:38:15 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <11836.1384276281@sandelman.ca>
Date: Tue, 12 Nov 2013 12:38:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <72351307-6AFD-4209-B04B-8025B544FC9A@fugue.com>
References: <11836.1384276281@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1822)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "homenet@ietf.org Group" <homenet@ietf.org>, "<radext@ietf.org>" <radext@ietf.org>
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 17:39:57 -0000

Historically this has been proposed to be done with a stateful BRAS that retains authentication information from the PPP client/RADIUS server authentication process, and provides that to the DHCP server using a relay option.   The DHCP server can then go to the RADIUS server to get prefix information if appropriate (although I would argue that this is unnecessary and probably harmful, since it requires static provisioning for all customers).

Have you looked at RFC 4014 and RFC 7037?

The reason for the state diagram in 4818 looking as it does is that the DHCP server has to know how it's going to respond to a request from the client before it sends its advertise message.   Since the prefix is statically configured on the RADIUS server, this shouldn't really be a problem.   If the RADIUS server were doing dynamic allocation, it would potentially be a problem since resources that are committed during the solicit/advertise phase ought to be freed if no request/reply phase follows.   I don't know enough about RADIUS to know if this ever happens, but it's my understanding that it does not.

Of course, the larger question here is, why the heck would you want to use PPPoE with all the MTU woes it brings into the picture?   I know the answers that are usually given, but I think this is something that ought to be treated as a less-preferred approach to delivering IPv6 service.