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 08:01 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 A57373A0D35; Fri, 9 Oct 2020 01:01:55 -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 wKxMwBDZUfIp; Fri, 9 Oct 2020 01:01:54 -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 34E673A0D34; Fri, 9 Oct 2020 01:01:52 -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 09981W03008331 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 9 Oct 2020 10:01:32 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1602230492; bh=m/5q1qUCsk0PjQwzbcRdAezawqqazdkr7QFGGYDs3oY=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=kSCvxXHwuBHhPkv2IzT5Yn34iQIKbs856EWusLIEI5N6IzXQHwQC6DPqBtQeWMz4z ovnXYtpyPLIaf0rgw0g1Juf96zVzyhr26EaMw6xKt2s3HEWjn1TvYCIgrrKw4xVILP MGS3iiKEnwQ4w8Rg4hVO1WIpeUrPeYDWwmDtRvGU=
Received: from bjorn by miraculix.mork.no with local (Exim 4.94) (envelope-from <bjorn@mork.no>) id 1kQnLH-001CFy-Fe; Fri, 09 Oct 2020 10:01:31 +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: <87h7r3hmuk.fsf@miraculix.mork.no> <36C7513E-BDF1-4189-89F6-5BB46797FB99@employees.org>
Date: Fri, 09 Oct 2020 10:01:31 +0200
In-Reply-To: <36C7513E-BDF1-4189-89F6-5BB46797FB99@employees.org> (Ole Troan's message of "Fri, 9 Oct 2020 09:43:07 +0200")
Message-ID: <875z7jhlpg.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/bMH7NoaswxIMdIUsZHMSBDD-E0g>
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 08:01:56 -0000

Ole Troan <otroan@employees.org> writes:
>> On 9 Oct 2020, at 09:37, Bjørn Mork <bjorn@mork.no> wrote:
>> 
>> 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.
>
> I think the premise here is that it’s a multiaccess interface. So
> wouldn’t that rule break traffic from B to A? If the premise here is
> that both customer A and B are on the same interface.
>
> If it was one l3 interface per customer then sure it’s easy. 

Right.  The requirement is impossible with that premise. So that surely
cannot be the intention?  I agree that this should be clarified.



Bjørn

v2.23.0 | Report a Bug | By Email