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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 18 October 2017 14:06 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 19B971321A1 for <dhcwg@ietfa.amsl.com>; Wed, 18 Oct 2017 07:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 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, URIBL_BLOCKED=0.001] 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 bASMsq9pnwMI for <dhcwg@ietfa.amsl.com>; Wed, 18 Oct 2017 07:06:20 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B6207132125 for <dhcwg@ietf.org>; Wed, 18 Oct 2017 07:06:19 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v9IE6FQD029442; Wed, 18 Oct 2017 16:06:15 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 92C21206804; Wed, 18 Oct 2017 16:06:15 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 856612020B7; Wed, 18 Oct 2017 16:06:15 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v9IE6ClP021159; Wed, 18 Oct 2017 16:06:15 +0200
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
References: <149869621720.6575.278128190348174876@ietfa.amsl.com> <08e4e953-3a68-d6cb-6066-f60514ef0ac5@gmail.com> <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com> <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com> <37917a26062f4e4c9715d324604e4d01@XCH-ALN-003.cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <d944ac55-d67d-d7d4-8eeb-f60438fdda2d@gmail.com>
Date: Wed, 18 Oct 2017 16:06:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <37917a26062f4e4c9715d324604e4d01@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/lnXFhOa3cXOTR6XYE1r5o3YUWWw>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA
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: Wed, 18 Oct 2017 14:06:23 -0000

Bernie,

Le 13/07/2017 à 19:38, Bernie Volz (volz) a écrit :
[...]

> Regarding Link Local vs GLA in Solicit, I think following the 
> specification would be recommended. Use link-local.

But the I-D 3315bis says this:
> Clients and servers exchange DHCP messages using UDP [RFC0768].  The
>  client uses a link-local address or addresses determined through 
> other mechanisms for transmitting and receiving DHCP messages.
   ^^^^^^^^^^^^^^^^

This "other mechanisms" means that a GUA generated with SLAAC could be
used as an src in a DHCPv6 Solicit.


[...]
> Note also that section 13.1 (for the unicast, GLA case) assumes the 
> message was not multicast (section 18.4 about UseMulticast Status 
> talks about "Reception of Unicast Messages").

Hm, that lokks like a relatively less explicit if not outright silent 
assumption(?)  Or maybe I did not look well enough in the I-D?

There is a particular equipment manufacturer's simulator software, and 
potentially real hardware, that uses GUA in src and dst multicast with 
link scope ff02::1:2.547, in the DHCPv6 Solicit.

If this behaviour is standard (src GUA and dst ff02::1:2) then it should 
be in the draft.  If it's not standard: it should get corrected in the 
simulated and in the real implementation.

Because other software than the one from the particular equipment 
manufacturer uses src LL and dst ff02::1:2.

Side note:

> I think section 13.1 was written with the assumption that determining
> the destination address of a packet is harder than obtaining the
> source address; hence the assumption is that if a GLA is used as the
> source address, it was not a multicast [to the link-local multicast
> address]. Today, kernels typically provide the ability to get the
> destination address, not just the source address (though it takes a
> bit more code to do so).

The picture may be different on point-to-point links like cellular 
links.  It's multicast, but it's just two nodes and they are always 
seeing each other.  Besides, one of the nodes allocates an address to 
the other node by other means than SLAAC, and it knows it.

Alex

> 
> 
>> I can say e.g. some (I believe Cisco) client puts a GUA in the src
>>  of aDHCPv6 Solicit.
> 
> That's a bit of a broad statement as Cisco has many different devices
> (and many different operating systems and versions) ... perhaps if
> you could indicate which device(s) and software versions you've found
> this to be the behavior on, I can perhaps follow up.
> 
> I will also add that in many cases when devices are doing DHCPv6, 
> they will only have a LL so it may also depend on the network 
> configuration.
> 
> - Bernie
> 
> -----Original Message----- From: Alexandre Petrescu 
> [mailto:alexandre.petrescu@gmail.com] Sent: Thursday, July 13, 2017 
> 12:01 PM To: Bernie Volz (volz) <volz@cisco.com> Cc: dhcwg@ietf.org 
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - 
> questions about Solicit Prefix Delegation
> 
> 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
>