[dhcwg] A question regarding section 6.2 of RFC 6221
Benjamin Kappel <b.kappel90@outlook.de> Fri, 25 September 2020 03:31 UTC
Return-Path: <b.kappel90@outlook.de>
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 012DF3A0F4C for <dhcwg@ietfa.amsl.com>; Thu, 24 Sep 2020 20:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 ux6TNZiKW0Kf for <dhcwg@ietfa.amsl.com>; Thu, 24 Sep 2020 20:31:39 -0700 (PDT)
Received: from EUR06-DB8-obe.outbound.protection.outlook.com (mail-db8eur06olkn2034.outbound.protection.outlook.com [40.92.51.34]) (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 EC5323A0F4A for <dhcwg@ietf.org>; Thu, 24 Sep 2020 20:31:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZobhQHVThwZ6RfVH727kYA/IcPS5LqCRwNl3aM6sLsjzkWPanzfshUoWwqQeaKKPKul60VldSLkUv89tobYCnQsxiKzRjcSL+ADktFwD8ugzAUv/lqx1/LBOVS/6qfEH110vA3Xgdg38uVKuzlrFwpLOG8ojY76U2dBNhGFWUId4bWgIwPqBBFn5ky6tY8BHL5u9L5lMsSCuXAw5wOSrYhpVbGrTCVjNvqkgGelBQcWnNMyI7cEb/6ehug+rfLA98ZmQQycvc9LgRyRdVjYUFNqZjWJpWVDpGuWl+9RYtD011a2+T8Z9z7+wqDhGGoM/L6G2gPh+Y82/UNPQvToZXg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pcv1WmgrVUoXw3FIxWwBBR5mdAkQwjsL4ev+lMJVlIc=; b=l6Aexgq/AJEcUPhn8nGqiA0A3AAdLxwkSrg19CKbpShKfGkTxwJLNzyRM/l083NZoS0s8IQmUk6OnZRsMiiTfDJ/jrKIF6yh0ukuYlCST9T1wdwtXqDoKDYwbqQh/r6Rhg6kLH79VT2PW0c3YVKrRUO++IG3dOHkJ0YiaEMbxcFaqgi7JziVhb9RDuR/VA9MgJ4fi6ZsecqWLr0SLY1vEv6FSWArwtlDCEAZqqHXz0PI563/PhXjtZmALFxxSLCsoiDjKUBhx1b04hMLCFUr9iFdjF7jnBCKaJUKDDpBbqovqXS6+MfaPjys5SPsRufBGWdhNSWCh8w5dBg9pe0QTg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
Received: from DB8EUR06FT044.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::47) by DB8EUR06HT034.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::456) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Fri, 25 Sep 2020 03:31:36 +0000
Received: from VI1P190MB0718.EURP190.PROD.OUTLOOK.COM (2a01:111:e400:fc35::4d) by DB8EUR06FT044.mail.protection.outlook.com (2a01:111:e400:fc35::280) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Fri, 25 Sep 2020 03:31:36 +0000
Received: from VI1P190MB0718.EURP190.PROD.OUTLOOK.COM ([fe80::f0bd:4a07:189c:846d]) by VI1P190MB0718.EURP190.PROD.OUTLOOK.COM ([fe80::f0bd:4a07:189c:846d%9]) with mapi id 15.20.3391.028; Fri, 25 Sep 2020 03:31:36 +0000
From: Benjamin Kappel <b.kappel90@outlook.de>
To: "dhcwg@ietf.org " <dhcwg@ietf.org>
Thread-Topic: A question regarding section 6.2 of RFC 6221
Thread-Index: AQHWkuweAsefQnX6HEq01+9SLy7vZw==
Date: Fri, 25 Sep 2020 03:31:36 +0000
Message-ID: <VI1P190MB071869412C7ADCECECB0FC4EFA360@VI1P190MB0718.EURP190.PROD.OUTLOOK.COM>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:F8D12604FF1D115ADDA544EE5D3C70F6D2519519327C9E240CB497525152EE82; UpperCasedChecksum:EA6AADF89C95D10D8F479A1EEE38E6DCC2D346EF008658C8ADB92E0C561513E2; SizeAsReceived:6654; Count:42
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [YEyJXlrCVgruwSo/Vt3cats4npBz6MuQ]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 54eb0cae-ad4c-463c-d9e5-08d8610381ae
x-ms-traffictypediagnostic: DB8EUR06HT034:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SaprZjTkmrP0G6u+Td1G5LM96w00IVkvc1WfPZp5GbKGphHTOAagSHzsVxIogVN/a99um4OAw1GrzpILhPfbmFQrisquwOX+r/ZgsFsZ+fZFZEPvfF7azvdpShE2b7MjtOCNaghpi2pN30MDwkiAVTofsSUOvE3YbfUuc1E6D8KgP+nz102EjCXDJ6NvYoiueZDK6qQsYgtnCQ+c4j/5cQ==
x-ms-exchange-antispam-messagedata: lRYLvz1JhVOnLHMANjc/53IO10f5qZqJTyLvUEKQts8j9Amzp6MDfxFsfH0ci1nvzzQfTFXjh+LSMtn3iMlAGDcpaL5qB1R7nVkSDDxICesu58NKEpms8aPL25Us/F7rS3rpQdfBPtCAQnR7NuFS0w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1P190MB071869412C7ADCECECB0FC4EFA360VI1P190MB0718EURP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: DB8EUR06FT044.eop-eur06.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 54eb0cae-ad4c-463c-d9e5-08d8610381ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 03:31:36.0953 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8EUR06HT034
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/yEMSpKXe8jyX11yausHpuKHsiB4>
Subject: [dhcwg] A question regarding section 6.2 of RFC 6221
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Sep 2020 03:31:41 -0000
Hi
I have a question regarding your work on RFC 6221 (Lightweight DHCPv6 Relay Agent) and hope this is an appropriate way to start a discussion.
In section 6.2 it that that the lrda should only intercept DHCPv6 messages with a link local source address. We run into the following issue:
Simplified, we have a topology like 7.2 where server and client communicate using a relay agent. The reply from the server is sourced by its unicast address and sent as unicast back to the relay agent. (packet A)
packet A:
src-ip: server (global unicast address)
dst-ip: relayB (global unicast address of link A)
msg-type: RELAY-REPLY
hop-count: 1
link-address: relayB address from link A (global unicast address)
peer-address: client link-local address
Relay-Message Option, which contains:
msg-type: RELAY-REPLY
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: REPLY
Reply Message Options: <from server>
The relay agent stripes away its relay message option and generating a new packet with the destination of the client. However, this implementation uses the source address (the unicast address) of the server as the source of the outgoing packet. (packet B)
Packet B:
src-ip: server (global unicast address)
dst-ip: client link-local address
msg-type: RELAY-REPLY
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: REPLY
Reply Message Options: <from server>
I've examined the DHCPv6 RFC (8415) to check if the relay agent behaviour is part of the document. The document says: "the relay agent relays the message from the server to the client on the link identified by the Interface-Id option". I'd argue "relays" not necessarily implies, that the agent needs to "source" it from its interface.
Anyway, currently, we have the problem that the LDRA doesn't intercept the packets, based on that above rule, and the client receives a RELAY-REPLY reply instead of a REPLY. Both manufactures pointing to the standards and argue that the comply, which they do, I think.
Can I ask about the motivation behind your rule? Why not allowing any address to be a legitimate source? Do you think the relay agent doesn't comply to standard?
Thank you in advance and have a nice day
Ben
- [dhcwg] A question regarding section 6.2 of RFC 6… Benjamin Kappel
- Re: [dhcwg] A question regarding section 6.2 of R… Bernie Volz (volz)