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

Andre Kostur <> Fri, 08 July 2016 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93CC712D0D3 for <>; Fri, 8 Jul 2016 12:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wmWDjbqS0uvl for <>; Fri, 8 Jul 2016 12:26:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72C2B12D567 for <>; Fri, 8 Jul 2016 12:17:15 -0700 (PDT)
Received: by with SMTP id fi15so1731545pac.1 for <>; Fri, 08 Jul 2016 12:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gqNOkqX/kNhvPFdG6PoDbzFHdwsEBzyFHNTMDvsyOBI=; b=NRTxsHRLQR6V/+q9YsVE2fT3MOn8e8EHheaK0VcTIM3r7Sr/z+Fgz3484XzJ3DW2z+ AzmHQ9yc6okUeP9oRgqW/8ynu8HOjPAT8a6vl+FAbRYX1D/0HOFwppMv7VqTPmqguPSA 1IY1bfEDpXIgGSLaBzeocH/I793qenmZ8RIU+q7q/K1ZpDxFUNyqMpJ77Kz8eI+P1+s+ OHgyID16n5dwRlmFH5jXV3qB7tvf9RX2od/8tpcImuBv3SeTNyDZ3G1ZC/zPr4ccyaQ1 ykUfsXAihVyAffdNVagBPwDAdeWcwNAQBraH0HNeGguctrCLwpfXaxYK5riW+hi0IW5V ewyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gqNOkqX/kNhvPFdG6PoDbzFHdwsEBzyFHNTMDvsyOBI=; b=k44ZEUdzut/aRwTR0gSponGW5C134SMSRkexWl+Vz1mBo+0Q52+ksIbN7vOq4gRAxB ASKqH20gq522bG7XgrSlwggsbgM0q9+PRTAJQiatj/+3opUIlZjDlXbCCYpwL8GEB3Pe 8BuTdPp/UT+gbQKJE3jD2cOnufh+DJ96ZzB6vuN+t6zXq6nOfbQ5ZPW/Q1PEVAzZJLjk UqPGSRAyZZxhF5/H4pdz2n/RJINhaz50EU+IfKdcWs3/f2tzuZI/6la5P83gmpKPS/aT Y6HSFEzf1rbfpcsLbXUKz0GP6N1g1Cjwcj+Go2rxxQCHQqWCHwSnWJ7OF8hf5soLCYVu q5sQ==
X-Gm-Message-State: ALyK8tJPzDW8VTa6B6OCxI79pa6ngkjAjHTLBVW96ralfUhjL0nTcwyRjy2SeM8HaSYd3SFdrv8ksGjIQ49QoUo7
X-Received: by with SMTP id dw11mr2955432pac.2.1468005434892; Fri, 08 Jul 2016 12:17:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Jul 2016 12:17:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Andre Kostur <>
Date: Fri, 8 Jul 2016 12:17:14 -0700
Message-ID: <>
To: "Bernie Volz (volz)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
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:26:11 -0000

A counterpoint for #1, I would argue that DHCPv4 does acknowledge the
possibility of chained relays.  (RFC 951, section 7.3 talking about
"If 'giaddr' is zero,....", would suggest that there are cases where
the GIADDR is non-zero.)  Granted, the DHCP server will reply back to
the original GIADDR, but by then this second relay which didn't modify
the GIADDR may now be sending from the standard DHCP port, resulting
in the destination port being determined to be the standard DHCP port
(used by the 2nd relay), not the non-standard DHCP port desired by the
first relay.

I would suggest that both forms of this option put in the desired port
number as the option's payload (2 octet, MSB first).

We have also seen a particular misbehaving load balancer fiddle with
the source port of DHCP packets as they passed by.  I'm not sure how
widely applicable this experience is... but it has been seen in the

On Fri, Jul 8, 2016 at 12:04 PM, Bernie Volz (volz) <> wrote:
> Hi:
> 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.

Andre Kostur