IETF Logo Mail Archive

Re: [v6ops] DHCPv6 vs ND strikes again

"Brzozowski, John" <John_Brzozowski@Cable.Comcast.com> Thu, 21 October 2010 22:45 UTC

Return-Path: <john_brzozowski@cable.comcast.com>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6194F3A63CA for <v6ops@core3.amsl.com>; Thu, 21 Oct 2010 15:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.667
X-Spam-Level:
X-Spam-Status: No, score=-107.667 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 vszjOZMgpVuO for <v6ops@core3.amsl.com>; Thu, 21 Oct 2010 15:45:35 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1C7313A67A4 for <v6ops@ietf.org>; Thu, 21 Oct 2010 15:45:35 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.100962936; Thu, 21 Oct 2010 18:46:57 -0400
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Thu, 21 Oct 2010 18:46:56 -0400
From: "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
To: "Brian E. Carpenter" <brian.e.carpenter@gmail.com>, Ole Troan <ot@cisco.com>
Thread-Topic: [v6ops] DHCPv6 vs ND strikes again
Thread-Index: AQHLcV4d775YCTTaj0KZPXL4p8GjopNMID2AgAAHCID//9m0gA==
Date: Thu, 21 Oct 2010 22:46:55 +0000
Message-ID: <C8E63B1D.2AC11%john_brzozowski@cable.comcast.com>
In-Reply-To: <4CC0AABD.6060207@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.6.0.100712
x-originating-ip: [147.191.125.12]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DF2525C9EF3D2F43911A787407E7FF69@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] DHCPv6 vs ND strikes again
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 22:45:36 -0000

On 10/21/10 5:03 PM, "Brian E. Carpenter" <brian.e.carpenter@gmail.com>
wrote:

> On 2010-10-22 09:38, Ole Troan wrote:
>> Brian,
>> 
>>>>>> Providing the hint does not guarantee that the operator will always honor
>>>>>> the hint.  This, however, is a step in the right direction to ensure the
>>>>>> IGD
>>>>>> is offered an appropriately sized IPv6 prefix.
>>>>> my assumption is that residential customers get the same address block
>>>>> size
>>>>> independent of what their actual need is.
>>>> [jjmb] at this time I do not share this assumption, I may over time.  I
>>>> also
>>>> not sure if this a universally accepted assumption.
>>> Absolutely not. It's entirely a matter between the customer and the ISP.
>>> The ISP might choose to offer a one-size-fits-all model or a user-chooses
>>> (and pays) model. This is emphatically not the IETF's business, beyond
>>> what is said in draft-ietf-v6ops-3177bis-end-sites.
>> 
>> certainly, and I didn't imply anything else.
>> DHCP PD does indeed contain a prefix length, but it is not suitable as a
>> protocol to negotiate the size of an address block.
>> 
>> what do you gain from doing dynamic address block size negotiations between
>> RR and DR?
>> as opposed to the customer getting whatever address block size he desires
>> when buying the service?
> 
> I tend to agree, but again, that's not IETF business.
[jjmb] +1
> 
>>> In our protocols, prefix length clearly needs to be a parameter
>>> (as it is in draft-hu-pppext-ipv6cp-extensions, for example).
>> 
>> so now we are not only going to replicate all functions between DHCPv6 and RA
>> options, but also for IPv6CP? that appears to be a bad idea.
> 
> Well, there are arguments about why this is needed from an operational
> viewpoint
> in draft-hu-pppext-ipv6cp-requirements. I guess they should be discussed
> on the pppext list.
> 
>      Brian

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

v2.23.0 | Report a Bug | By Email