IETF Logo Mail Archive

[dhcwg] passing relay info back to client

Kent Watsen <kwatsen@juniper.net> Thu, 04 January 2018 18:35 UTC

Return-Path: <kwatsen@juniper.net>
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 0A66A127201; Thu, 4 Jan 2018 10:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 kKYUwC-9BKdH; Thu, 4 Jan 2018 10:35:02 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE921270A3; Thu, 4 Jan 2018 10:35:02 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w04IYHWY002078; Thu, 4 Jan 2018 10:35:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=U9Eck7REQi1PqxA4d/Io0R/MdCdZA2BrcX36ic2nv60=; b=LfiuGQrdN1O6RJgj+WhJXqgniaoavyPHEXsceKgTslwprlKdE7/ZNC1paWMBov+O0E/T yP93vAWFPpGwMy58tbm+WuWDihf8bkbzAjIPy28IvA236OUWdWjMeTnJpMnXrryeaWJH 8P4TSzjkbUGQbeulGAIvuyaHCYiqw79NZz3VZu9vvn5SeSD0HRAOdrrzRlWRjZmukzB8 lWVAV1ekIC08eWO52jarmBDr/8ekfXV8lFl/Tfa3Y46LIJgQ/5gyKdnqaUh3PmyNMNa8 OIiwNBbq+jg41sVcekamLMu2AdT2Dp6Kh9aHdfrsl7zbCEoOzoOQtOk1U3bv0mN+qF38 0Q==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0054.outbound.protection.outlook.com [207.46.163.54]) by mx0b-00273201.pphosted.com with ESMTP id 2f9sm3g0fn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 10:35:00 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3273.namprd05.prod.outlook.com (10.173.220.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.1; Thu, 4 Jan 2018 18:34:58 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0407.000; Thu, 4 Jan 2018 18:34:58 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
CC: "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>
Thread-Topic: passing relay info back to client
Thread-Index: AQHThYq5t46JLrGOc0qesTzgGz1RDQ==
Date: Thu, 04 Jan 2018 18:34:58 +0000
Message-ID: <88649CAA-99B6-48FA-8E47-6D386BD50FFD@contoso.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3273; 6:hrsNqBUC3Fi7VMsRp2k9bacHmMvH69JQzO8xry0VwZxE+5iORb5Ztpi2Ze0aqXi9W9oNV3jwwpP//M7Bh3g67J30u+xiILTWvAvUgm76gWORvrPL+/I4IXYYDb6VvI6lpFDC2pI6ecl/3ierCGXBRq3Rwqn1/eVti1uhgCQBbCX1VB78TRcUMJOTfWm5NQb2brjHryxN6PeyfJT2gxdtplI8fwKpNIEUyPbSpvIqQgPDhCVzR1BiXqw+BUe7yqrUz3Iz93dlK1C/v4JfVPc8N7svrkV4gS1gxYe0SpkOh4ccV89NKJXYKYvluKKx3xUEZT5qmrEokyWSaSsFdOCLfLzfqLzRHqsIhEq+fq5jVY3uZDege02QVSoRqP4BrRfz; 5:bV1R2TcQxmisYIvAIK2B/Bbie0klocFp7vJQLlx57meFuzS8LuAKbHSlCYZmwA+I2eGlmF/cpN+Nr7SHWurPEihEfP0O3zwCczJBgjtfVAB1iBRbBLcU8pBCPHoVwZTUMiKu6TY8x1alSgHIO2ZNUI3YV/6e/IcxrmjroelTEcw=; 24:E2qZpb9FnwDqT5p3PI2obH0tOvrotbeUluHesH1CIiHLDAa0k7+tc7WfL5OSUvob76tyjgzJF1fgEwTpHxbPgZmnxIM9vlOT/OHv1/mhqq8=; 7:uEFqgarXRO51kk9Jrplh5rH+udvcKsV+VUQiWOeW7q6dYGwBP3iOcA7HudBFf7RoPZOpuu6FQjdGtafMPjnUiKQ72XfTaQYHFjYq9Cj/wNgH5AgNU7X52IbnODf6XEjIMzI3OUjGJNZ/r6LeYMU+Tb5zEB7AQXIVdfvpPNL6bjGs5+JVsQTZHHDX1KK3DBqCjR/o1DAgFVOsUYHEssjqz4uiRm+X6KujTFjkw3qdgXdrpjYlsZiXCL1webxJRKbQ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 52996a63-eef2-45f9-a7a0-08d553a1dbc8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(5600026)(4604075)(3008032)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:DM5PR05MB3273;
x-ms-traffictypediagnostic: DM5PR05MB3273:
x-microsoft-antispam-prvs: <DM5PR05MB3273929B1311650F8763F73CA51F0@DM5PR05MB3273.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR05MB3273;
x-forefront-prvs: 054231DC40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(396003)(376002)(346002)(199004)(40224003)(189003)(6116002)(3846002)(105586002)(2900100001)(81166006)(106356001)(6486002)(53936002)(3280700002)(7736002)(77096006)(3660700001)(25786009)(2501003)(1730700003)(81156014)(8676002)(36756003)(2906002)(6512007)(99286004)(97736004)(6306002)(6916009)(66066001)(9686003)(4326008)(5660300001)(2351001)(450100002)(478600001)(54896002)(83506002)(8936002)(86362001)(33896004)(316002)(6436002)(102836004)(6506007)(83716003)(58126008)(5640700003)(33656002)(82746002)(68736007)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3273; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Pho/kghEdgZL2UAA99enQSvkpJH0sRGHFpIKbDTFXYPW2I16d5eXPhuHBEtqK52BMnvrMRXv2RI3x7O/anHQdw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_88649CAA99B648FA8E476D386BD50FFDcontosocom_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 52996a63-eef2-45f9-a7a0-08d553a1dbc8
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 18:34:58.4524 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3273
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-04_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040256
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/SufOgBpLedIpQVpBwZu3FCWSM5s>
Subject: [dhcwg] passing relay info back to client
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Jan 2018 18:35:05 -0000


In support for draft-ietf-netconf-zerotouch, I'm wondering about what relay information the DHCP client may learn in a DHCP response.  Specifically, it would be helpful for deployments that do not wish to track the movement of specific devices (serial numbers) if the device (via its DHCP client) could learn the relay information used by the DHCP Server to identify it.  However, sadly, I'm beginning to think that this is not possible...



For DHCPv4, RFC 3046 Section 2.1 says:



   The Relay Agent Information option echoed by a server MUST be removed

   by either the relay agent or the trusted downstream network element

   which added it when forwarding a server-to-client response back to

   the client.



For DHCPv6, RFC 3315 Section 20.1 says:



   The relay agent processes any options included in the Relay-reply

   message in addition to the Relay Message option, and then discards

   those options.



Is this the end of the story, or am I overlooking something?  Do implementations ever pass the relay info back to the client anyway?   Would there be any interest in changing this behavior in DHCP so as to better support zerotouch bootstrapping scenarios?



Thanks,

Kent

v2.23.0 | Report a Bug | By Email