Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt

James Carlson <carlsonj@workingcode.com> Mon, 08 February 2010 18:42 UTC

Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2127E28B56A for <pppext@core3.amsl.com>; Mon, 8 Feb 2010 10:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6OhZyvyVlej for <pppext@core3.amsl.com>; Mon, 8 Feb 2010 10:42:33 -0800 (PST)
Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 306C73A71DD for <pppext@ietf.org>; Mon, 8 Feb 2010 10:42:32 -0800 (PST)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o18IhQfY026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 13:43:27 -0500 (EST)
Message-ID: <4B705B4E.6030405@workingcode.com>
Date: Mon, 08 Feb 2010 13:43:26 -0500
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>, jhuang1@att.com
References: <00b801caa542$5d9daec0$18d90c40$@net>
In-Reply-To: <00b801caa542$5d9daec0$18d90c40$@net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-DCC-dmv.com-Metrics: carlson; whitelist
Cc: pppext@ietf.org
Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2010 18:42:34 -0000

Glen Zorn wrote:
> FYI

Thanks for forwarding.

> 	Title           : IPv6CP Options for PPP Host Configuration
> 	Author(s)       : J. Huang
> 	Filename        : draft-huang-ipv6cp-options-00.txt

We've had the same proposal come up -- and get shot down -- multiple
times in the past.  Please search the archives.  There's plenty of
detail available in the archives to describe why these ideas don't
actually work well in deployment and are fundamentally unnecessary.

In short, PPP is a link layer protocol.  It negotiates only what's
necessary to make the link itself work and prevent obvious sorts of
misconfigurations in the the link.

It does not (and should not be expected to) negotiate for arbitrary
network and application level parameters that might help your system
function.  It doesn't make any more sense to do that than to (say) build
DNS server negotiation into Ethernet.

The commonly accepted mechanisms are:

2.1 through 2.4: prefixes and default gateway addresses are acquired via
IPv6 Router Discovery RS/RA messages.  These mechanisms already exist
and are used on numerous platforms.

2.5 and 2.6: these are already doable with DHCPv6 Information; there's
no need to build it into PPP.

2.7 and 2.8: prefix delegation requires mechanisms in other protocols,
such as DHCPv6 and Router Discovery.  Looking there for common
link-layer agnostic answers is likely the best answer.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>