Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-01.txt

["Naiming Shen (naiming)" <[e-mail]>]

Move them to the front.

BV> OK, while you could implement it this way -- saying that the presence of the option in the Relay's packet (with a 0 value) is an indication that the port number is not the default and therefore the RECEIVER must insert it (replace the 0 value with the non-zero value based on the source port), I think this is NOT a good idea. I think the sender (that wants to response on the non-standard port) should be the one that adds the option with the correct port number. In DHCPv6, changing some other entities message is frown upon (hence why we encapsulate). And, I think it is simpler and less work for the receiver. There's also a security mechanism that the receiver can use to CONFIRM that the port is the indicated port.

For DHCPv6, because there is cascading relays. Otherwise, this is what we
agreed on for DHCPv4 UDP PORT option, and there is no local port number
needed. For v6 it has to if the ‘downstream’ relay uses a non-standard port.

Since I’ve done some implementation now, it is really straightforward to
get the UDP port number from the dhcp packet, since the ‘upstream’ has
already got the IP address of the source, which is even a lower layer in
the network stack.


BV> I guess the ONE benefit of doing it your way is that a server COULD detect if there are relays in the mix that don't support this, as when it copies the Relay-Forw's port option to the Relay-Reply, if the value is 0 it could report that the response will not get back to the client since a relay doesn't support the return path. But I don't see that benefit to be very large (since you already require that all entities must support this feature to use it).

For this to work, any ‘upstream’ device has to support that, but not further
besides the server side has to copy the option back. I can see a case:

client — relay1(1000)——relay2——relay3——server

in this case, relay1 uses a non-standard port, and relay2 has to support
this extension. But relay3 does not have to support that. Server has to
support that, since it copies the options back in relay-reply. When it
gets to relay2, which is really the place to use this option with a non-zero
port number in the options.

On Jan 18, 2017, at 1:54 PM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:

I'll look at the 02 draft when you do publish it.

I agree that upsteam/downsteam is very confusing (as it depends on perspective) and hence why I think you should just call the option something simple (relay-port)? By keeping it a simple name, the complexity can be in how it is used and the name gets less in the way.


We’ll try to define them in some better way.

thanks.
- Naiming


See more below (BV>).

- Bernie

-----Original Message-----
From: Naiming Shen (naiming)
Sent: Wednesday, January 18, 2017 4:19 PM
To: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>
Cc: dhcwg <[e-mail]<mailto:[e-mail]>>; Enke Chen (enkechen) <[e-mail]<mailto:[e-mail]>>
Subject: Re: I-D Action: draft-ietf-dhc-relay-port-01.txt


Hi Bernie,

Thanks for the review and comments.

BTW, I made the latest draft changes due to I found it's necessary duration my implementation (using ISC dhcp code base). I have coded the feature for both relay agent and the server for V4 and V6. I have tested with my implementation with:

1) DHCPv4 simple relay case using non-standard port
2) DHCPv6 cascaded relay case with all the V6 relay agents using non-standard ports
3) DHCP 4to6 with cascaded V6 relay agents using non-standard ports

The main reason why this ‘port’ field of DHCPv6 option needs to be a ‘downstream’
port number instead of previous version we thought as local non-standard port, just think the example of option “Interface-ID” to contrast with. In the case of option “Interface-ID”, the relay-x includes this in it’s Relay-Forw options, when it gets back in the Relay-Reply to relay-x, it needs to find out the ‘interface-id’ to use for the operation 'ON THIS relay-x’; But for relay UDP port option, when it gets back the Relay-Reply to relay-x, it has no use of this non-standard UDP port number of its own, since this DHCPv6 packet has already reached this device, this non-standard UDP port really is for relay-x’s upstream devices to use in order to get to this ‘relay-x’ device. I hope this point is clear.

Please see more replies inline with [NS] tag.

On Jan 12, 2017, at 11:42 AM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:

Hi:

I don't think the DHCPv6 Relay handing is correct.

The only relay that needs to add this is the relay that is using a non-standard port. Other relays in the chain only need to add this if they too are using a non-standard port.

Thus the text:

 Also when a DHCPv6 relay agent
 detects that the downstream relay agent relays uses a non-DHCP UDP port in
 the packet, it MUST record the port number in the Downstream UDP
 Source Port field of this option.  If this option is included to
 indicate only the local non-DHCP UDP port usage and there is no
 downstream relay agent's non-DHCP UDP port usage, the field
 Downstream UDP Source Port MUST be set to zero.

Is not appropriate. I'm not even sure how a relay agent could detect this (other than by looking in the received Relayed packet for the option).

The concept is that a relay that Relays a packet to a server (i.e., generates a Relay-Forw) should ONLY add this option to the generated Relay-Forw if IT is using a non-standard port. Otherwise no option is added (just don't add the option; not an option with 0 value).

When a server generates Relay-Reply packets from the Relay-Forw chain, it copies this option from the Relay-Forw into the Relay-Reply. And, if the "outermost" Relay-Reply has this option, it sets its destination port number to that port for the packet to be sent.

The most simple case is:

Client -> Relay at port 2000 -> Server

Relay message send to server is then:

Relay-Forw
  Option: UDP Port = 2000
  Option: Relay Message:
         <Client request message>

The server will then generate a Relay-Reply:

Relay-Reply
  Option: UDP Port = 2000
  Option: Relay Message:
         <Client response message>

And send the packet to the relay at port 2000.

The relay will then send the client message to the client.

Note: The above only includes the basic items needed to demonstrate this.

[NS starts]

Correct. And more precisely let me make a distinction for the port 2000 is for upstream server to use. Now In my new version of the draft:

- DHCPv4 case

 relay1 will include relay-agent option for UDP PORT and send to the server.
 The server notices there is a relay-agent option for UDP PORT (without port
 number here), and finds its UDP RELAY-FORW packet has the port
 number of 2000. When sending back the RELAY-REPLY, the server
 uses the destination UDP port 2000 to send to relay1.

- DHCPv6 case

 Basically the same. In our new version of the draft, the relay1 will include
 the Relay Port option and sets the ‘downstream UDP port’ to zero. The
 DHCPv6 server receives this packet, and notices there is a Relay Port option,
 then it finds the UDP port of this packet being 2000. When sending back
 to relay1, the UDP port number will be 2000.

Both cases are almost identical. There is no number number passed in both options.
[NS ends]

BV> OK, while you could implement it this way -- saying that the presence of the option in the Relay's packet (with a 0 value) is an indication that the port number is not the default and therefore the RECEIVER must insert it (replace the 0 value with the non-zero value based on the source port), I think this is NOT a good idea. I think the sender (that wants to response on the non-standard port) should be the one that adds the option with the correct port number. In DHCPv6, changing some other entities message is frown upon (hence why we encapsulate). And, I think it is simpler and less work for the receiver. There's also a security mechanism that the receiver can use to CONFIRM that the port is the indicated port.

BV> I guess the ONE benefit of doing it your way is that a server COULD detect if there are relays in the mix that don't support this, as when it copies the Relay-Forw's port option to the Relay-Reply, if the value is 0 it could report that the response will not get back to the client since a relay doesn't support the return path. But I don't see that benefit to be very large (since you already require that all entities must support this feature to use it).



A more complex case:

Client -> Relay at port 1000 -> Relay at standard port -> Relay at
port 2000 -> Server

Thus the Relay-Forw received at a server might look like:

Relay-Forw
  Option: UDP Port = 1000
  Option : Relay Message:
       Message: Relay-Forw
             Option: Relay Message:
                    Message: Relay-Forw
                           Option: UDP Port = 2000
                           Option: Relay Message:
                                  <Client request message>

The server then generates:

Relay-Reply
  Option: UDP Port = 1000
  Option : Relay Message:
       Message: Relay-Reply
             Option: Relay Message:
                    Message: Relay-Reply
                           Option: UDP Port = 2000
                           Option: Relay Message:
                                  <Client response message>

And sends this to the relay at port 1000.

The relay will then process this by removing the outer most relay message hence end up with:

Relay-Reply
     Option: Relay Message:
            Message: Relay-Reply
                  Option: UDP Port = 2000
                  Option: Relay Message:
                       <Client response message>

It will then send this to the next relay at the STANDARD Port (no UDP Port in outermost message):

That relay will then process this by removing the outer most relay message and hence end up with:

Relay-Reply
         Option: UDP Port = 2000
         Option: Relay Message:
               <Client response message>

It will then send this to the next relay at port 2000.

That final relay will send the client message to the client (at the standard port).

[NS starts]
Also lets be more precise here to name the cascaded relay agents to be ‘relay-1’ and relay-2’.
relay-1 has the source UDP port of 1000 talking to upstream relay-2, and relay-2 has the source UDP port of 2000 talking to upstream server.

- client sends request msg to relay-1

- relay-1 Relay-Forw msg

 it puts on the Relay UDP Port option and set the ‘downstream udp port’ to zero.
Relay-Forw
  Option: UDP Port, downstream-port=0
  Option: Relay message
   <client request message>

- relay-2 Relay-Forw msg

 Relay-2 notices the Relay-Forw previous hop has the option of UDP PORT,
 it then finds out the inbound packet has UDP port number 1000.
 It puts on the Relay UDP Port option and set the ‘downstream udp port’ to 1000.
 (because relay-2 needs to use this value 1000 later in order to send reply packet
  back to relay-1).

Relay-Forw
 Option: UDP Port, downstream-port=1000
 Option: Relay message
     Option: UDP Port, downstream-port=0
     Option: Relay message
        <client request message>

- server Relay-Reply msg

 The server notices the Relay-Forw previous hop has the option of UDP PORT,
 and it then finds out the inbound packet has UDP port number of 2000.
 It sends back the Relay-Reply message to relay-2 using the UDP port of 2000.

Relay-Reply
 Option: UDP Port, downstream-port=1000
 Option: Relay message
     Option: UDP Port, downstream-port=0
     Option: Relay message
        <client reply message>

- relay-2 Relay-Relay msg

 Relay-2 finds the UDP Port option, and finds the ‘downstream udp port’ to
 be 1000. It formats the message and sends to relay-1 using the UDP port
 of 1000. (to the downstream relay agent)

Relay-Reply
     Option: Relay message
       Option: UDP Port, downstream-port=0
       Option: Relay message
          <client reply message>

- relay-1 Relay-Relay msg

 Relay-1 finds the UDP Port option, and finds the ‘downstream udp port’ to
 be zero. It formats the message and sends to client with standard UDP port.

Relay-Reply
     Option: Relay message
        <client reply message>

- Client gets the relay message.
[NS ends]



You also need to clean up the text as you are using "Relay Source Port
Option" and "Downstream UDP Source Port"? I think having a

[NS starts]
I’ll look through this again, and as explained above, this ‘port field’ really represents the ‘downstream UDP source port’. But I will try to see if there is something can be improved and consistency is certainly needed.
[NS ends]

bit more consistent naming would be useful. I think because this is where the "response" should be sent, perhaps best to the "Relay Reply Port Option" or perhaps even "Relay-Reply Port Option" (as in Relay-Reply message). But I'm less concerned about the exact name, just that more consistence exists. I also think that "port" or something simple in the option field definitions would be sufficient rather than using a long name. i.e.:

    Option-Code:  OPTION_RELAY_REPLY_PORT. 16 bits value, to be assigned by IANA.

    Option-Len:  16 bits value to be set to 2.

    Port:  16 bits value.  To be set by to the port to which
    the Reply-Reply should be sent to (by the upstream
    relay-agent or server).

Another issue is that you should give the option a name (OPTION_...) - see http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 as all options have such a name and this is not something IANA does -- you need to have it in your draft. (This is less important for v4, though several drafts have been doing this using too - see http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options).

[NS starts]
Will do.

thanks.
- Naiming

[NS ends]


- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Naiming Shen
(naiming)
Sent: Friday, January 06, 2017 5:50 PM
To: dhcwg <[e-mail]<mailto:[e-mail]>>
Cc: Enke Chen (enkechen) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-01.txt


Hi,

We have updated the dhc-relay-port draft.

The main update is on the DHCPv6 Relay Agent Source Port option, with
the change to the definition of UDP port field from previously of
‘local' UDP source port to 'downstream relay' UDP source port, this is
for the cascaded DHCPv6 relay case.

And added more requirements on server side and relay agent handling of
this DHCPv6 option.

Please review and comment.

thanks.
- Naiming

On Jan 6, 2017, at 2:38 PM, [e-mail]<mailto:[e-mail]> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

     Title           : Generalized Source UDP Port of DHCP Relay
     Authors         : Naiming Shen
                       Enke Chen
Filename        : draft-ietf-dhc-relay-port-01.txt
Pages           : 8
Date            : 2017-01-06

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-ietf-dhc-relay-port/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-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
[e-mail]
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

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