Re: [dhcwg] I-D Action: draft-shen-dhc-client-port-01.txt

"Naiming Shen (naiming)" <> Fri, 08 July 2016 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F449126B6D for <>; Fri, 8 Jul 2016 12:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Status: No, score=-15.946 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=-1.426, SPF_PASS=-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 9bb9Y5O2s6km for <>; Fri, 8 Jul 2016 12:23:46 -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 DFB9412D0AA for <>; Fri, 8 Jul 2016 12:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31986; q=dns/txt; s=iport; t=1468005825; x=1469215425; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tc12+EtyW72MxRUqCFPvSPaY0qVwHZIV5Qj24+qq/kw=; b=dXy8dLL2cH+N8bCXmdp/04hjg5DLfvktjrRgVwUP40fAbGFKuS+gwGcj fkQA/zwMWkzbHqVR5L0VoqkpTacT/0p8JKoci3opsYHy5rG2/1pMaTMnN T6dfQlhvIqv6DBZZE2AiO/KQA5YGhx0c2mPFt3OCKEhb3kvYvZrnYM5Tu Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgCl/H9X/5RdJa1cgnBOVm0PBrkMg?= =?us-ascii?q?XsihXYCHIEMOBQBAQEBAQEBZSeETAEBBQEBIUQHBgUQAgEGAhEDAQEBIQcDAgI?= =?us-ascii?q?CJQsUCQgCBA4FCYgnDpFdnR2PJgEBAQEBAQEBAQEBAQEBAQEBAQEBARyIHwiCT?= =?us-ascii?q?YQrLQkWCIJDK4IvBZNahToBhguIQwKBaE6ECodPgRuIMYdcAR42g3FuAYgyfwE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.28,331,1464652800"; d="scan'208,217";a="295384263"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 19:23:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u68JNiBD003317 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Fri, 8 Jul 2016 19:23:44 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 14:23:43 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 14:23:43 -0500
From: "Naiming Shen (naiming)" <>
To: "Bernie Volz (volz)" <>
Thread-Topic: I-D Action: draft-shen-dhc-client-port-01.txt
Thread-Index: AQHR2M8PtDgyaoUgHE2ggSXIc0+FlqAO5D0QgABacYA=
Date: Fri, 8 Jul 2016 19:23:43 +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_3927494629554C49B2886FEC48A03D13ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Enke Chen \(enkechen\)" <>
Subject: Re: [dhcwg] I-D Action: draft-shen-dhc-client-port-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 19:23:49 -0000


Thanks for the initial comment.

We intend for this option to be hop-by-hop behavior instead of
end-to-end. For example, in below DHCP devices topology:

Client <—> Relay-1(x) <——> Relay-2(y) <—> Relay-3(z) <—> Server

where (x, y, z) are the non-standard UDP source ports used by the
relay agents of 1, 2 and 3.

This DHCPv6 option is meant only between the two neighbors. When
the Relay-2 receives from Relay-1, or the Relay-3 receives from Relay-2,
or the Server receives from Relay-3, the implementation can easily
setup the previous relay agent IPv6 address to the UDP port binding
locally. When the reply message comes back in the other direction,
the binding can be retrieved hop-by-hop, and optionally the binding
can be discarded after.

This restricts the issue between the two DHCPv6 neighbors and there
is no state needs to be carried end-to-end for the DHCPv6 messages.
This will also scale better if the relay cascading extend to N stages.

- Naiming

On Jul 8, 2016, at 12:04 PM, Bernie Volz (volz) <<>> wrote:


Some initial comments:

1.       For DHCPv4, the zero length option can work since there is no provision for relay chaining.
2.       For DHCPv6, the zero length option does NOT work since this provides no means for a case where Relay 1 uses port X which is sent to Relay 2 which uses port Y to send to the Server. The server can response to Relay 2 on port Y (since that is the incoming port), but there is no place for Relay 2 to have stored the port. You should go back and make this option a 2 octet option with the port number. The server would then see:
Relay-Forw from Relay 2
                Relay Port Source Port option Y
                Relay-Message option
                                Relay-Forw from Relay 1
                                                Relay Port source Port option X
                                                Relay- Message Option
                                                                <client’s request>
                And all would work correctly as the Server would use the port Y from the outermost relay option, relay 2 would use the port X from the Relay 1 Relay-Forw.

-          Bernie

From: dhcwg [] On Behalf Of Naiming Shen (naiming)
Sent: Friday, July 08, 2016 12:29 AM
Subject: [dhcwg] Fwd: I-D Action: draft-shen-dhc-client-port-01.txt


We have updated the draft of “Generalized Source UDP Port of DHCP Relay”.
Please review and comment.

- Naiming

Begin forwarded message:

Subject: I-D Action: draft-shen-dhc-client-port-01.txt
Date: July 7, 2016 at 9:13:05 PM PDT
To: <<>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Generalized Source UDP Port of DHCP Relay
       Authors         : Naiming Shen
                         Enke Chen
Filename        : draft-shen-dhc-client-port-01.txt
Pages           : 7
Date            : 2016-07-07

  This document extends the DHCP and DHCPv6 protocols for the UDP
  transport from relay agent to server and allows the port to be any
  valid number on the DHCP relay system.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list
Internet-Draft directories: