Re: [dhcwg] A question regarding section 6.2 of RFC 6221

"Bernie Volz (volz)" <volz@cisco.com> Fri, 25 September 2020 15:50 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 B82013A119B for <dhcwg@ietfa.amsl.com>; Fri, 25 Sep 2020 08:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=CI9cgQKV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Y9x2dlxU
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 nrkT79jk1Wc3 for <dhcwg@ietfa.amsl.com>; Fri, 25 Sep 2020 08:50:35 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA483A1493 for <dhcwg@ietf.org>; Fri, 25 Sep 2020 08:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22319; q=dns/txt; s=iport; t=1601049015; x=1602258615; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vX6MRC34rwfwloqrI9/YbrV6ngazyTzH4+70nXsj2bE=; b=CI9cgQKVq80dBHddkCSIblcxS315y09JD0i5SEEb1+X3ScaLq4+hMZxj YjquA6NYAK+fDq6CgnHLgaR9cJrVDwUZlOEELhhymQm/93KTvP+Q0cmuI XgUqTFfTiYgOaiqYR9XAjC4r52BTKGiij8MN2hX/GyEdOMP6/jB7OAKNF Y=;
X-IPAS-Result: =?us-ascii?q?A0C+CQAKEW5f/5ldJa1fHgEBCxIMQIJyL1EHcFkvLAqHe?= =?us-ascii?q?AONfph2glMDVQsBAQENAQEtAgQBAYRLAoIuAiQ4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEbYVcDIVyAQEBAQMSGxMBATgPAgEIDgMEAQEhDjIdCAIEARIIGoMFg?= =?us-ascii?q?X5NAy4BrQ0CgTmIYXSBNIMBAQEFhTwYghAJgTiCcoo8G4IAgRFDgk0+gQSDI?= =?us-ascii?q?RqDSIItmjmLepEOCoJnk0+HKqEQkwigBQIEAgQFAg4BAQWBayMqgS1wFYMkU?= =?us-ascii?q?BcCDY4fg3GKVnQ3AgYKAQEDCXyNKAGBEAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3AhVJIghZ+AYUGj54K+ouEIBT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4LG9/ZDjOmQv62zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutYEDOpnq17ngeF0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,302,1596499200"; d="scan'208,217";a="540599682"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Sep 2020 15:50:14 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08PFoEAU008424 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2020 15:50:14 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 10:50:14 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 10:50:13 -0500
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 25 Sep 2020 10:50:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MeLE8RBFXAb7DqwUfsUC/W8J7s8PjNseUVzFdNAImsSQpMY15Qhi6QNCrFl5ZquOMWSqL1Xq+Mg9937/izqoZhX+h9B2Mt+ydRJDS4yEN82HmJKypb+EWVAMkjcsgSxul82X1FG235LdX6qWvp4Fzdirvt8rgER15js3cIUW9g8N7eAXx3XtwwUX22n7krly6xs3sJDqT/avVXwJ7AyOWbin8NqGdaaCUD6Of/BgicIt1gY1LLjdqZxMygg4/CVdbU6XVpHns1t9pCAp05+Ex/mT0GkJjKqS9gNE+urEshRY+2+KtWOBwSkpFW3+c8hgmix1nMrB+7KJ0lyUaXZ2qg==
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=D4NQ2PVaUesasWjWayfBCnHNQVEEF+Mrw9J1AYzrSeI=; b=Ez5xEJoVossYAfszf6vUvILyHGbMfUQnuKtZ5OI8dLGiQqazNP+oDJshqTCPPgzmguSIqeufpzVphSnrhMt7KDGX9QBmj/xg1bohlngjVLT49vrtKDq5J2pehDVd7nMTUBghm5H7YZvezJo0UGGoNgKw8OOFukLy1KSNACuXGaVJ9jKLIzR+fMOhNg9Y8A+9yefL/s4kuWdAlguQTAuJUnI0+D2MY7vyTLH6a0htt6eECFlbCJywtLQSxUgwMaNP87XLfJB0nRdN1wU2DpI2iaj3LX4vwHW3Ne1DFaozhB7NCYiFhcHNEKo7cTtJfxfH5sqbyjXISBEDAgUDXeeonA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D4NQ2PVaUesasWjWayfBCnHNQVEEF+Mrw9J1AYzrSeI=; b=Y9x2dlxUGk9RI4Os3zenOEobmy0SsRRuR/XqzCZHt/Y1mKvcXEYmeny56f6EM92J25KtJZmRMbEIkxB0WFd054GSQ57LHy4UQugF6U+Ej6M0fxJmoYbJ7rP25ObQ8Ch4IrhBU96TCxsdxyAfGyYCMm+xrOtTOm6G9DoEMUEuGu8=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR11MB3876.namprd11.prod.outlook.com (2603:10b6:405:77::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.22; Fri, 25 Sep 2020 15:50:09 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::c8dd:2c09:b5bd:a7d5]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::c8dd:2c09:b5bd:a7d5%7]) with mapi id 15.20.3412.020; Fri, 25 Sep 2020 15:50:09 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Benjamin Kappel <b.kappel90@outlook.de>, "dhcwg@ietf.org " <dhcwg@ietf.org>
Thread-Topic: A question regarding section 6.2 of RFC 6221
Thread-Index: AQHWkuweAsefQnX6HEq01+9SLy7vZ6l5eecw
Date: Fri, 25 Sep 2020 15:50:09 +0000
Message-ID: <BN7PR11MB2547F33CA50042E1CC06375FCF360@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <VI1P190MB071869412C7ADCECECB0FC4EFA360@VI1P190MB0718.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <VI1P190MB071869412C7ADCECECB0FC4EFA360@VI1P190MB0718.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: outlook.de; dkim=none (message not signed) header.d=none;outlook.de; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.67]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2d838009-2baa-48ba-b65a-08d8616aaea8
x-ms-traffictypediagnostic: BN6PR11MB3876:
x-microsoft-antispam-prvs: <BN6PR11MB3876B74D348F29100205E8B0CF360@BN6PR11MB3876.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: e5PSkDVcgdoqlIqHa6w2AZ3UadndUocZgcmU0n86ifZF39JrCVfLA5A/n2ZjBLDWvu3O41nP1cOZlZ6NPCEbHC1LVmT3lnLjnwKm5DFf6VCne46HFma5g3QY8LSd7oDy2Vuh96L2fb5FgodNtbDYzjcpu420ny5O3asYeqcetjvQDefYc739j9joqxWiaYGwYgAUExJaPOVLMhUZZ+gLzl03RnOojMUyAJrGfE44B+ZIG/PlYzsA6tooOJZ4lfsUIRAoFBjY9ezijS4t9v1vCcryZaT0gbHvsNp6RA8D7D92ssd0shqEipBlcC5xo54l
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(136003)(39860400002)(396003)(66476007)(7696005)(478600001)(33656002)(8936002)(66446008)(316002)(110136005)(86362001)(53546011)(8676002)(186003)(76116006)(2906002)(71200400001)(66946007)(64756008)(66556008)(9686003)(26005)(6506007)(55016002)(5660300002)(52536014)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SIm8HVGBt7t5CDiE84HZ6tCMuDJujp7HvA27sp268oBwWWxZHS5M5qn8kSbMi27wjJu0lRPZTetZxUcA8uAeCoSwwaVJ6uCvt84xkD3fVUTyRL/neNK3BPerLFOsMC79aNFZlX5gJ15n5HU/5RI/X/nMSR4NwpLLVq3HRYc5GOSLIZQgMzaijW7v0ElD2c/74gQGx6xIZPALKjQ5BtqqiwQFGt6Fsx57hQL2CPJ3irTOc0dwzNvnFlex5KdhkeSldLTQ0NqsCD+ehRq2lIurmnMDehGT1bib+a8qNotvBWN8QYJqZtTj3zMBwM53Sx0xCwcAOYQ4HQjtSjVK5L27JXr566+JbbJybc3xSFQGIehc8B8eMw/wuK+UuGGuPkL+mBUhdBcsRhp1e02Fxke7OO9N9kRg1/pnrj1tDFZGZiYY9/mDCu7Bu/KhmkmBvz0qpbf79AbPxbs7J8Z+LxDUzTjKgn4uTitFXWUhBHS279Szkx7D23HHtkjgiIVGhW9qwwrYHZ0rqhjlvLYw3xkPp2p7+z2egCKIQ/fHr78sH30uX09xUU0/P/Bd8ZxrGP5tRLZhCl6I0gu9SgcMfa2BfjNDo0RklBUiekww5Ktirsy7304xt/Dr8EHV1r5ChYYp4JRdeJvcBwI6YXT2zNpSZw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547F33CA50042E1CC06375FCF360BN7PR11MB2547namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d838009-2baa-48ba-b65a-08d8616aaea8
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 15:50:09.6345 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HrbKqJEx/HiI8tnoSYcuqpxSe16Pm2TItrpaJDbkRLds5PSnVm2ZmNg0N8W37pH4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3876
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/JWH9sjcRr2XdJu6w18JlEE7VHYE>
Subject: Re: [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 15:50:44 -0000

Section 6., Relaying a Relay-Reply Message from the Network, does state:


   The LDRA MUST copy the link-layer and IP source address from the

   Relay-Reply message into the IP/UDP packet that is forwarded to the

   client.

This is required because the LDRA does not have any addresses of its own.

And, 6.2 also says:

   The LDRA MUST intercept and process all IP traffic received on the
   network-facing interface that has:

   o  a link-local scoped source address;

   o  a link-local scoped destination address;

   o  protocol type UDP; and

   o  destination port 547

  An LDRA MUST inspect the DHCP message type and only forward Relay-
   Reply messages.  Other DHCP message types MUST be silently discarded.

Which would indeed cause the LDRA to not do anything with the packet if the source address is not a link-local. But as the destination address is link-local (for LDRA), the source address SHOULD also be.

And, the relay closest to the server (relayB) isn't an LDRA relay, so why it would use the server's unicast address is very odd?

For DHCPv6, excepting the special requirements for LDRA because they have no IPv6 addresses, standard networking functions should be used and no special requirement exists for the 'standard' relay to follow these rules. If a relay is not an LDRA relay, it not be using LDRA rules; it should use a source address appropriate for the interface on which it will send out the relayed packet (appropriate here implies of the same or lesser scope than the destination address). If the next hop is indeed the LDRA relay, the appropriate address would indeed be a link-local address as that will be the destination address of the packet.

So it seems to me that relayB is broken.


  *   Bernie

From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Benjamin Kappel
Sent: Thursday, September 24, 2020 11:32 PM
To: dhcwg@ietf.org <dhcwg@ietf.org>
Subject: [dhcwg] A question regarding section 6.2 of RFC 6221

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