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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 07 October 2020 17:32 UTC

Return-Path: <Fred.L.Templin@boeing.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 A5FDF3A0CCE; Wed, 7 Oct 2020 10:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 rI1xbLJGugkK; Wed, 7 Oct 2020 10:32:06 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 A1C5E3A0CAB; Wed, 7 Oct 2020 10:32:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097HW1Xp030443; Wed, 7 Oct 2020 13:32:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602091924; bh=XoOPlJA0eOqXV4AJuU0I6R8ay3aJokpE/7zqVbNFzxE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B11F4VGTBxtcGu/cn+nXhmEEP+nwmK1+92YDPAGzTT03K61W7e28E0X0pl26BPdkX 93yQ9RK4ic4aIiSoxTrNez9M7VX+VpbW2hbztxA9lR6ViQSxq/U0nYgMJkpEQoLydy KM11U6FAtW7cResvLsOcT3M6DTohI0cxRF/wgo+/j5pwT5xYnPUj3JUSMd5MRoD0vt 8ZDRJsz7geeXgi+opS3T7zbX5snL+TRT+HvtKCaKwCZkVcwouDkludcYKIvmwiceA2 7K1ycDbAfP6u0XPnsnVQ8uhawGceT5FaOtHau8yEBSfItZGw9LsalBEucCwSNhBrlt B5TequXcl1U/Q==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097HVvdN029799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 13:31:57 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 10:31:55 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 10:31:55 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "otroan@employees.org" <otroan@employees.org>
CC: dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Thread-Topic: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AQHWnLXoMKJ/JAitSUqS66KPREymdamMqyOA//+MlACAACxM0A==
Date: Wed, 7 Oct 2020 17:31:55 +0000
Message-ID: <50e11f06bb764decb7b1f650e6c7728c@boeing.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <bb7c15dd4ba04730bd062a03861827ba@boeing.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> <ec6841fc378e4a09a7d1cc9e0c94ed5a@boeing.com> <872EAB12-8015-4591-A0D6-16F3623CA208@employees.org> <59358070ef5d4eaab46578c187f71bf1@boeing.com>
In-Reply-To: <59358070ef5d4eaab46578c187f71bf1@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 43141DF6448E8330DA0330B932FFF517A924C930173218E882692088A887D5102000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/v_NgKGV9ZSkGwfMRYWkWIQAkwk0>
Subject: Re: [dhcwg] [EXTERNAL] 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: Wed, 07 Oct 2020 17:32:09 -0000

An update has been posted that backs away from even doing DHCPv6 relay at all;
the function we are now calling for could better be described as a "DHCPv6 proxy"
where a middlebox acts as a DHCPv6 client on behalf of another node that is only
capable of using IPv6 ND messaging and not DHCPv6. The loop prevention test
discussed in this thread is still relevant, however - but we will not be referring
to what we do as "DHCPv6 relay" any longer.

Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, October 07, 2020 7:48 AM
> To: otroan@employees.org
> Cc: dhcwg <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man WG <ipv6@ietf.org>
> Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> Ole, I don't see a problem with implementing what their spec calls for in terms
> of dropping the looped traffic in the relay. I'm not as sure about sending back
> ICMPs though, so it is good that that is a "MAY".
> 
> Fred
> 
> > -----Original Message-----
> > From: otroan@employees.org [mailto:otroan@employees.org]
> > Sent: Wednesday, October 07, 2020 7:39 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: ianfarrer@gmx.com; v6ops list <v6ops@ietf.org>rg>; 6man WG <ipv6@ietf.org>rg>; dhcwg <dhcwg@ietf.org>
> > Subject: Re: [dhcwg] [EXTERNAL] 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 7 Oct 2020, at 16:26, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > >
> > > Ole, are you talking about the amnesiac client case - such as, the client reboots
> > > and then comes back to life again with no memory of its past lifetime? Our
> > > lease lifetimes are short - generally about 30 seconds - so any stale leases
> > > should be very transient. But, our relays also retain knowledge about the
> > > client<->server interactions and in some sense act as a proxy for the client.
> > > So, the relay itself will clean up after an amnesiac client when it detects
> > > that the client has suffered a traumatic event.
> >
> > No the routing loop detection code on the relay.
> >
> > Cheers,
> > Ole
> >
> > >
> > >> -----Original Message-----
> > >> From: otroan@employees.org [mailto:otroan@employees.org]
> > >> Sent: Wednesday, October 07, 2020 6:55 AM
> > >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > >> Cc: ianfarrer@gmx.com; v6ops list <v6ops@ietf.org>rg>; 6man WG <ipv6@ietf.org>rg>; dhcwg <dhcwg@ietf.org>
> > >> Subject: Re: [dhcwg] [EXTERNAL] 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 7 Oct 2020, at 15:50, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > >>>
> > >>> We implement DHCPv6 PD on relays. The relay is always co-resident with the
> > >>> delegating server and behaves according to RFC6221. Are we covered?
> > >>
> > >> What's your experience with implementing section 3.5 / R-4?
> > >>
> > >> Cheers,
> > >> Ole
> > >>
> > >>>
> > >>> Thanks - Fred
> > >>>
> > >>> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ianfarrer@gmx.com
> > >>> Sent: Wednesday, October 07, 2020 3:26 AM
> > >>> To: v6ops list <v6ops@ietf.org>rg>; ipv6@ietf.org
> > >>> Cc: dhcwg <dhcwg@ietf.org>
> > >>> Subject: [EXTERNAL] [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.
> > >>>
> > >>>
> > >>> Hi,
> > >>>
> > >>> 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
> > >>>
> > >>>   If the client loses information about a prefix that it is delegated
> > >>>   while the lease entry and associated route is still active in the
> > >>>   delegating relay, then the relay will forward traffic to the client
> > >>>   which the client will return to the relay (which is the client's
> > >>>   default gateway (learnt via an RA).  The loop will continue until
> > >>>   either the client is successfully reprovisioned via DHCP, or the lease
> > >>>   ages out in the relay.
> > >>>
> > >>> Ole’s comment: "And I would also be happy if we could have some implementors chime in with a "we are happy and able to
> > >> implement this requirement”.”
> > >>>
> > >>>
> > >>> We would appreciate any feedback on this, especially from anyone with experience implementing DHCPv6 relays with PD.
> > >>>
> > >>>
> > >>> Thanks,
> > >>> Ian
> > >>>
> > >>>
> > >>> Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> dhcwg mailing list
> > >>> dhcwg@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/dhcwg
> > >
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops