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

>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 https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05 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 [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Thursday, September 15, 2016 4:23 AM
To: Dan Seibel <Dan.Seibel@TELUS.COM>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] testing PD availability (was: two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue)

Hi,

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"?

Alex

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 
>> <alexandru.petrescu@gmail.com> 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@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg