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

From: [email-masked]
Date: Fri, 06 Jan 2017 14:38:29 -0800

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/

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 6 Jan 2017 22:50:07 +0000

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, [email-masked] wrote:
> 
> 
> _______________________________________________
> 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: Thu, 12 Jan 2017 19:42:06 +0000

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.

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

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

- Bernie

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

Hi,

thanks.
- Naiming

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

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 18 Jan 2017 21:18:52 +0000

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) <[email-masked]> wrote:
> 
> Hi:
> 

[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]

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

[NS starts]
Will do.

thanks.
- Naiming

[NS ends]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Jan 2017 21:54:34 +0000

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) <[email-masked]>
Cc: dhcwg <[email-masked]>; Enke Chen (enkechen) <[email-masked]>
Subject: Re: I-D Action: draft-ietf-dhc-relay-port-01.txt

Hi Bernie,

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:

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.

[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

- DHCPv6 case

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

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

- relay-1 Relay-Forw msg

- relay-2 Relay-Forw msg

Relay-Forw

- server Relay-Reply msg

Relay-Reply

Relay-Reply
      Option: Relay message

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

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

[NS starts]
Will do.

thanks.
- Naiming

[NS ends]

> 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 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-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 18 Jan 2017 22:15:01 +0000

Move them to the front.

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.

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) <[email-masked]<mailto:[email-masked]>> wrote:

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) <[email-masked]<mailto:[email-masked]>>
Cc: dhcwg <[email-masked]<mailto:[email-masked]>>; Enke Chen (enkechen) <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-ietf-dhc-relay-port-01.txt

Hi Bernie,

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

Hi:

Thus the text:

The most simple case is:

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

Relay-Reply
  Option: UDP Port = 2000
  Option: Relay Message:

[NS starts]

- DHCPv4 case

- DHCPv6 case

A more complex case:

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

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>

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:

Relay-Reply
     Option: Relay Message:
            Message: Relay-Reply
                  Option: UDP Port = 2000
                  Option: Relay Message:

Relay-Reply
         Option: UDP Port = 2000
         Option: Relay Message:

[NS starts]

- relay-1 Relay-Forw msg

- relay-2 Relay-Forw msg

Relay-Forw

- server Relay-Reply msg

Relay-Reply

Relay-Reply
     Option: Relay message

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

[NS starts]

[NS starts]
Will do.

thanks.
- Naiming

[NS ends]

- Bernie

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

Hi,

thanks.
- Naiming

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

Abstract:

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Jan 2017 22:35:30 +0000

I understand the v4 case as there is no relay chaining. And, in that case just having the option is sufficient (port number is not needed). (If you want relay chaining in DHCPv4, it is much more complex and you have to have a place to store a bunch of information, such as original giaddr … and then you can also store port – there is no standard for this).

For DHCPv6, things are different and I think it is very bad (and as a WG “member” would not support this) to have one relay change another Relay-Forw’s packet (we used encapsulation of messages for a reason). While we have nothing that breaks today, that doesn’t mean it won’t in the future. And if a relay is adding the option already, it can stick the port number into it (rather than 0).

If you wanted to have the target relay store it for the return (if needed), you would then need two options. The sender of a non-standard port Relay-Forw includes an option (with no value) that just tells the next hop that a non-standard port is being used and that receiving relay that stores this into a new option in the Relay-Forw it adds. But again, this seems overly complex for non-benefit. Just have the SENDING relay store the port number in the Relay-Forw. Yes, this is different than DHCPv4, but so are a lot of other things different between v4 and v6. That’s life.

Note also that you’ve made the Relay processing for DHCPv6 much more complex for the forwarding towards server. By having the sender include the option with the port, there is NOTHING the receiver (next relay) needs to do. You only need to change the code for the sending path on the relay that wants to use a non-standard port and the Relay-Reply processing (to extract the option if present and use a different port). There’s no Relay-Forw processing that needs to change.

-          Bernie

Sent: Wednesday, January 18, 2017 5:15 PM

Move them to the front.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 19 Jan 2017 00:24:12 +0000

Bernie,

If you read my example with detailed message layout for each hop,
there is nothing about one relay agent changes another relay agent’s
message. all the relay-forw messages are encapsulated ontop of previous
agent’s message at the upstream direction. Server copies those unchanged,
and each relay-reply message is deencapsulated one by one. this is
exactly as the other relay options handled.

- Naiming

On Jan 18, 2017, at 2:35 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

-          Bernie

Move them to the front.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 20 Jan 2017 23:23:10 +0000

Hi:

After an offline discussion, I am fine with the general proposal of how the DHCPv6 handling is per the -01 draft. Sorry for my misunderstanding and the distraction.

-          Bernie

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 20 Jan 2017 23:41:55 +0000

No problem Bernie. Thanks!

Regards,
- Naiming

On Jan 20, 2017, at 3:23 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

-          Bernie