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

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 8 Jul 2016 04:29:08 +0000

Hi,

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

Thanks.
- Naiming

Begin forwarded message:

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

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

Abstract:
  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:
https://datatracker.ietf.org/doc/draft-shen-dhc-client-port/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-shen-dhc-client-port-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-shen-dhc-client-port-01

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:04:14 +0000

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.

-          Bernie

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

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:23:43 +0000

Hi,

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.

thanks.
- Naiming

On Jul 8, 2016, at 12:04 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

Some initial comments:

-          Bernie

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

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:24:54 +0000

Andre:

Yes, I would agree. Far better to specify the port :).

Yeah, firewalls or NAT[P] boxes between the relays/servers could create
issues. Probably something that should be indicated in the draft that it
may not work well with NAT[P] boxes between relays or the servers (also
perhaps those boxes may drop the packets as not considering them valid
DHCP packets). Probably a minor issue as most likely that part of an
operators network would not use NAT[P], but worth just mentioning.

- Bernie

On 7/8/16, 3:17 PM, "Andre Kostur" <[email-masked]> wrote:

>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
>wild.
>
>On Fri, Jul 8, 2016 at 12:04 PM, Bernie Volz (volz) <[email-masked]>
>wrote:
>> Hi:
>>
>>
>>
>> Some initial comments:
>>
>>
>>
>> 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
>>
>><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

---

From: Andre Kostur <[email-masked]>
Date: Fri, 8 Jul 2016 12:17:14 -0700

On Fri, Jul 8, 2016 at 12:04 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 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
> port Y from the outermost relay option, relay 2 would use the port X from
> the Relay 1 Relay-Forw.

-- 
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:26:55 +0000

I don’t understand this at all. Unless you explicitly configured a Relay 2 to always use port X when sending to Relay 1, where in the Packet from the Server (which comes from Relay 3) would Relay 2 know where to send the packet. You don’t want to have to have relay 2 remember this.

- Bernie

From: "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 8, 2016 at 3:23 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Enke Chen (enkechen)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-shen-dhc-client-port-01.txt

Hi,

thanks.
- Naiming

Hi:

Some initial comments:

-          Bernie

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

[email-masked]<mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Jul 2016 12:30:36 -0700

We went a fair distance down the relay agent chaining rathole a few years
ago:

https://tools.ietf.org/html/draft-lemon-dhcpv4-relay-encapsulation-01
https://tools.ietf.org/html/draft-kurapati-dhc-relay-chaining-dhcpv4-02

The effort was abandoned because IPv4...

On Fri, Jul 8, 2016 at 12:26 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I don’t understand this at all. Unless you explicitly configured a Relay 2
> to always use port X when sending to Relay 1, where in the Packet from the
> Server (which comes from Relay 3) would Relay 2 know where to send the
> packet. You don’t want to have to have relay 2 remember this.
>
> - Bernie
>
> From: "Naiming Shen (naiming)" <[email-masked]>
> To: Bernie Volz <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Enke Chen (enkechen)" <
> [email-masked]>
> On Jul 8, 2016, at 12:04 PM, Bernie Volz (volz) <[email-masked]> wrote:
>
> Hi:
>
> Some initial comments:
>
> option a 2 octet option with the port number. The server would then see:
> Relay-Forw from Relay 2
> *From:* dhcwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Naiming Shen (naiming)
> *Sent:* Friday, July 08, 2016 12:29 AM
> *To:* [email-masked]
> *Subject:* [dhcwg] Fwd: I-D Action: draft-shen-dhc-client-port-01.txt
>
>
> Hi,
>
> *From: [email-masked]
> *Subject: I-D Action: draft-shen-dhc-client-port-01.txt*
> *Date: *July 7, 2016 at 9:13:05 PM PDT
> *To: *<[email-masked]>
> *Reply-To: [email-masked]
>
>
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:50:48 +0000

Agreed Ted. v4 relay chaining is not a concern (hence why I was less concerned about having the option specify the port; though for consistency with v6 it might be nice and zero-length options have caused some issues with DHCPv4). My example was for DHCPv6.

Note that the Relay-Forw’s DHCPv6 Relay Agent Source Port Option is where the server (or relay) should send the packet. This is a bit different than how the peer-address field is used (since the server just uses the packet’s source address, not the Relay-Forw’s peer-address for where it sends the packet).

For the server, if the received outer-most Relay-Forw that it is responding too (I.e., constructing a Relay-Reply) has a DHCPv6 Relay Agent Source Port Option, the server sends to that port instead of the default port.

For a relay-agent, if Relay Message Option’s packet is a Relay-Reply, if it contains a DHCPv6 Relay Agent Source Port Option, the relay would send to that port instead of the default port (and use the peer-address out of the Relay-Reply it received).

- Bernie

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 8, 2016 at 3:30 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Enke Chen (enkechen)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] I-D Action: draft-shen-dhc-client-port-01.txt

We went a fair distance down the relay agent chaining rathole a few years ago:

On Fri, Jul 8, 2016 at 12:26 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I don’t understand this at all. Unless you explicitly configured a Relay 2 to always use port X when sending to Relay 1, where in the Packet from the Server (which comes from Relay 3) would Relay 2 know where to send the packet. You don’t want to have to have relay 2 remember this.

- Bernie

Hi,

thanks.
- Naiming

Hi:

Some initial comments:

-          Bernie

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 8 Jul 2016 21:17:30 +0000

I was describing the ‘remembering’ scheme in my previous email.
Each DHCPv6 cascading relay, when forwarding the packet upstream,
if this option exist (hop-by-hop), will cash the previous hop relay's
IPv6 address (for return) along with the UDP port (if it’s non-standard).
When the reply packet coming back downstream, the relay agent will do a
match if it’s there and use the cached UDP port, then release the
cache entry on the relay.

Regards,
- Naiming

On Jul 8, 2016, at 12:26 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

- Bernie

Hi,

thanks.
- Naiming

Hi:

Some initial comments:

-          Bernie

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Jul 2016 21:20:51 +0000

Yuck!

Why do that when you can just add it to the Relay-Forw packet and extract it from the Relay-Reply (servers must be sure to copy this from the Relay-Forw into the Relay-Reply, since they usually DON’T do this – see the ERO (RFC4994 for more details)).

In DHCPv6, the relay must construct a Relay-Forw (and process a Relay-Reply), so storing it there just makes so much sense. You are already adding an option to indicate “hey relay, you must do this” so why make it also do the work of “remembering” this when you can just send it along with the signal.

-          Bernie

From: Naiming Shen (naiming)
Sent: Friday, July 08, 2016 5:18 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; Enke Chen (enkechen) <[email-masked]>
Subject: Re: I-D Action: draft-shen-dhc-client-port-01.txt

Regards,
- Naiming

- Bernie

Hi,

thanks.
- Naiming

Hi:

Some initial comments:

-          Bernie

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 8 Jul 2016 21:34:58 +0000

Ok. Makes sense since we are already including the option itself.

Regards,
- Naiming

On Jul 8, 2016, at 2:20 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Yuck!

-          Bernie

From: Naiming Shen (naiming)
Sent: Friday, July 08, 2016 5:18 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Enke Chen (enkechen) <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-shen-dhc-client-port-01.txt

Regards,
- Naiming

- Bernie

Hi,

thanks.
- Naiming

Hi:

Some initial comments:

-          Bernie

Hi,

Thanks.
- Naiming

Begin forwarded message:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.