Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 13 July 2017 16:00 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820F7126C2F for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 09:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 XvYtbtj88rsu for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 09:00:45 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F78D124BE8 for <dhcwg@ietf.org>; Thu, 13 Jul 2017 09:00:45 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6DG0ekn129091; Thu, 13 Jul 2017 18:00:40 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 71CF4205832; Thu, 13 Jul 2017 18:00:40 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 64220205563; Thu, 13 Jul 2017 18:00:40 +0200 (CEST)
Received: from [132.166.84.92] ([132.166.84.92]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6DG0dem010721; Thu, 13 Jul 2017 18:00:39 +0200
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <149869621720.6575.278128190348174876@ietfa.amsl.com> <08e4e953-3a68-d6cb-6066-f60514ef0ac5@gmail.com> <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Message-ID: <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com>
Date: Thu, 13 Jul 2017 18:00:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Z2NgElfh60q9UgnWO2SLDHH5Wo4>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jul 2017 16:00:47 -0000

Bernie,

Le 12/07/2017 à 23:33, Bernie Volz (volz) a écrit :
> Hi:
> 
>> What is the Hop Limit that a Solicit should contain in the IPv6 
>> header?
> 
> ND uses hop limit of 255 so the destination can check that it is 255 
> on receipt (whereas 1 could have been anything and forwarded many 
> times).
> 
> But I'm not sure if that is a the best practice when you don't want 
> the packet forwarded. I would think that if the destination is a 
> link-local multicast, it really doesn't matter as nothing should 
> forward the packet (and if something is misconfigured to forward the 
> packet, you're probably in deeper trouble than just with DHCPv6).
> 
> RFC 4861 has:
> 
> 11.2.  Securing Neighbor Discovery Messages
> 
> The protocol reduces the exposure to the above threats in the absence
> of authentication by ignoring ND packets received from off-link
> senders.  The Hop Limit field of all received packets is verified to
> contain 255, the maximum legal value.  Because routers decrement the
> Hop Limit on all packets they forward, received packets containing a
> Hop Limit of 255 must have originated from a neighbor.
> 
> I don't know off hand if there's any place this is documented (what 
> to use for hop limit with link-local).

I think your explanation makes sense about ND.

But, about DHCP, I need to know whether a DHCP Solicit with HopLimit 1
is valid or not.

As I said earlier, some DHCP clients set it at 255 whereas others at 1.

In some setting, the DHCP Solicit is encapsulated in IPv4.  Some of the
decapsulation RFCs say that the HopLimit is decremented.

In that setting, it is not clear whether decrementing the hop limit
happens, or not.

But I want to make sure the client which sets HopLimit at 1 (odhcp6c) is
the right way to do.

I think a good place to clarify this is in the DHCP spec.

The spec could say that the HopLimit has some preferred value.

>> Is IA_NA with empty fields a valid option in a Prefix Delegation 
>> Solicit, or must IA_NA be absent altogether? (the intention is to 
>> only request the Prefix, because the address comes from RA).
> 
> Not sure what an "empty" IA_NA is. Whether you include an IA_NA or 
> not with IA_PD is the client's choice. If it what's an address (such 
> as for management) on the upstream link, than it should include an 
> IA_NA. This is covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD 
> and IA_NA, typically).

Noted.

>> Is ORO with empty fields illegal in a Prefix Delegation Solicit? 
>> (the intention is to get the DNS server from RA, but some client 
>> puts an empty ORO there).
> 
> An empty ORO is fine (it should not cause problems, but is obviously 
> useless). Though if they are following the rfc3315bis and doing what 
> they should, there would not be an empty ORO.

Noted.

>> Is it ok to use a GUA in the src address of a Solicit Prefix 
>> Delegation?
> 
> See 13.1 of draft-ietf-dhc-rfc3315bis-09 ... the source address here 
> should be link-local.

Well, that contradicts some trial.

I can say e.g. some (I believe Cisco) client puts a GUA in the src of a
DHCPv6 Solicit.  Other DHCP clients have this optional between LLA or
GUA.  The operator I work with wants it to be a GUA.

As such, I dont know what is the way forward: should the spec get
updated?  shoudl the operator change?  should the Cisco implementation
change?

Alex