Re: [dhcwg] recommendation on DHCP6 source port numbers
Ole Troan <otroan@employees.org> Thu, 29 February 2024 09:20 UTC
Return-Path: <otroan@employees.org>
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 827A5C151531 for <dhcwg@ietfa.amsl.com>; Thu, 29 Feb 2024 01:20:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIByPzpIIgaj for <dhcwg@ietfa.amsl.com>; Thu, 29 Feb 2024 01:20:27 -0800 (PST)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [204.87.183.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BDEC14F5EB for <dhcwg@ietf.org>; Thu, 29 Feb 2024 01:20:27 -0800 (PST)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id DED30E32F7; Thu, 29 Feb 2024 09:20:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=Vp7oc5K+8A6G2GTi HXjfT/UwzFclm1gjPFRfkaK29uI=; b=p/hmvADkJ5e/TkmdmsKjj/sRRdkWqrTc 4cjrckL8cO7S/Ms1m6x5cEwS+DqcCOgJz9Sc34JuQEQkm/AZiseDM7cAWxoMN7BE 39xloJMvu7fwX+Dt0v8M3yzC7ZTtXxWf9sdcpQGBEVBBS23Ct2Y1RjyTwTqgW4KO 58gtKtLwzudQ/yod26b1wUAE0+AaksRAhlxH7l75ixgckP+CBRxuGcJtRSKN3C66 gtpYUr4YjzRzgyXy+U3lIZqLELm5XK1YgQlZuMH44f1IPO4Ud/e5fQJ3TZEaEABh khGiPaL0IZHxXS42TizpeU9fKi7qMBhASBnUrABDgDsK3EHan4P2WA==
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id BB2F1E32E7; Thu, 29 Feb 2024 09:20:26 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2a02:20c8:5921:200:a85e:8f06:321e:2ff6]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id DD8384E11C77; Thu, 29 Feb 2024 09:20:25 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <20240229.170150.644022369405025541.tsahara@iij.ad.jp>
Date: Thu, 29 Feb 2024 10:20:12 +0100
Cc: Lorenzo Colitti <lorenzo@google.com>, Bernie Volz <bevolz@gmail.com>, dhcwg <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5D5C687-C17E-4856-B10A-F570845DE87F@employees.org>
References: <CB30D204-AC74-44EF-9002-8FEABF981B0F@gmail.com> <20240229.161925.1809625754663434930.tsahara@iij.ad.jp> <CAKD1Yr3Hwgu+dTxHB-1PQR2Qxz4bxLWP_0-q-MC4MEiM7j-FLw@mail.gmail.com> <20240229.170150.644022369405025541.tsahara@iij.ad.jp>
To: Tomoyuki Sahara <tsahara@iij.ad.jp>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/OaT1qqsXs3CsXByciW-ArTwnL4I>
Subject: Re: [dhcwg] recommendation on DHCP6 source port numbers
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <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, 29 Feb 2024 09:20:31 -0000
> It may be a violation. > But I think the RFC text is not crystal clear on that. Yes, I also think this is ambiguous. Cheers, Ole > >> Isn't b) a violation of the RFC? If a client sends a message from >> port 12345 to 547, then shouldn't the server send the message to >> destination port 546, since the RFC says "clients listen for DHCP messages >> on UDP port 546"? >> >> On Thu, Feb 29, 2024 at 4:19 PM Tomoyuki Sahara <tsahara@iij.ad.jp> wrote: >> >>> The clarification text should be helpful for new DHCP6 implementers >>> and network operators who write firewall rules. >>> >>> But when client/server received a request message from a random port, >>> which port should they send a response message to? There are two types >>> of implementations on the market (and on my desk): >>> >>> (a) returns to 546/547. >>> (b) returns to the source port of the request message. >>> >>> (a) follows the text in RFC8415 strictly. (b) follows normal UDP >>> communication rules. To interoperaate with both (a) and (b), we should >>> send request messages from the standard source port number 546/547. >>> That is not obvious and I think it is worth mentioning that in the spec. >>> >>> >>> Thanks, >>> Tomoyuki >>> >>>> Yes, I got it wrong. Been a while since that part of the code was done. >>>> >>>> I agree with Lorenzo: >>>> >>>> I do think the current text is ambiguous. In practice it allows >>>> arbitrary source ports, but because this is unusual, implementers might >>>> assume that the other side is using the same port to send and receive. >>>> Such an implementation might not interoperate. So if we think the >>>> behaviour is OK, then we should clarify the text to say that the source >>>> port is not specified and clients and servers need to be prepared to >>>> receive messages from arbitrary source ports. >>>> >>>> We do allow arbitrary source ports and as there are lots if >>> implementations >>>> in existence with that behavior, we should just clarify it: "The source >>>> port is not specified and clients, servers, and relay agents need to be >>>> prepared to receive messages from arbitrary source ports." >>>> >>>> - Bernie >>>> >>>> On Feb 28, 2024, at 3:28 AM, Lorenzo Colitti <lorenzo@google.com> wrote: >>>> >>>> FWIW the Android client binds to port 546 and does not connect() the >>>> socket but uses sendto(). So it will send packets from port 546 and it >>>> will receive any packet to port 546 regardless of the source port used >>>> by the server. So I guess that happens to be correct. >>>> >>>> Having the client send from 12345 -> 547 and the server send from 33333 >>>> -> 546 is sort of unusual - usually each party in a connection will use >>>> the same source port for sending and receiving - but DHCPv6 is not a >>>> connected protocol (e.g., some of the messages are multicast and some >>>> are unicast), so... >>>> >>>> I do think the current text is ambiguous. In practice it allows >>>> arbitrary source ports, but because this is unusual, implementers might >>>> assume that the other side is using the same port to send and receive. >>>> Such an implementation might not interoperate. So if we think the >>>> behaviour is OK, then we should clarify the text to say that the source >>>> port is not specified and clients and servers need to be prepared to >>>> receive messages from arbitrary source ports. >>>> >>>> On Wed, Feb 28, 2024 at 4:47 PM Ole Troan >>>> <otroan=40employees.org@dmarc.ietf.org> wrote: >>>> >>>> Bernie, >>>> >>>>> No. Normal UDP communication rules apply. A client sends traffic >>>> to a well-known destination port and it is free to select whatever >>>> port number it likes as the source port. The server’s response is >>>> sent from that well known port (as source port) and sent to the >>>> client’s selected port (as destination port). This is normal >>>> communication and dhcpv6 follows it. That is why nothing is said or >>>> needs to be said about the client source port. >>>> >>>> I’m with Tomoyuki here. >>>> >>>> " >>>> 7.2. UDP Ports >>>> >>>> Clients listen for DHCP messages on UDP port 546. Servers and relay >>>> agents listen for DHCP messages on UDP port 547. >>>> >>>> “ >>>> >>>> Just checked my little scapy based DHCPv6 server and I do: >>>> >>>> reply = (Ether(src=self.interface_info.mac, dst=request >>>> [Ether].src) / >>>> IPv6(src=self.interface_info.ip6ll, dst=request >>>> [IPv6].src) / >>>> UDP(sport=547, dport=546) / >>>> DHCP6_Reply(trid=trid) / >>>> DHCP6OptServerId(duid=self.duid) / >>>> DHCP6OptClientId(duid=clientduid) / >>>> DHCP6OptIA_NA(iaid=request[DHCP6OptIA_NA].iaid, >>>> T1=t1, T2=t2, >>>> ianaopts = DHCP6OptIAAddress >>>> (addr=ipv6, >>>> >>>> preflft=self.preflft, >>>> >>>> validlft=self.validlft) >>>> ) >>>> >>>> I couldn’t find any text supporting your position Bernie. Although >>>> I would be fine if that was also the outcome. >>>> As another implementor I cannot figure out what the correct >>>> behaviour is from the RFC. >>>> >>>> Cheers, >>>> Ole >>>> >>>>> - Bernie Volz >>>>> >>>>>> On Feb 26, 2024, at 1:00 AM, Tomoyuki Sahara >>>> <tsahara=40iij.ad.jp@dmarc.ietf.org> wrote: >>>>>> >>>>>> Hi, DHC wg members: >>>>>> >>>>>> Can we make recommendations on source port numbers of DHCP6 >>>> messages >>>>>> in rfc8415bis? >>>>>> >>>>>> DHCP6 specification says that DHCP6 clients and servers listen on >>>> UDP >>>>>> port 546 and 547 respectively, in RFC8415 section 7.2. It >>>> implies >>>>>> that DHCP6 clients MUST send messages to UDP port 547 (server >>>> port) and >>>>>> servers MUST send messages to UDP port 546 (client port) to work >>>> with >>>>>> their counterpart correctly (though restrictions can be relaxed >>>> with >>>>>> RFC8357 for relays). >>>>>> >>>>>> But it says nothing about source port numbers. Without any >>>>>> restrictions, some implementations use ephemeral source port >>>>>> (e.g. 12345) to send their messages. DHCP6 conversations look >>>> like: >>>>>> >>>>>> 1. client send Solicit fe80::2#49876 -> ff02::1:2#547 >>>>>> 2. server send Advertise fe80::1#547 -> fe80::2#546 (!) >>>>>> 3. client send Request fe80::2#49877(?) -> ff02::1:2#547 >>>>>> 4. server send Confirm fe80::1#547 -> fe80::2#546 >>>>>> >>>>>> This behavior is not prohibited by the specification but makes >>>>>> confusions for DHCP6 implementer and network/firewall operators >>>> (*1). >>>>>> Most Internet protocols nowadays assume that servers send >>>> response >>>>>> messages from the port number they received on. >>>>>> (*1 e.g. https://bugzilla.redhat.com/show_bug.cgi?id=952126 ) >>>>>> >>>>>> In my humble opinion, it is too late to require that DHCP6 client >>>> and >>>>>> server MUST send messages from the fixed port number (546/547) >>>> because >>>>>> there are too many DHCP6 implementations in the wild. But making >>>> a >>>>>> recommendation is helpful for new implementations/deployments of >>>> DHCP6. >>>>>> >>>>>> An idea to make such recommendation is adding a text in >>>> rfc8415bis: >>>>>> >>>>>> OLD: >>>>>> 7.2. UDP Ports >>>>>> Clients listen for DHCP messages on UDP port 546. Servers >>>> and >>>>>> relay agents listen for DHCP messages on UDP port 547. >>>>>> >>>>>> NEW: >>>>>> 7.2. UDP Ports >>>>>> Clients listen for DHCP messages on UDP port 546. Servers >>>> and >>>>>> relay agents listen for DHCP messages on UDP port 547. >>>>>> >>>>>> Clients are RECOMMENDED to send DHCP messages from UDP port >>>> 546. >>>>>> Servers and relay agents are RECOMMENDED to send DHCP >>>> messages >>>>>> from UDP port 547 (unless relay agent includes Relay Source >>>> Port >>>>>> Option for DHCP6 [RFC8357]). >>>>>> >>>>>> I know WGLC has been concluded but I believe the recommendations >>>> above >>>>>> encourage new implementations to use the standard DHCP6 port >>>> numbers >>>>>> on UDP source port. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Tomoyuki Sahara >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dhcwg mailing list >>>>>> dhcwg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>> >>>>> _______________________________________________ >>>>> dhcwg mailing list >>>>> dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>
- [dhcwg] recommendation on DHCP6 source port numbe… Tomoyuki Sahara
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Tomoyuki Sahara
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… Mark Smith
- Re: [dhcwg] recommendation on DHCP6 source port n… Lorenzo Colitti
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Tomoyuki Sahara
- Re: [dhcwg] recommendation on DHCP6 source port n… Lorenzo Colitti
- Re: [dhcwg] recommendation on DHCP6 source port n… Tomoyuki Sahara
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Trøan
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… David Farmer
- Re: [dhcwg] recommendation on DHCP6 source port n… Robert Nagy
- Re: [dhcwg] recommendation on DHCP6 source port n… Alan DeKok
- Re: [dhcwg] recommendation on DHCP6 source port n… David Farmer
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… David Farmer
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Trøan
- Re: [dhcwg] recommendation on DHCP6 source port n… David Farmer
- Re: [dhcwg] recommendation on DHCP6 source port n… rob@deepdivenetworklng.com
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… David Farmer
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ted Lemon
- Re: [dhcwg] recommendation on DHCP6 source port n… rob@deepdivenetworklng.com
- Re: [dhcwg] recommendation on DHCP6 source port n… rob@deepdivenetworklng.com
- Re: [dhcwg] recommendation on DHCP6 source port n… Michael Richardson
- Re: [dhcwg] recommendation on DHCP6 source port n… rob@deepdivenetworklng.com
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Robert Nagy
- Re: [dhcwg] recommendation on DHCP6 source port n… Michael Richardson
- Re: [dhcwg] recommendation on DHCP6 source port n… Tomoyuki Sahara
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan
- Re: [dhcwg] recommendation on DHCP6 source port n… Bernie Volz
- Re: [dhcwg] recommendation on DHCP6 source port n… Ole Troan