Re: [dhcwg] I-D Action: draft-shen-dhc-client-port-01.txt
"Naiming Shen (naiming)" <naiming@cisco.com> Fri, 08 July 2016 21:35 UTC
Return-Path: <naiming@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 19A3712D926 for <dhcwg@ietfa.amsl.com>; Fri, 8 Jul 2016 14:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 tV5ZNqE_lAO4 for <dhcwg@ietfa.amsl.com>; Fri, 8 Jul 2016 14:35:01 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2754712D92D for <dhcwg@ietf.org>; Fri, 8 Jul 2016 14:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61832; q=dns/txt; s=iport; t=1468013701; x=1469223301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ESfx61tCOkc0CHnLZvjKs1O0jfnUyn9Z/0bEx+c5a6w=; b=WoIxqOfYuEcMW1wKIG/z1060QcUH3no1Yrdgf/Dty2wVE0JU6zTSkwGY H3bOxmtXgi+PQnniNAcIi4BPZ5qaf0tNKCnc+HdPaWwRnhmU7Njbabtx4 5BWHQs4eNWlmrwVHqhh7MaBZk4Di51nErjI8TdRPraux9Nz3BzioRtefo U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A0AgB0G4BX/4UNJK1cgnBOVm0PBrkRgXoihXYCHIEMOBQBAQEBAQEBZSeETAEBBQEBIUQHBgUQAgEGAhEDAQEBIQEGAwICAiULFAkIAgQOBQmIJw6RYp0djxoBAQEBAQEBAQEBAQEBAQEBAQEBAQEciB+CVYQTEQEGLQkWCIJDK4IvBZNahToBhguIQ4FqToQKh0+BG4gxh1wBDw82g3FuAYd8Nn8BAQE
X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208,217";a="123857302"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 21:34:59 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u68LYxZb005949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Fri, 8 Jul 2016 21:34:59 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 16:34:59 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 16:34:58 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: I-D Action: draft-shen-dhc-client-port-01.txt
Thread-Index: AQHR2M8PtDgyaoUgHE2ggSXIc0+FlqAO5D0QgABacYD//73TAIAAYfaA//+sV1CAAFiLAA==
Date: Fri, 08 Jul 2016 21:34:58 +0000
Message-ID: <22614E7A-7B78-43E5-AF45-93DCC89CDFB0@cisco.com>
References: <20160708041305.18785.16916.idtracker@ietfa.amsl.com> <FDE950BA-7E7F-4D7E-912C-C324B628A246@cisco.com> <adb4507f1c9947478d3e613271a98367@XCH-ALN-003.cisco.com> <39274946-2955-4C49-B288-6FEC48A03D13@cisco.com> <D3A57660.30335%volz@cisco.com> <1CAC3C01-24D5-4FA9-B173-3679B39BCDDC@cisco.com> <d6f3562f790e43429949eb0450b5b333@XCH-ALN-003.cisco.com>
In-Reply-To: <d6f3562f790e43429949eb0450b5b333@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.41.57.106]
Content-Type: multipart/alternative; boundary="_000_22614E7A7B7843E5AF4593DCC89CDFB0ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/NiL3qt6fRH2ZicrlQKnPxszb-6Y>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Enke Chen (enkechen)" <enkechen@cisco.com>
Subject: Re: [dhcwg] I-D Action: draft-shen-dhc-client-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: Fri, 08 Jul 2016 21:35:04 -0000
Ok. Makes sense since we are already including the option itself. Regards, - Naiming On Jul 8, 2016, at 2:20 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote: Yuck! Why do that when you can just add it to the Relay-Forw packet and extract it from the Relay-Reply (servers must be sure to copy this from the Relay-Forw into the Relay-Reply, since they usually DON’T do this – see the ERO (RFC4994 for more details)). In DHCPv6, the relay must construct a Relay-Forw (and process a Relay-Reply), so storing it there just makes so much sense. You are already adding an option to indicate “hey relay, you must do this” so why make it also do the work of “remembering” this when you can just send it along with the signal. - Bernie From: Naiming Shen (naiming) Sent: Friday, July 08, 2016 5:18 PM To: Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> Cc: dhcwg@ietf.org<mailto:dhcwg@ietf.org>; Enke Chen (enkechen) <enkechen@cisco.com<mailto:enkechen@cisco.com>> Subject: Re: I-D Action: draft-shen-dhc-client-port-01.txt I was describing the ‘remembering’ scheme in my previous email. Each DHCPv6 cascading relay, when forwarding the packet upstream, if this option exist (hop-by-hop), will cash the previous hop relay's IPv6 address (for return) along with the UDP port (if it’s non-standard). When the reply packet coming back downstream, the relay agent will do a match if it’s there and use the cached UDP port, then release the cache entry on the relay. Regards, - Naiming On Jul 8, 2016, at 12:26 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote: I don’t understand this at all. Unless you explicitly configured a Relay 2 to always use port X when sending to Relay 1, where in the Packet from the Server (which comes from Relay 3) would Relay 2 know where to send the packet. You don’t want to have to have relay 2 remember this. - Bernie From: "Naiming Shen (naiming)" <naiming@cisco.com<mailto:naiming@cisco.com>> Date: Friday, July 8, 2016 at 3:23 PM To: Bernie Volz <volz@cisco.com<mailto:volz@cisco.com>> Cc: "dhcwg@ietf.org<mailto:dhcwg@ietf.org>" <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>, "Enke Chen (enkechen)" <enkechen@cisco.com<mailto:enkechen@cisco.com>> Subject: Re: I-D Action: draft-shen-dhc-client-port-01.txt Hi, Thanks for the initial comment. We intend for this option to be hop-by-hop behavior instead of end-to-end. For example, in below DHCP devices topology: Client <—> Relay-1(x) <——> Relay-2(y) <—> Relay-3(z) <—> Server where (x, y, z) are the non-standard UDP source ports used by the relay agents of 1, 2 and 3. This DHCPv6 option is meant only between the two neighbors. When the Relay-2 receives from Relay-1, or the Relay-3 receives from Relay-2, or the Server receives from Relay-3, the implementation can easily setup the previous relay agent IPv6 address to the UDP port binding locally. When the reply message comes back in the other direction, the binding can be retrieved hop-by-hop, and optionally the binding can be discarded after. This restricts the issue between the two DHCPv6 neighbors and there is no state needs to be carried end-to-end for the DHCPv6 messages. This will also scale better if the relay cascading extend to N stages. thanks. - Naiming On Jul 8, 2016, at 12:04 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote: Hi: Some initial comments: 1. For DHCPv4, the zero length option can work since there is no provision for relay chaining. 2. For DHCPv6, the zero length option does NOT work since this provides no means for a case where Relay 1 uses port X which is sent to Relay 2 which uses port Y to send to the Server. The server can response to Relay 2 on port Y (since that is the incoming port), but there is no place for Relay 2 to have stored the port. You should go back and make this option a 2 octet option with the port number. The server would then see: Relay-Forw from Relay 2 Relay Port Source Port option Y Relay-Message option Relay-Forw from Relay 1 Relay Port source Port option X Relay- Message Option <client’s request> And all would work correctly as the Server would use the port Y from the outermost relay option, relay 2 would use the port X from the Relay 1 Relay-Forw. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Naiming Shen (naiming) Sent: Friday, July 08, 2016 12:29 AM To: dhcwg@ietf.org<mailto:dhcwg@ietf.org> Subject: [dhcwg] Fwd: I-D Action: draft-shen-dhc-client-port-01.txt Hi, We have updated the draft of “Generalized Source UDP Port of DHCP Relay”. Please review and comment. Thanks. - Naiming Begin forwarded message: From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> Subject: I-D Action: draft-shen-dhc-client-port-01.txt Date: July 7, 2016 at 9:13:05 PM PDT To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>> Reply-To: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized Source UDP Port of DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-shen-dhc-client-port-01.txt Pages : 7 Date : 2016-07-07 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-shen-dhc-client-port/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-shen-dhc-client-port-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-shen-dhc-client-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<http://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<mailto: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
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Naiming Shen (naiming)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Ted Lemon
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Naiming Shen (naiming)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Bernie Volz (volz)
- [dhcwg] Fwd: I-D Action: draft-shen-dhc-client-po… Naiming Shen (naiming)
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Andre Kostur
- Re: [dhcwg] I-D Action: draft-shen-dhc-client-por… Naiming Shen (naiming)