IETF Logo Mail Archive

Re: [v6ops] Updating RFC 7084 - alternate logic

Gert Doering <gert@space.net> Mon, 05 December 2022 13:45 UTC

Return-Path: <gert@space.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA42C1524A8 for <v6ops@ietfa.amsl.com>; Mon, 5 Dec 2022 05:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx3UiWlMR4zg for <v6ops@ietfa.amsl.com>; Mon, 5 Dec 2022 05:45:07 -0800 (PST)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 6A5ECC1524A2 for <v6ops@ietf.org>; Mon, 5 Dec 2022 05:45:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1670247908; x=1701783908; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qjlWVvY5IAXfVv8HKoYzt3rjKn6s4GujF1T+I5Md0kM=; b=d0OtzokBRkjLQpYJBP5Oy/LssN61+y4g1jyDHx8+a5YfiifQEMnkS7tu ABJ36cgoNwn2Gs3uanXFKRuFxbYTfdaKd763bxmAl62mk2AEKyXYIzO1m 6DjHMY7PZd+99B5bPq8TdAkjQdwk10vNS6sg9GTrOepkTBg8YTjuVtpfA WhNyNhRpRnfGCPQ5W+4GUQvctHDEyh9iHchobQ5GSjma066chEREtiCJe QF6jBMpJPcXoYE/LJ4dAvXjbnLLLUuodLo9LVZh7X53s+eR9aa/CSOFRW lBNzWr+t1QN4Hpdj8qMqdidQN91MXpHyF9tCnzmhOB5heQOfoMsXfP6xk A==;
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2022 14:45:02 +0100
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B100941FF8 for <v6ops@ietf.org>; Mon, 5 Dec 2022 14:45:01 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 85E5B4105D; Mon, 5 Dec 2022 14:45:01 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 7F2821103EB; Mon, 5 Dec 2022 14:45:01 +0100 (CET)
Date: Mon, 05 Dec 2022 14:45:01 +0100
From: Gert Doering <gert@space.net>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>, "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <Y4313SQDIpYMfclu@Space.Net>
References: <CAPt1N1nqjZyMdGcagHeqOwwZZay=gCdaP_iq-M=JGOZ92=t+aQ@mail.gmail.com> <CWXP123MB516372E5FF9C699BB8180FABD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAJgLMKs=CTBAdW=-GaFT+j+rjnd=sdDe6ytoqpZhYE1KW29jUQ@mail.gmail.com> <CWXP123MB51634A6A6D20796AE43A6207D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <db23f437-7dd8-ad24-0c72-e3164dd43f4a@gmail.com> <CWXP123MB516311D9A5E90628BC8E8FD2D3149@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <DU0P190MB1978713EFCC2841F4B762F05FD149@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <5782557e-e2d8-48c0-b75c-d67d7e6cb228@gmail.com> <DU0P190MB19782F86F06A030BD9AC4836FD189@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <9169a670-1141-d688-fd7c-68f06c221378@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9169a670-1141-d688-fd7c-68f06c221378@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Y8JO5_7MuvVOiCqHeiYnSh65_cw>
Subject: Re: [v6ops] Updating RFC 7084 - alternate logic
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2022 13:45:12 -0000

Hi,

On Mon, Dec 05, 2022 at 02:31:21PM +0100, Alexandre Petrescu wrote:
> I meant there is a WiFi Access Point in router mode between
> the snac router and the ISP's inhome router.  It is because of that
> additional intermediary router that DHCPv6-PD allocations of /64s might 
> not work.
> 
> To facilitate my expression, allow me to draw a picture:
> 
>                  /-----------\      ----       ------------        -----
>    Internet --- |ISP's inhome |--- | AP |-----| snac router|------|IPv6 |
>                  \  router   /      ----       ------------       |light6
>                   -----------                                     |bulb |
>                                                                    -----

If there is an AP in "router mode", that AP needs to do "router things",
which means "handle DHCPv6 PD from the snac router to the ISP's router".

No different from any other combination of routers on a string - each
of the intermediates need to receive DHCPv6 PD requests from "downstream"
routers and forward "upstream" (and on the way back, install routing table
entries, of course).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email