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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 12 January 2017 19:42 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2810F129519 for <dhcwg@ietfa.amsl.com>; Thu, 12 Jan 2017 11:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFy4en7FgEJj for <dhcwg@ietfa.amsl.com>; Thu, 12 Jan 2017 11:42:09 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D199912950F for <dhcwg@ietf.org>; Thu, 12 Jan 2017 11:42:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10302; q=dns/txt; s=iport; t=1484250128; x=1485459728; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=plpm+XzJT0+IfzZlLBo/Or4/xJDRXbGg0ibEHkf0oEg=; b=Hz2eiEqTEalxIM/P5ouE1i3lMRoXZMgFl5jLPOwVqBY2GD0D1SKYFtFL 1GkuWLyrUHu8slPNkcHBqAr7QdplnIr0e9PkK9AL33eZUNU0eh5/1LkaT cpYzs6W84JdczyYyn+b9/P+4xJdS7g0Pjwbfrbv8BmKtivezbFvZ3zDkn Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AbAQDd2ndY/5pdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgzwBAQEBAR9fgQkHg0mKCJIVlSqCDR8NhXYCGoFsPxQBAgEBAQEBAQFjKIRpAQEBAwEBASEEDToLBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIAYhvCA6wbYFrOooQAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELiRWBBoMJgScdM4JMgl4Fjx6GCoYEAYZainKCAFGEPYgvgTaIE4IfiDEBHzg2gQ4VGCKGL3MBh1iBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208";a="194091513"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 19:42:07 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0CJg76u021695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Thu, 12 Jan 2017 19:42:07 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 13:42:06 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 12 Jan 2017 13:42:06 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>, dhcwg <dhcwg@ietf.org>
Thread-Topic: I-D Action: draft-ietf-dhc-relay-port-01.txt
Thread-Index: AQHSaG9D0XfUeEfxw0Sn9ambzTJNZaE1P/BQ
Date: Thu, 12 Jan 2017 19:42:06 +0000
Message-ID: <4328855a5add4c3a9f044689171156f7@XCH-ALN-003.cisco.com>
References: <148374230973.17537.14402355403407250708.idtracker@ietfa.amsl.com> <843031F0-B818-4C19-8120-78EE7D531E06@cisco.com>
In-Reply-To: <843031F0-B818-4C19-8120-78EE7D531E06@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.32.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/NPMjUkW7o0J8Ac8IEsa4lnwFSk4>
Cc: "Enke Chen (enkechen)" <enkechen@cisco.com>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jan 2017 19:42:11 -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:dhcwg-bounces@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Friday, January 06, 2017 5:50 PM
To: dhcwg <dhcwg@ietf.org>
Cc: Enke Chen (enkechen) <enkechen@cisco.com>
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, internet-drafts@ietf.org 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
> I-D-Announce@ietf.org
> 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
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg