Re: [v6ops] RFC7084

Owen DeLong <owen@delong.com> Wed, 11 December 2013 18:52 UTC

Return-Path: <owen@delong.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96561ADF79; Wed, 11 Dec 2013 10:52:40 -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 zWrMjThqXh-a; Wed, 11 Dec 2013 10:52:40 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 090E21ADF74; Wed, 11 Dec 2013 10:52:39 -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 rBBIpJS5024344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Dec 2013 10:51:20 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBBIpJS5024344
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386787880; bh=yAmQhuJgAJ7o9/8Tx96nkBTGJQg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jxJ9MwuWaulBWdUNv+iYkWdciTrIDoyPVzWvDjnKwHmhUD+l1ob8R1BV9aV/5KYmm kScbmxFqNQT4YAN/L+u+prX+pOp6vIMCChwIiaQGFWv5sjU02sVNnp9oyaqjNSxiv7 0DI60cn4Ye+V/5foBDTG5jRjlHzCKDZSUl/1SC3U=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: [v6ops] RFC7084
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52A83C92.4020204@gmail.com>
Date: Wed, 11 Dec 2013 10:51:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1A3DD00-96D8-4D73-B5F1-1CA705196689@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>
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]); Wed, 11 Dec 2013 10:51:20 -0800 (PST)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 18:52:41 -0000

On Dec 11, 2013, at 2:21 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

> Le 11/12/2013 11:08, Erik Kline a écrit :
>>> Am I the only to read this as maybe a hint towards necessity of
>>> creation of a new flag akin to M/O but specific to IA_PD? I.e. it
>>> would be allow a Router to see whether it may be able to
>>> specifically request a Delegated Prefix even when it would
>>> self-configure its address by other means than DHCP.
>> 
>> I'm not sure I understand how's that materially different/better
>> than a node just trying to request a PD if it wants one, and coping
>> with the response (whatever it may be), like it does today.
> 
> Well, as you suggest below, it may save some bytes on the wire, i.e.
> would not send the expensive Solicit if the preceding RA said no PD
> available.

I hardly think that an RS packet could legitimately be called “expensive”.

It’s a relatively small multicast datagram.

> I suppose this is the same reason of presence of other flags in the RA,
> like the H (HMIPv6) and P (PMIPv6).

As near as I can tell, those flags are for capabilities that are:

	1.	unlikely to be present on the majority of networks
	2.	would be much more difficult/expensive to negotiate without
		information in the RA.

The P flag isn’t alone in the RA, it’s also accompanied by a MAP option
in the RA that provides information about the MAP.

Owen