Re: [dhcwg] RFC 8415 question: unicast Information-request

Ted Lemon <mellon@fugue.com> Sun, 30 August 2020 13:58 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 C809C3A0969 for <dhcwg@ietfa.amsl.com>; Sun, 30 Aug 2020 06:58:21 -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, SPF_HELO_NONE=0.001, 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 fU7x3jMSI-2h for <dhcwg@ietfa.amsl.com>; Sun, 30 Aug 2020 06:58:20 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C87793A094E for <dhcwg@ietf.org>; Sun, 30 Aug 2020 06:58:19 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id n129so3944423qkd.6 for <dhcwg@ietf.org>; Sun, 30 Aug 2020 06:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AegPlfo8PoCK+mlwS6xs3Bkj2bEOmwDpMP01mw+5J5o=; b=ZXWyorVGsfnZYmCDiP5spSCY48Vmm7o+OPejbrpQGJPNX+OApo+tVI24PjzOULHc47 9OBamifQSNfgSslCanA/zOgyUGwQjJFTpNQBOC2czj1MM8UjYkCBFyGbUNjtBTuv5l9P n5RQgolFT7cxi9mM7gHDBQD3uKp9yrRTWoKfiwWcyJActl1WyTrioO0F3gnxX+L3Uj5V KZ78pj33T8mDIBA6ar1klNbVQO7rdlDAbT1yRxKKYqe33fKHqRP9SUFsF+41k8O+hw5J 2NHGYDFEhASc48GNIbzj+2Ht7pluqD8J0H8Uh0VuOhE6lZNaa7psVsIGSyvYBkwEwAp5 la5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AegPlfo8PoCK+mlwS6xs3Bkj2bEOmwDpMP01mw+5J5o=; b=i3X95/FoZMU2I5B8RXjC1X0dVvCQXSbJAMWDypjs1EnvhDxy2bPXfn1dCrFGf3LMxV Devu56BQBJHpCcmxblBtkStys+z4vimNRuLKo4h9QaEW3SPCZZT6ExCTKlbN2nlzwZkY CKLgoJli+lqfy3OohStO9WkMgXnWQtcPjHNX1VM04p4zlWXgAOwEdLy0Q2l2PpH3325o fPWBmX1kccHycIzscyy/FfJsyDT1OCxQKsNtJROCWoA2lnfQEYvTja9KxDSzG6G2rFm6 WzdxDlQl4/lIqrPxz+O2a21KSin3zFqB+5h4ELez83/QGOKBi4K56Wtg/fMkn2qzMvHd 9+0Q==
X-Gm-Message-State: AOAM533VyAFeUTDXgyMaAJVo0isPhWL35TWiipdYnO6hMj2SSaFBL5nb dhUKE9VYPmxx7meEUaJlbclk0X/LA1U1NI1J
X-Google-Smtp-Source: ABdhPJxE6A3Lm5k0O9vLU+rt8niyVynAcmLDE0tsVvN9ht4v8btMSDvDNDvyRMgx3c1QdEK5nyFL9Q==
X-Received: by 2002:ac8:19a6:: with SMTP id u35mr3966246qtj.315.1598795434796; Sun, 30 Aug 2020 06:50:34 -0700 (PDT)
Received: from localhost.localdomain ([2601:18b:300:36ee:7414:615d:ae62:c5e7]) by smtp.gmail.com with ESMTPSA id l95sm6419512qte.36.2020.08.30.06.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Aug 2020 06:50:34 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 30 Aug 2020 09:50:33 -0400
Message-Id: <B82AE983-FD32-4609-8C1B-9A023F54EFE7@fugue.com>
References: <85887c35-f8cb-c4b0-52a7-8abc111773f4@united-internet.de>
Cc: dhcwg@ietf.org
In-Reply-To: <85887c35-f8cb-c4b0-52a7-8abc111773f4@united-internet.de>
To: Felix Hamme <fhamme@united-internet.de>
X-Mailer: iPhone Mail (18A366)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/x80cmfTN8fpRViiN_RHNXes-zVg>
Subject: Re: [dhcwg] RFC 8415 question: unicast Information-request
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 30 Aug 2020 13:58:22 -0000

Yes. That’s the reason we did this. We want a client that does an information request to get the same answer as a client that asks for an address. 

> On Aug 30, 2020, at 04:15, Felix Hamme <fhamme@united-internet.de> wrote:
> 
> But does this apply to Information-request messages? Is a server allowed
> to include a Server Unicast option in a Reconfigure message when it also
> includes a Reconfigure Message option with msg-type 11 for
> Information-request message?
> Does a Server Unicast option in a Reply message allow a client to send
> subsequent Information-request messages to the unicast address of the
> server?
> 
>> On Aug 29, 2020, at 15:11 CEST Ted Lemon wrote:
>> The client can unicast if the server tells it to, using the Server Unicast option. The reason for this is to make sure that all DHCP packets transit the same infrastructure: if a client unicasts a packet to the server, it can reach the server via IP routing rather than DHCP relay, and may miss some information that needs to be collected about the network on the way to the server.
>> 
>>>> On Aug 29, 2020, at 5:55 AM, Felix Hamme <fhamme@united-internet.de> wrote:
>>> 
>>> Dear DHCPv6 experts,
>>> 
>>> 
>>> does RFC8415 permit Information-request messages with an IPv6 unicast
>>> destination address?
>>> 
>>> 
>>> Section 16 states:
>>> "A server MUST discard any Solicit, Confirm, Rebind, or
>>> Information-request messages it receives with a Layer 3 unicast
>>> destination address."
>>> (unicast Information-request forbidden)
>>> 
>>> Section 18.2 states:
>>> "If the client has a source address of sufficient scope that can be
>>> used by the server as a return address and the client has received a
>>> Server Unicast option (see Section 21.12) from the server, the client
>>> SHOULD unicast any Request, Renew, Release, and Decline messages to
>>> the server."
>>> (unicast Information-request not mentioned)
>>> 
>>> Section 18.4 states:
>>> "For example, unicast transmission is not allowed for Solicit, Confirm,
>>> and Rebind messages (see Sections 18.3.1, 18.3.3, and 18.3.5,
>>> respectively), even if the Server Unicast option (see Section 21.12) is
>>> configured. For Request, Renew, Information-request, Release, and
>>> Decline messages, it is allowed only if the Server Unicast option is
>>> configured."
>>> (unicast Information-request allowed if a Server Unicast option was
>>> received)
>>> 
>>> Appendix B ("informational") does not permit a Server Unicast option in
>>> a Reconfigure message.
>>> 
>>> 
>>> I am not sure how to interpret those statements in total.
>>> 
>>> When sending an Information-request message in response to a Reconfigure
>>> message, a client needs to include a Server Identifier option (see
>>> section 18.2.6) to address a specific server. It appears reasonable to
>>> me to permit a Server Unicast option in a Reconfigure message so that a
>>> client can respond with an Information-request message with an unicast
>>> destination address.
>>> 
>>> What if the Information-request message is sent after a
>>> Solicit-Advertise-Request-Reply message exchange, in which the server
>>> sent a Server Unicast option? May a client unicast Information-request
>>> messages in that case?
>>> 
>>> 
>>> Sincerely,
>>> Felix Hamme
>>> 
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>