Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26

"Naiming Shen (naiming)" <> Tue, 25 April 2017 04:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41F2B1294CE; Mon, 24 Apr 2017 21:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bKstzPFsNei6; Mon, 24 Apr 2017 21:02:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93C9C127698; Mon, 24 Apr 2017 21:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=33660; q=dns/txt; s=iport; t=1493092925; x=1494302525; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=668V28qZ+mxCO3/usJ5QsM+uQV0MDKAcezQbwnjiOEs=; b=IFTSx7ifBnXrPk4271nH0TIqCpJvYHNEfpArPgNla1CHBJkc/ooIHrIt THzUQbt6HVdQFVBP4awjJG0T48aF4bbjUdlDodujadMH1oBTeRJ6VMupo Q3eN1BT9ThH50bM6tQWn+GDHzPPvQqBXm93pniyesNbEzHr3K8tHE9Sgh I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,247,1488844800"; d="scan'208,217";a="414232286"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 04:02:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3P4244c002289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 04:02:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 23:02:03 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 23:02:03 -0500
From: "Naiming Shen (naiming)" <>
To: "Bernie Volz (volz)" <>
CC: Tomek Mrugalski <>, dhcwg <>, "" <>
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26
Thread-Index: AQHSrkJ4jGafpAaCIk+/kF5HBW5FkaHRyhDAgAQelgA=
Date: Tue, 25 Apr 2017 04:02:03 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A7E53EB44CBB4E32BDB4F9C7CBDF0CB2ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 04:02:09 -0000

Hi Bernie,

Thanks for the detailed comments. Replies inline:

On Apr 22, 2017, at 11:31 AM, Bernie Volz (volz) <<>> wrote:


I reviewed the 04 version.

This document could use some updates. Below are my comments. I think these should be addressed before the document advances, but otherwise I think it should be mostly ready to move forward.

1. General - I would highly recommend this draft adopt and document the "DHCP" terminology as follows:
DHCP means DHCPv4 and DHCPv6.
DHCPv4 means the Dynamic Host Configuration  Protocol for IPv4 as documented in RFC2131.
DHCPv6 means the Dynamic Host Configuration Protocol for IPv6 as documented in RFC3315.
And make use of these correctly.

The document currently uses DHCP to mean DHCPv4 or both DHCPv4 and DHCPv6.

Similarly, I 'd suggest using IPv4 and IPv6 (or IP when being general and apply to both or either).

Sure. Makes sense. Will go through those and not to mix the DHCP and DHCPv4 usage.
Some of the places, just IPv4 and IPv6 is fine.

2. Abstract - As currently written I don't see why this RFC is needed. Relay source ports in 2131/3315 are meaningless and the abstract "allows any valid number" which is already the case. It needs to be document that this provides the means for the relay to receive packets from a server or (upstream) relay on any port, not just the default port.

Ok, what about this?

   This document proposes an extension to the DHCP protocols that allows
   a relay agent to receive packets from a server or an upstream relay
   agent on any UDP port, not just the default port 67 for IPv4 or
   default port 547 for IPv6.

3. Introduction (1) - The "to remember inbound" may cause some concern with regards to relay's -- since they actually do not remember anything (they are supposed to be stateless).  I wonder if this text can be cleaned up -- servers need to "remember" while processing a packet; (cascading) relay's need to add this port information to the Relay-Forw packets.

Ok, how about this?

   This extension requires
   a DHCP server to remember the inbound packet's UDP port number along
   with the IP/IPv6 address.  The DHCP server when sending back replies
   MUST use the UDP port number that the incoming relay agent uses
   instead of the fixed DHCP port number.  In the case of IPv6 cascaded
   relay agents [RFC3315], the upstream relay agent needs to use the
   "Relay Source Port Option" to record the downstream source port and
   it MUST use this recorded port number instead of the fixed DHCP port
   number when replaying the reply messages.

4. Section 4.2 - there are several places where "non-DHCP UDP port" is used. I wonder whether we could just say "port other than 547. I know this is in the terminology, but in this case it is DHCPv6 specific text so why make someone look it up? I guess you could use: "non-DHCP UDP Port (not 547)" or similar if you wanted to keep the reference to that term?

This same comment applies to section 5.1 and 5.2 (though in 5.1 port 67 applies).

In the end, it may be that the definition isn't that useful and perhaps that would even be better to remove it and just use the explicit port numbers? I think this would help readability. But review and consider.

I still think it’s just too many places we are talking about both IPv4 and IPv6 and
have to say both of the ports explicitly. But those some of the places is only for
IPv4 or only for IPv6, I’ll do what you suggested, to use the (not 67) or to use
the (not 547) in those places.

5. Section 7 (IANA). Please look at a document such as To avoid confusion, we have put the URL of the tables in the IANA considerations. This practice should be followed here to that it is clear to IANA exactly which set of tables to update.

Ok, sure. But the example you sited, it already had the IANA number assigned.
For this one, we have not so far, how about these sentences?

   A new sub-option, DHCPv4 Relay Source Port, is defined in this
   document within the IPv4 Relay Agent Information Option.  It needs to
   be assigned by IANA in the "DHCP Relay Agent Sub-Option Codes"
   registry, as
   specified in [RFC3046].

   A new option, DHCPv6 Relay Source Port, is defined in this document
   for DHCPv6 and it needs to be assigned by IANA for the DHCPv6 option
   code, in the "Option Codes" registry for DHCPv6, as specified in

6. Section 8 (Security Considerations). This should reference the security considerations of RFC 2131 and 3315.

The text that is there is more of an operational consideration rather than what security issues this new work might expose - which may be nothing new over 2131/3315. But pointing out that firewalls need to be adjusted is a good thing.

Ok, I added this paragraph in the front, and a ‘Although’ to start the original sentence:

   [RFC3118] and [RFC3315] described many of the threats in using DHCP.
   This extension does not raise addition security issues.

   Although if the network uses firewall to block or allow DHCP packets

7. Section 10 (Document Change Log). Usually an RFC Editor note is added to request that they REMOVE this material in the RFC publication process.

Sure. Will remove these in the next version.

- Naiming

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 3:26 PM
To: dhcwg <<>>
Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26

draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and
DHCPv6 protocols that allows usage of other UDP source ports to be used by relay agents. Authors believe this document is ready. The discussions so far on the mailing list were a bit modest, but the concept is simple, the draft was presented twice (in Buenos Aires and Berlin) and enjoyed a favourable reception in the room. As such, we announce a working group last call on this document. Please review and comment.

This is a very short document. It has around 6 pages of actual text.

Many WG participants may celebrate upcoming Easter and take some days off, therefore this WGLC is a bit longer than typical two weeks.

Title: Generalized UDP Source Port for DHCP Relay
Authors: N. Shen, E. Chen
Filename: draft-ietf-dhc-relay-port-02
Pages: 10 (around 6 of actual technical text)
Date: 2017-02-28

Responses by April 26th are appreciated.

Bernie and Tomek

dhcwg mailing list<>