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

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

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.

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]>
Cc: dhcwg <[e-mail]>; Enke Chen (enkechen) <[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]> 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]>
> Cc: Enke Chen (enkechen) <[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] 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]
> https://www.ietf.org/mailman/listinfo/dhcwg