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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 13 July 2017 17:38 UTC

Return-Path: <volz@cisco.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 25E281300CF for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 10:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 j44l8brSd_Bf for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 10:38:24 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B4F12F257 for <dhcwg@ietf.org>; Thu, 13 Jul 2017 10:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8088; q=dns/txt; s=iport; t=1499967504; x=1501177104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NB5WLNsuafM7aKSioEviVK2bY++1vXlH15KWcmXPXGE=; b=Mps1mNddMiyDfG4R1AHtua8uwMj9TVa2fSLoz/B3jzTuCJqLJ0MHGaFc aV5b7Fo9R5v3qeNikwVyySgh2fFEJU/ArAwkl/NGBgESBHSemV7pvUj8c ArMoN7qaV8VvGT2YGMYplfYb12zB3WS7FSgQj9YSkACyPRqxYDzEgZULI E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAAAtr2dZ/5ldJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBeAeOApF2iC6NVYIRgjuDOwIag08/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEjEUUFBwQCAQgRBAEBAwIfBAMCAgIfERQBCAgCBA4FCIoPAw0Iry6CJoczD?= =?us-ascii?q?YNkAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2FLYMlgleBcA0tD4JtgmEFl0C?= =?us-ascii?q?HNTsCjyOEZpIyjAiJTAEfOIEKdRWFXBwZgU52hk+BMYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,354,1496102400"; d="scan'208";a="267804404"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 17:38:23 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6DHcNU7021965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jul 2017 17:38:23 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Jul 2017 12:38:22 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 13 Jul 2017 12:38:22 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
Thread-Index: AQHS9arXA8HVoh8yrE6qal+jjpOQE6JQvX5QgAGNVYD//8L84A==
Date: Thu, 13 Jul 2017 17:38:22 +0000
Message-ID: <37917a26062f4e4c9715d324604e4d01@XCH-ALN-003.cisco.com>
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>
In-Reply-To: <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.32.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/kWyhViM-Ai3Ww09EH1HutAc_BCI>
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 17:38:26 -0000

Regarding the hop limit, I don’t have a recommendation; I'd likely leave it be what the OS defaults it to if I were writing a client. I'm not sure I'd put this in the 3315bis specification, but the WG can debate that issue.

Note also that the server does not have an easy way to get the hop count (well, perhaps there is a way but the server I work on doesn't care what it is) and therefore I doubt any of them check.


Regarding Link Local vs GLA in Solicit, I think following the specification would be recommended. Use link-local. For things that use GLA, likely it doesn't matter since if the Solicit is relayed and then the GLA isn't really used by the server -- as the link-address in the Relay-Forw. It may matter if the server is directly on link if it checks. I think that using differing scopes for source/destination addresses is a bad idea (and certainly sending with a source of LL and destination of GLA would be very bad). So, I think the client should stick to using the LL unless it is unicasting.

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").

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).


> 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