IETF Logo Mail Archive

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

Bjørn Mork <bjorn@mork.no> Fri, 09 October 2020 07:37 UTC

Return-Path: <bjorn@mork.no>
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 5B6BD3A0CF4; Fri, 9 Oct 2020 00:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 CtpxZwz8gidb; Fri, 9 Oct 2020 00:37:20 -0700 (PDT)
Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 1A7143A0B41; Fri, 9 Oct 2020 00:37:18 -0700 (PDT)
Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id 0997apjn026280 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 9 Oct 2020 09:36:53 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1602229014; bh=fw5we2dqpCxHT2H2nRqU6czmDXUvGhbLb0zf+LTBGTQ=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=EKLVBFmzzyD21SM/AGtiEFihqLAcVxSL9sfTy8RCHREe7dV6zPH1Mtw5TyHBJW3BM SZupNdp90xw8/2PSXgEatD2YrWkbxLajWWkHLFENoDNratvdSBrSC4P59bhC5Dvmqz /zN2NeCrNupHtU8kG+QkpLfB4zemofLnZA8X3OXI=
Received: from bjorn by miraculix.mork.no with local (Exim 4.94) (envelope-from <bjorn@mork.no>) id 1kQmxP-001CDJ-9p; Fri, 09 Oct 2020 09:36:51 +0200
From: Bjørn Mork <bjorn@mork.no>
To: Ole Troan <otroan@employees.org>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Organization: m
References: <ff36a6d9f0834b5bbf331c6c40df16b8@boeing.com> <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org>
Date: Fri, 09 Oct 2020 09:36:51 +0200
In-Reply-To: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> (Ole Troan's message of "Thu, 8 Oct 2020 23:59:40 +0200")
Message-ID: <87h7r3hmuk.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.102.4 at canardo
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/sg1fOZAUALRxfoqZ08kMwbGHNRc>
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: Fri, 09 Oct 2020 07:37:22 -0000

Ole Troan <otroan@employees.org> writes:
>> On 8 Oct 2020, at 23:55, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>> 
>> Now, client B sends packets destined to an address in A to R, and R forwards the
>> packets to client A since it still has a route for A. When the packets arrive at A,
>> however, A forwards them back to R since it has "forgotten" that it holds the
>> prefix A. When R receives the packets from A with destination address also
>> from prefix A, it must drop them instead of forwarding them back to A to
>> avoid looping.
>
> This is indeed what the requirement in the draft says. 
>
> This isn’t quite obvious how to implement, which why I brought up the
> question if anyone had implemented this. And if it’s supported in hw
> etc.

I don't know anything about hardware implementations or scaling in
general, but this seems easy to implement using the Linux kernel routing
facilities:

 ip -6 rule add pref 1234 iif if_A to prefix_A blackhole

where 'if_A' is the interface connecting A to R and 'prefix_A' is the
prefix assigned to A.


Bjørn

v2.23.0 | Report a Bug | By Email