IETF Logo Mail Archive

Re: [v6ops] DHCPv6 vs ND strikes again

"Brzozowski, John" <John_Brzozowski@Cable.Comcast.com> Fri, 22 October 2010 18:04 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 09D3E3A6936 for <v6ops@core3.amsl.com>; Fri, 22 Oct 2010 11:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.713
X-Spam-Level:
X-Spam-Status: No, score=-107.713 tagged_above=-999 required=5 tests=[AWL=0.150, 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 G0L19TsoeGIB for <v6ops@core3.amsl.com>; Fri, 22 Oct 2010 11:04:12 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 692BB3A68A4 for <v6ops@ietf.org>; Fri, 22 Oct 2010 11:04:12 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.101185069; Fri, 22 Oct 2010 14:05:45 -0400
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Fri, 22 Oct 2010 14:05:45 -0400
From: "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
To: Ole Troan <ot@cisco.com>, "Brian E. Carpenter" <brian.e.carpenter@gmail.com>
Thread-Topic: [v6ops] DHCPv6 vs ND strikes again
Thread-Index: AQHLcaIzGAgvL+p1b0efThcxErp8n5NNREiA
Date: Fri, 22 Oct 2010 18:05:45 +0000
Message-ID: <C8E74AC5.2AF55%john_brzozowski@cable.comcast.com>
In-Reply-To: <BF19AF42-62D0-4C9E-BDB2-1AC759881879@cisco.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: <AA945616491DC548AA879B13370A0576@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: Fri, 22 Oct 2010 18:04:14 -0000

On 10/22/10 12:32 AM, "Ole Troan" <ot@cisco.com> 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.
> 
> but it is the IETF business how our protocols work.
> where in rfc3633 is this behaviour specified?
[jjmb] what do you mean?  You yourself cited the text in RFC3633 where the
prefix size hints can be used?
> 
>>>> 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.
> 
> so creating two protocols doing exactly the same thing is a good thing?
[jjmb] are you saying that draft-hu-pppext-ipv6cp-requirements == RFC3633?
> 
> cheers,
> Ole
> 

=========================================
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