Re: [dhcwg] testing PD availability (was: two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue)

"Bernie Volz (volz)" <> Fri, 14 October 2016 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEDBB1298B7 for <>; Fri, 14 Oct 2016 13:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.517
X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5nKElVau52Ip for <>; Fri, 14 Oct 2016 13:34:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C6EF129442 for <>; Fri, 14 Oct 2016 13:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5520; q=dns/txt; s=iport; t=1476477244; x=1477686844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dmnQaxLFRv+vSzELthOP/TQVhN+15IhkAfForsNf0CU=; b=Qrd6X5K8DQNggsHk4DIQ+KPWj+b9Rc3ZzfE+XtxkKfmZAF2CQfneoYL3 a3PVjZDlZ9KEMWj2nZhPge43rUnBz31Ei+n98qoT04zqnEXdv1ifQBfVW hgAc7Yl8GlOG4NZ73tSzXFk68mRSjo6DfJAyr2IouPFo9fl2oXKmCFcnh g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,346,1473120000"; d="scan'208";a="334041912"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2016 20:34:03 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9EKY36A014779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Oct 2016 20:34:03 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Oct 2016 15:34:02 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 14 Oct 2016 15:34:02 -0500
From: "Bernie Volz (volz)" <>
To: Alexandru Petrescu <>, Dan Seibel <Dan.Seibel@TELUS.COM>
Thread-Topic: [dhcwg] testing PD availability (was: two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue)
Thread-Index: AQHSDyp0fX+NWIdU8kK/INmb9CR5J6CokWEQ
Date: Fri, 14 Oct 2016 20:34:02 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [dhcwg] testing PD availability (was: two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Oct 2016 20:34:07 -0000

>What would be the behaviour with a legacy no-PD server? will it crash? timeout no reply? reply "Noaddrsavail"?

I'm not sure what you mean by a legacy no-PD server?

The draft doesn't add anything about new PD servers; IA_PD and related was defined in RFC 3633 long ago.

If a server that receives an IA_PD (with or without a prefix hint) doesn't support IA_PD at all, I would think it would ignore the option. If there's an IA_NA/IA_TA in the client's request, the server would process it. If there was only IA_PD, it would likely consider the request not including an IA_* option - perhaps dropping it, returning UnspecFail, or perhaps a mostly empty Reply. I don't think this behavior is clearly spelled out in 3315, 3633, or later. It might be a question for the 3315bis document and whether there should be some clarity around this (note that behaviors for Solicit, Request, Renew, and Rebind would have to be considered).

In the document, section 17.2.9 has:

   If the Solicit message from the client included one or more IA
   options, the server MUST include IA options in the Advertise message
   containing any addresses and/or delegated prefixes that would be
   assigned to IAs contained in the Solicit message from the client.

>From this, it is clear that servers should process the known IA_* so for server compliant to that document, it SHOULD really support IA_PD though of course further in that section it would follow the "If the server is not going to assign an address or delegated prefix ..." case.

And, there is no specific text that I could locate that says anything about what happens if there are no "IA_*" options at all or none that the server supports.

The document assumes that the server knows about IA_NA, IA_TA, and IA_PD options -- though of course the server is allowed to indicate it will not assign any.

I will add something about this issue to the list of WGLC issues related to the rfc3315bis document so that the author team will discuss it (of course, anyone is free to comment on the mailing list or to the authors).

If the server crashes, that would obviously be something that would need to be fixed as it is clearly a denial of service attack.

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Alexandru Petrescu
Sent: Thursday, September 15, 2016 4:23 AM
To: Dan Seibel <Dan.Seibel@TELUS.COM>
Subject: Re: [dhcwg] testing PD availability (was: two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue)


We wrote a test client looking whether PD is available in the network, by sending a IA_PD in a Solicit; and run it against KEA and ISC servers.

If the PD knob unset at the server, both responded a Status Code "NoPrefixAvail (6)", wireshark display.  Textually, ISC says Status Message "No prefixes available for this interface" whereas KEA says "Sorry, no subnet available".  What interface?  And why a 'subnet' when what is asked is a 'prefix'?

Even though it's negative, there is a reply.  It is because these servers have such a PD option.

What would be the behaviour with a legacy no-PD server? will it crash?
timeout no reply? reply "Noaddrsavail"?


Le 23/07/2015 à 14:54, Dan Seibel a écrit :
> For #1 I would think sending a solicit with IA_PD is how you can find 
> out if the server supports it.  If it does you will get a prefix 
> returned, if not you will get a Noaddrsavail for the IA.
>> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu 
>> <> wrote:
>> Hello,
>> I just read draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.
>> I am happy this draft exists and I have two comments.  One is more  
>> general question in this context, and the other a potential 
>> improvement, but not a request.
>> The draft assumes the Client is a Host which may request a prefix len 
>> at some point, and another one maybe later.  It seems the prefix is 
>> to be used on the interface which has issued that Solicit.  And it 
>> seems to face a Server sure to be willing to deliver a prefix.
>> 1. What is the best way to query a DHCPv6 Server to ask it whether or 
>> not it supports Prefix Delegation at all?
>> 2. when this Router changes mind and requests a different prefix, 
>> maybe with a different length, a specification like 
>> draft-cui-dhc-dhcpv6-prefix-length-hint-issue could recommend to 
>> deprecate that prefix with specific consideration to below it, not 
>> just to the Server.
>> I mean this something like this:
>> Current text:
>>> 1.Deprecate the old prefix right away by sending a Release message 
>>> to the server, and switch over to the new prefix.
>> New text:
>>> 1.Deprecate the old prefix right away by sending a Release message 
>>> to the server, and switch over to the new prefix.  And by stopping 
>>> sending RAs on its other interfaces with the old prefix, stop 
>>> propagating it in the routing protocol.
>> Alex
>> _______________________________________________ dhcwg mailing list  

dhcwg mailing list