Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

"Bernie Volz (volz)" <volz@cisco.com> Thu, 08 October 2020 21:18 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 736DF3A0DCA; Thu, 8 Oct 2020 14:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=cm5kdcnC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ax54wx/e
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 KuSx4xyFkeDj; Thu, 8 Oct 2020 14:18:51 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518453A0DAD; Thu, 8 Oct 2020 14:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8396; q=dns/txt; s=iport; t=1602191924; x=1603401524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=cm5kdcnCUwXBg0YII/3gZujF7vLBQUfATPgFkpgDsx12DiWupcv33cPn rHxGpCIWlLWJFoc+8D80bQAUewu7vJxSiyzNctQ8vPDv/dbHbJVF3xX6u GiachNO9cHBGSR6rR+keHPUP0BOQp5VZm+phiLk0ibZgHQ21RqAmaqVxH g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AnmP32hfhdMrP/jRyGffYIu1ilGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQBdfU7uICgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7dxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYBQD9gH9f/4kNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqEM4NGA41RmHuBQoERA1ULAQEBDQEBGAs?= =?us-ascii?q?KAgQBAYRKAheBcwIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBARA?= =?us-ascii?q?REQwBASwLAQQHBAIBCBEEAQEBAgIfBAMCAgIlCxQBCAgCBA4FCBqDBYJLAw4?= =?us-ascii?q?gAQ6eKQKBOYgsNXaBMoMBAQEFgTMBg2gYghADBoEOKoJyg22CRIQSG4IAgRF?= =?us-ascii?q?Dgk0+ghpCAQGBICcaBTOCXTOCLZAigyKSJWCRFAqCaJsJgxOKBoU/igmET5M?= =?us-ascii?q?boB0CBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2OHzeDOoUUhUJ0AjUCBgEJAQE?= =?us-ascii?q?DCXyMOwGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.77,352,1596499200"; d="scan'208";a="557625360"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 21:18:43 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 098LIhKh028983 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 21:18:43 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 16:18:42 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 16:18:42 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 16:18:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ObjKcNnnhohB1qXLb2VP5JTELs8kq/tZGgxfEv+l2zZe2RorsYU/hDqP7ZQhnEWqEAtuJ4DpudS5ZfrgsagCMh/n0ijXZo29BlmbYV3kiYP1uXDDxVDNwTO8RksxI7P6ytGqE7SKSs/RbwqPOn/lHF7g7dNxJvo39icYtjCukohi+NqAEm0MGeuGEUUCLKc7V+mXAhiBc8ymD8HmFz/dW+pXWXVEgDmDCfppERiw0KwTOnRgKvAYW90tdEh1Mxxh6A0K1i2ITUPjTNxGIwGvW/bQzJD+sjKJicthL3vvCQZmvwl1NsqYJrg/fRN9qibzTEzDN/2gtJWHo8LHFa+xpw==
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=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=HZAWAAbFhacep52F+T44mfVtEHzhD/Qw3SJKVmeO0fOjnmfMZ5GIgkhHDpaPnV69NvBYiI1d2PDXNNo0IAy7l2judu0fW6mB4Ca1JEidX5B0RaZL2rD3ZvAntC6mQ2+9b+fqsKRlenYyR6IK5wHz79df6e6WHrfSiwONY6kfR494aG7x5wSZYeUo5wmD+Lc2TpJ+XX9RuQHym5GvJYXuGSB9N7vLjGQxL2ekQeEg+A3sX/vfXMfSQ24SpNKjpSH6JwjxxLWF0xLScxKM8JLVtIoGhlfyl41amS7MTMRDFvK4rmOMurCuNtKPUpLpPP2Cac4Sl42YexsWEVADtcu+EQ==
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=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=ax54wx/eTCbMu9DG5Nx/jpa360MuoKsm2pi6JKim/UCf5/b5qsMEA27fifncXQ9I5gKXMHd5LTj4IkD3udPrvmX1bLO6q3q4ENc+jrf3uf8eIW3YvVqmmrQh25jC+bM0HH2iyYnIxBU8Ufj+ar1aDG/AJVvlYajRKBFGirpMlGc=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR1101MB2212.namprd11.prod.outlook.com (2603:10b6:405:52::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Thu, 8 Oct 2020 21:18:41 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470%3]) with mapi id 15.20.3455.024; Thu, 8 Oct 2020 21:18:41 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: dhcwg <dhcwg@ietf.org>, 6man <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AQHWnY5pT1BZPqcqAkuJPITGjT8WRqmONFtw
Date: Thu, 8 Oct 2020 21:18:41 +0000
Message-ID: <BN7PR11MB2547029C572CB32F3C593AD7CF0B0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com> <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com> <D259F559-8528-428A-A9DF-0D9FB07E6BE4@gmx.com>
In-Reply-To: <D259F559-8528-428A-A9DF-0D9FB07E6BE4@gmx.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [24.233.121.124]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 435acfb5-036d-4342-0551-08d86bcfbb02
x-ms-traffictypediagnostic: BN6PR1101MB2212:
x-microsoft-antispam-prvs: <BN6PR1101MB221293C35C2299471E3AF9E1CF0B0@BN6PR1101MB2212.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: 5G2fCQ/KvpFbPejz4n+agM0xze8WUSEx1r1c3q6/lcE9d04DpWBgNPHl7+7LfQ9WL3QF/lNHl9zKuUywSrEMzN3jh6iLmGYzlYD8D8gVUURNgxsi/nDkfUdQyrA9CxhcebotXqQ7VSK+UpqPdYASxg1Ppyb1FHpiv24LxGNCxnmhdTYE4Uu/9fFh7A+/Bc+rvbzyJbGhma+2T1Q/YSVmQJATLpVnBY6CBKg1FoERGkCPPabS0DclAJSKnRUZFcbAvLugPcUX9bfC0P4AFV7BmEF0KDhepuGiY4BXifr2Gu2xjIAWgJpb5KncDY85EJVShFj2FiDRnE1ZHOv2rgjZrj2NiKRUsSxAK6OPgxIrbWpIarTB7v15Bdjs3/zWQH1fAuhAqvwDr1buo8UMAtk5E6b4ni9ivm66OiqTIn+2XWXHNvVoNnIk/SLUIpV0ZhpDPRHBfravGs1bpC1mMoL/pA==
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:(396003)(376002)(366004)(346002)(39860400002)(136003)(53546011)(52536014)(66946007)(5660300002)(6506007)(71200400001)(76116006)(8936002)(66476007)(66556008)(64756008)(8676002)(66446008)(83080400001)(478600001)(966005)(83380400001)(66574015)(7696005)(2906002)(55016002)(110136005)(54906003)(86362001)(186003)(26005)(4326008)(9686003)(316002)(33656002)(518174003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 2zVWTW9WEOee+xffPBNSZ9cqJV6M68VRp1V62VDizccbXmlakHuipd6MxTEDRNLuVi6voYON/mTpIMiirh85u18HM5zChxXH3iG/1e2ls2QjxrjTkZKqRZSpzL4SuXSaPInvqW0L8TMuTlKbywemUtH+0DeKbWjNy8yoBc+d7k6KEzSaHeRsvOHC/W5/Mna7wFjgIAXeEIxAgOPq8IH+okchI/EPNOy5UrWB0evseuq063lbsuGXE5OyfIZvCVSfVgpVMvynCq2DUcwPBJRiPYX8Btn8YvwD9IaLK5iOrSqYuCbPTFKbc4tXSf7gU0mh5KQwui3Kf82qyMyEJ/HXl1E+j0IwS4d7dBqIuF7kdJB/b5NSaNcEAawyDSOxEKfqRNtmfNjFMbXHG2uI653HNerMGRxPLl5meILQhAUNNEKrQmlgFCaPkFcAnEwoTYenLCNvcZ1HRYpNOzS5ejhYiUbXioPz/xD2P+oOihqpSjN944ZSuzraPCWvn2Xq0Z/lpgGnRo/4zIHmqvr0+z5dBSU1KDY+0LX2EQQcGY6D65ED3cVJcnh9LJy62gYmm6eyveGWeQn5sRV/YU+bZ+CVrGchkVZHMaZ87oviH42VsV8rF6Cz/x9yOzaljvFwwLBuQCZB4vL1FcgAj42HBA6J/Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 435acfb5-036d-4342-0551-08d86bcfbb02
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 21:18:41.1719 (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: KnKVdmoBjjuM21njnOzzIpoTsiZyd8vQe/mvtB4vfMkJzH9Sdxvra4oXzPHidzpo
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2212
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/vdc2CoVlJCXc1kq-sAQpTgonMwY>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
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: Thu, 08 Oct 2020 21:18:54 -0000

Is this a model where in your Figure 1, you have a switch between the PD Client and Delegating Relay and you might have other devices off that switch?

In that case, why would any of the devices off that switch be using the prefix given the PD Client? How would they learn this? I don't think the PD Client nor Delegating Relay should be doing RAs with the PD prefix in them (or a sub-prefix).

If the PD Client is doing that, then any devices off the switch would be using it as the default router for that prefix and not the delegating relay? And, hence no traffic should be doing to the delegating relay with the PD destination address.

Or, do I have this model wrong?

- Bernie

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of ianfarrer@gmx.com
Sent: Thursday, October 8, 2020 12:16 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: dhcwg <dhcwg@ietf.org>rg>; 6man <ipv6@ietf.org>rg>; v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi Fred / Jen

Please see inline below.

Thanks,
Ian

> On 8. Oct 2020, at 17:51, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Jen,
> 
>> What would happen if the *second* device sends traffic towards the 
>> delegated prefix? As that device is usig the relay as its default 
>> gateway, the traffic would be sent there.
>> If I read the draft correctly, instead of forwarding the traffic and 
>> maybe sending the redirect, the relay is expected to drop it?
> 
> The way that I interpret it, when the second device sends the traffic 
> to the relay, the relay would still forward the traffic to the client, 
> which would then forward the traffic back to the relay, then at that 
> point the relay would drop the traffic. Unless the second node somehow 
> has a way of knowing that the client has entered into an amnesiac 
> state and then does a malicious "flood-ping", we can expect 
> applications to quickly learn that the IP addresses of the client are 
> no longer reachable. Plus, these amnesiac conditions can be expected 
> to be rare and transient; not steady-state.
> 
> Fred

[if - If I understand Jen’s question correctly, it’s related to the ‘working’ case.
i.e. the client has completed PD, installed the routes and the relay has the relevant lease info/routes.

When the second device sends via the default route with a destination address in the delegated prefix, R-4 in it’s current form would cause the traffic to be dropped.
As the relay doesn’t forward the packet, it can’t send a redirect (per RFC4681), so the second device can’t forward.

Looking at this, I think there are deployment scenarios where R-4 isn’t going to work. 

My suggestion would be to make R-4 disable-able.]



> 
> 
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
>> Sent: Wednesday, October 07, 2020 6:25 PM
>> To: ianfarrer@gmx.com
>> Cc: dhcwg <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man 
>> <ipv6@ietf.org>
>> Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors 
>> regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> This message was sent from outside of Boeing. Please do not click 
>> links or open attachments unless you recognize the sender and know that the content is safe.
>> 
>> 
>> On Wed, Oct 7, 2020 at 9:25 PM <ianfarrer@gmx.com> wrote:
>>> We are currently finishing WGLC for this draft. It describes 
>>> requirements for a 'DHCPv6 Delegating Relay' - this is a router 
>>> functioning
>> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This 
>> is a common deployment scenario, but RFC3633/8415 only really 
>> describes PD using a Delegating Router - i.e the L3 edge also 
>> functions as a DHCPv6 server with no relay. When the relay and server 
>> functions are performed by separate devices a number of problems with 
>> how relays behave have
>>> been observed, so this document addresses them.
>>> 
>>> During WGLC for this, Ole raised a comment related to one of the routing requirements:
>>> 
>>> R-4:    If the relay has learned a route for a delegated prefix via a
>>>           given interface, and receives traffic on this interface with
>>>           a destination address within the delegated prefix (that is
>>>           not an on-link prefix for the relay), then it MUST be
>>>           dropped.  This is to prevent routing loops.  An ICMPv6 Type
>>>           1, Code 6 (Destination Unreachable, reject route to
>>>           destination) error message MAY be sent back to the client.
>>>           The ICMP policy SHOULD be configurable.
>>> 
>>> The problem that this is trying to solve is:
>>> 
>>> 3.5.  Forwarding Loops between Client and Relay
>> 
>> I might be missing smth but...
>> Let's say I have a relay and it's 'south' (client-facing) interface 
>> is connected to a switch. The client AND second device (another 
>> router or a host) are connected to the same segment.
>> The client gets a prefix, the relay 'learned' (or shall we call it
>> 'install'?) the route for the delegated prefix pointing to its 'south'
>> interface with the client address as a next-hop.
>> What would happen if the *second* device sends traffic towards the 
>> delegated prefix? As that device is usig the relay as its default 
>> gateway, the traffic would be sent there.
>> If I read the draft correctly, instead of forwarding the traffic and 
>> maybe sending the redirect, the relay is expected to drop it?
>> 
>> --
>> SY, Jen Linkova aka Furry
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops