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

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 5 Apr 2017 21:25:49 +0200

Hi,
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
Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02

Responses by April 26th are appreciated.

Thanks,
Bernie and Tomek

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 6 Apr 2017 20:54:08 +0000

I support as a co-author.

Best Regards,
- Naiming

> On Apr 5, 2017, at 12:25 PM, Tomek Mrugalski <[email-masked]> wrote:
> 
> Hi,
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Fang, Luyuan" <[email-masked]>
Date: Thu, 6 Apr 2017 23:06:00 +0000

I support.
Luyuan

On 4/6/17, 1:54 PM, "dhcwg on behalf of Naiming Shen (naiming)" <[email-masked] on behalf of [email-masked]> wrote:

    Best Regards,
    - Naiming

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Apr 2017 16:15:13 -0700

I support advancing this work.   However, there is an issue: right now the document assumes that if the relay agent sends a message from a different source port, the DHCP server will reply to that port.   This should be stated explicitly.  Right now the document does not place requirements on DHCP servers as far as I can see, and those are needed for interoperability.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 7 Apr 2017 00:02:32 +0000

Hi Ted,

Thanks for the suggestion. Currently in section 6 “Compatibility”, it says:

     It is recommended to upgrade the server side first before using a non-DHCP
     UDP port for a relay agent.

How about changing to this:

    The DHCP server MUST be upgraded to support the extension specified
    in this document before the extension is used by a relay agent.

Best Regards,
- Naiming

> On Apr 6, 2017, at 4:15 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Apr 2017 17:03:36 -0700

No, that's not quite what I mean.   What I mean is that you have to explicitly say what the DHCP server does.   Right now I'm not seeing that.    Maybe I missed it—I read the document pretty quickly.

> On Apr 6, 2017, at 5:02 PM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Hi Ted,
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 7 Apr 2017 00:15:22 +0000

Hi Ted,

In section 4.1 “Source Port Sub-option for DHCPv4", it says:

   When a DHCP server receives a message from a relay agent with the
   "Source Port Sub-option", it MUST remember the UDP source port of the
   message and use that port number as the UDP destination port when
   sending the reply message to the same relay agent.

In section 4.2 “Source Port Sub-option for DHCPv6", it says:

   When a DHCPv6 server receives a Relay-forward message with the "Relay
   Source Port Option", it MUST copy the option when constructing the
   Relay-reply chain in response to the Relay-forward message.  This
   option MUST NOT appear in any message other than a Relay-forward or
   Relay-reply message.  Additionally, the DHCPv6 server MUST check and
   use the UDP source port from the UDP packet of the Relay-forward
   message in replying to the relay agent.

thus the dhcp server behavior for both v4 and v6 is defined.

Best Regards,
- Naiming

> On Apr 6, 2017, at 5:03 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 7 Apr 2017 00:26:40 +0000

Ok, currently the text is this:

   The Relay Agent "Source Port Sub-option" is a new option, and it is
   part of the relay-agent-information option for DHCPv4 [RFC3046<https://tools.ietf.org/html/rfc3046>].  It
   SHOULD be used by a relay agent that uses a non-DHCP UDP port
   communicating with the DHCP server.

I can change it to:

   The Relay Agent "Source Port Sub-option" is a new option, and it is
   part of the relay-agent-information option for DHCPv4 [RFC3046<https://tools.ietf.org/html/rfc3046>].  It
   MUST be used by a relay agent that uses a non-DHCP UDP port
   communicating with the DHCP server.

and do the same for DHCPv6 part also.

Best Regards,
- Naiming

On Apr 6, 2017, at 5:17 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

Hm, okay, but earlier you also specify that the router can just use a different source port without using the option.   If this isn't permitted, then you need to make that text more explicit: if and only if the relay sends the suboption can it use a different source port.

On Apr 6, 2017, at 5:15 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ted,

Best Regards,
- Naiming

On Apr 6, 2017, at 5:03 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 6, 2017, at 5:02 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ted,

---

From: "Peter Arberg" <[email-masked]>
Date: Fri, 7 Apr 2017 10:04:01 +0200

I support,
Peter

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Fang, Luyuan
Sent: 7. april 2017 01:06
To: Naiming Shen (naiming) <[email-masked]>; Tomek Mrugalski
<[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr
26

I support.
Luyuan

On 4/6/17, 1:54 PM, "dhcwg on behalf of Naiming Shen (naiming)"
<[email-masked] on behalf of [email-masked]> wrote:

    Best Regards,
    - Naiming

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 22 Apr 2017 18:31:10 +0000

Hi:

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).

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.

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.

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.

5. Section 7 (IANA). Please look at a document such as https://tools.ietf.org/html/rfc7839#section-8. 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.

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.

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.

- Bernie

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

Hi,
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.

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

Thanks,
Bernie and Tomek

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Tue, 25 Apr 2017 04:02:03 +0000

Hi Bernie,

Thanks for the detailed comments. Replies inline:

On Apr 22, 2017, at 11:31 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

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.

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.

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.

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.

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, http://www.iana.org/assignments/bootp-dhcp-parameters 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,
   http://www.iana.org/assignments/dhcpv6-parameters as specified in
   [RFC3315].

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
     ….

Sure. Will remove these in the next version.

thanks.
- Naiming

- Bernie

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

Hi,

Thanks,
Bernie and Tomek

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 25 Apr 2017 10:33:55 +0000

Sounds fine.

- Bernie (from iPad)

On Apr 25, 2017, at 12:02 AM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie,

Hi:

Ok, what about this?

Ok, how about this?

   This extension requires

thanks.
- Naiming

- Bernie

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

Hi,

Thanks,
Bernie and Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 28 Apr 2017 20:04:09 +0200

> Responses by April 26th are appreciated.

I (Bernie recused himself on this one as all authors work for the same
company as he does) reviewed the responses received to this last and
determined that there's a consensus in the working group to proceed
forward with this document.

Authors already seem to have addressed all comments in the -05, which
has been published recently.

Thank you to everyone who commented and to authors for addressing all
the issues raised quickly.

Tomek
p.s.
I will do my shepherd duties once I get back from a short vacation and
business trip. Expect some movement here around mid-May.