Re: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-port-00.txt

["Bernie Volz (volz)" <[e-mail]>]

(WG Chair hat-off)

I think this work is flawed and it will basically be impossible to get all clients to change - and manually configuring the client as to whether to use the 'default port' or not is also not an option - especially for clients that roam. If a client is configured incorrectly it will not get a lease. And if there are still some clients on a network that use the default port, you're hosed anyway. So, this just cannot work.

The main reason a specific port is used is that the relay does not have an option (or field in the packet) in which to store the response port; just the address (giaddr for v4, peer-address for v6).

Having relays remember this information also seems rather complex (especially since a relay-agent (option 82) sub-option could easily be defined for v4, or a relay top-level option for v6). But, that is really the lesser of the problems with this entire solution.

Relaxing RELAY to SERVER communication to use alternate ports seems to be a much more plausible and viable solution. And, I would think that would give you exactly what you need? (The client to directly reachable server or first hop relay communication is interface specific so hard to see how that is an issue with using the client port.) Also, relays and servers are typically within the same operator administrative domain, so upgrading both to support this capability is a much more easily achieved goal.

Again, the solution here is to have the relay indicate the response port. This would be a new relay agent option (82) sub-option and a new DHCPv6 relay option. The option would just need to be 2 octets to specify the 16-bit port number to be used [an alternative would just be to this option be a flag option to indicate reply to source port, but that does not work as well for DHCPv6 given that relay chaining is supported there - note that each relay can add its own port].


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, June 22, 2016 2:39 PM
To: [e-mail]
Cc: Enke Chen (enkechen) <[e-mail]>
Subject: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-port-00.txt


Hi,

We just submitted a new (individual submission) Internet draft dealing DHCP
issues with large scale and distributed relay agents within a single node/router/switch.

Please review and comment.

thanks.
- Naiming


Begin forwarded message:

From: <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-shen-dhc-client-port-00.txt
Date: June 20, 2016 at 10:28:56 PM PDT
To: Naiming Shen <[e-mail]<mailto:[e-mail]>>, Enke Chen <[e-mail]<mailto:[e-mail]>>


A new version of I-D, draft-shen-dhc-client-port-00.txt
has been successfully submitted by Naiming Shen and posted to the
IETF repository.

Name: draft-shen-dhc-client-port
Revision: 00
Title: Generalize Client UDP Port Number of DHCP Relay
Document date: 2016-06-20
Group: Individual Submission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-shen-dhc-client-port-00.txt
Status:         https://datatracker.ietf.org/doc/draft-shen-dhc-client-port/
Htmlized:       https://tools.ietf.org/html/draft-shen-dhc-client-port-00


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




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

The IETF Secretariat