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

Ted Lemon <mellon@fugue.com> Thu, 13 July 2017 18:51 UTC

Return-Path: <mellon@fugue.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 9C853124234 for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 11:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 QJJbMwKP0f7e for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 11:51:48 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3093112F27C for <dhcwg@ietf.org>; Thu, 13 Jul 2017 11:51:48 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id u62so33734557pgb.3 for <dhcwg@ietf.org>; Thu, 13 Jul 2017 11:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xhEYy6di4TYPFqbKy7AoAXELKKboqZ88ntnlCZW3XS4=; b=fWXkOdOq6DE/zr6ktbZv15Yq8ipGctDY43Wmpr/fZ9Tny1nwWS52NlEuNaF5rm7NUC S3jlnnuC3ju444xaaxkY34jB0n2hR3y9MeEl2jgnmWNvhn8uoEvmceZldhdHlTkutOOB LIwof2pNpqvucZDqglxWpheq09Uiar2cobNBlpYwsa6OkHrDUzIr8+xpz21zhntefHsL RwtdH2DQod2lSFXppU0y+uFjAYTQtsoZXvNfx3wp++CWzQly+8vNzJVz7zhcRBt2Y2PQ jo/XGwgbBlCkVEF/fzxuzHHkFJXkQ0vBu7Eg6GNf+MzOov/8iLxC0pUwG6nGS4c8U1Bi H4Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xhEYy6di4TYPFqbKy7AoAXELKKboqZ88ntnlCZW3XS4=; b=Z3XFyJCT0I1Bx9BtqNlS7HxcTVBl41j2fRDe8yNySMbT9XvB5MFIMgEiAXZW0mFzAW W0F7gnd9CfllW7C77DqdC1pdlca5dpJRdx9a1y/ARrXBp5nyf0l2uy0KqGTCNidw2ZoP EvkVHcAVcfaF+wDp9yxcW8u++uCcOxhRgDcjE24+TKZ1LVM5MP8FEDjwwekyj6jVulKH 15rh3nW2zz73GlWoHYThhuUASQ2iPEGzkGA3xotPweFK8Q5KsR3TR9TSJxSvff4CZU1L 3dVddioZuGjGAhEWVT7975CcxSPdql+7ebSlBcxwiAA8KZYp/6P5ihsqDffPYOjhglHN XbVg==
X-Gm-Message-State: AIVw112COvjlVJDTMFMViXQ9j0Ejsu6fKL1ac01q6iJGb63/K6jSXtML EqSPdKoG6IZBvsnBP4nhvOUPOss9So0A
X-Received: by 10.98.42.4 with SMTP id q4mr1040565pfq.143.1499971907776; Thu, 13 Jul 2017 11:51:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Thu, 13 Jul 2017 11:51:47 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Thu, 13 Jul 2017 11:51:47 -0700 (PDT)
In-Reply-To: <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.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>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 13 Jul 2017 14:51:47 -0400
Message-ID: <CAPt1N1nCt9nW2VNczpSa0f8jSn4sMGdVcxpmUTywshJrPiSFtA@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="001a1145cd5ebc8ec80554376cf5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8H6rCmWq6hk63WVlScXhq6KQm2Q>
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 18:51:52 -0000

DHCP relay is an app layer encapsulation. The hop count isn't even
presented to the app layer. It would be bizarre to do anything special with
it. I don't even know how you would write coffee that would accidentally
get this wrong. So it shouldn't matter what hop count the client uses. Hop
count is only relevant at the routing layer.

On Jul 13, 2017 12:00, "Alexandre Petrescu" <alexandre.petrescu@gmail.com>
wrote:

> 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
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>