Re: [v6ops] IA_PD bit in RA (was: RFC7084)

Owen DeLong <owen@delong.com> Fri, 13 December 2013 15:52 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106FE1ADFC8; Fri, 13 Dec 2013 07:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.992
X-Spam-Level:
X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-6-bYWrf-fX; Fri, 13 Dec 2013 07:52:52 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 043F51ADBF7; Fri, 13 Dec 2013 07:52:51 -0800 (PST)
Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDFnPeU013261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 07:49:26 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDFnPeU013261
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386949767; bh=O18QQIFNg89bucUSfxqLfwUcjtY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L6Pisi+bW2IQ3GsJsmfT2ECtKnRl9CA7iNjxZPqbTTLHV/pJYqaPcBRIz5AycBHpG jmhkvRpMIyuhiLt+18xRF0/l4R1rdiBQ12HdsAUaYxaFc6XLT6u6ahsDyBbsqdjQLE MeR6Q9foW6wews2S2TgEI8jODBnAqbBhMk5RyCkU=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52AAEDDA.6010504@gmail.com>
Date: Fri, 13 Dec 2013 07:49:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <FED11C95-5D12-410E-8D8C-CB8A9F5D79C1@delong.com>
References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se> <F92E1B55-C74B-400C-B83E-6B50D175D121@steffann.nl> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <A583EFC3-71BB-4962-875C-4AB775D13491@delong.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <CAAedzxq6ym-uZJQVC7JTMgKnETpGiNt3JCmkJeGW2MVnw+sixA@mail.gmail.com> <52A83C92.4020204@gmail.com> <A1A3DD00-96D8-4D73-B5F1-1CA705196689@delong.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1822)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 07:49:27 -0800 (PST)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: Re: [v6ops] IA_PD bit in RA (was: RFC7084)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Dec 2013 15:52:53 -0000

On Dec 13, 2013, at 3:22 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

> Le 12/12/2013 20:05, Owen DeLong a écrit :
>>> (should the RA provide the delegated prefix as well to compare favorably
>>> to the PMIP example? but again this is the 'what if' branch, deviating
>>> from the main CPE discussion)
>> 
>> I don’t think anyone really wants to move PD into RA. I think that would
>> be inappropriate, personally.
>> 
>> Without moving the PD functionality into RA, then, I would say that the
>> current situation is fine.
>> 
>> CPE should ask for PD if it wants a prefix.
>> It should deal with one of five possible results in response:
>> 
>> 1.No response
> 
> As one senses it, implementing it is not easy.
> 
> How would one implement the decision 'no response' other than waiting for one a certain amount of time?  That wait is what makes people think it takes too long, especially mobile people.

Treat it as no response until you get one. Really, what are you going to do differently after you get denied a prefix (assuming a model of active denial like you suggest) than you can do while you’re waiting and haven’t yet received a prefix?

Either way, you have nothing to delegate to your subordinate networks.

> 
> Alex
> 
>> 2.Denial
>> 3.Requested prefix size granted
>> 4.Longer prefix (smaller net block) granted
>> 5.Shorter prefix (larger net block) granted
>> 
>> Nobody has yet made a good case for why this behavior is problematic.
>> 
>> Owen
>> 
>