Re: [v6ops] Updating RFC 7084 - alternate logic
Timothy Winters <tim@qacafe.com> Wed, 30 November 2022 17:44 UTC
Return-Path: <tim@qacafe.com>
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 7A29EC14F749 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 09:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 (1024-bit key) header.d=qacafe.com
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 Rd5WOKrkjugq for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 09:44:53 -0800 (PST)
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109AFC14F741 for <v6ops@ietf.org>; Wed, 30 Nov 2022 09:44:52 -0800 (PST)
Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-1433ef3b61fso21855537fac.10 for <v6ops@ietf.org>; Wed, 30 Nov 2022 09:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zLAQhl87UQaV/tWMz1HnygHaGGrFqjnOPrXa10N1KQY=; b=gRySQS/n3ZCnbv58Hp2CxzEBIUk1kgecaFr2sVdFd+nxD0XH9xoDLXIcIq4vGXGhia w81LbVuaW14rCZ2zbt+eom4lNgTvadJYjyQc40I2/v2xFK+XwcK2vtekKOgsvtgYTQVI j5UXnCqia2MRoWxMIrXtJpgBfVJrYgVUfNB9Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zLAQhl87UQaV/tWMz1HnygHaGGrFqjnOPrXa10N1KQY=; b=mDKL1HiByW9J9CLaBeFKaA8d0UgD2lhBHYASh7dc0OyU+vcqvGMgZ9/B7K+RVwP+Yk DshB1gOjonzh4gJng8PFVtz5i6LroWCpgwqC28BPF1FuAPW7aSKPqPblVTc6Ai/p5qCe x8i8ln33tWYQjaIvsd/PowJSFI3ltyi2GsGTtygln4ul2s20tC67nQmMCEbDSfEjOQ3M 1Fe6/i017303KqPildW2dX7QZodXYLb7r+U325lqNKoiRHNjSU2ygZuXydfPxsaVluc8 7qVFX3lvtz1KkeYnVCS9Vmp2zsYBDAau/EZK7qagptvGxI7newY7EVuz/5iUSKIVXOgn 7BPw==
X-Gm-Message-State: ANoB5pniiR5IDnqvliHMW6XfAhfkkVOgczz2/AqCNMs/KAtZza2afL0z Mu9fwCYcOloXkuOmhQC+UmO/nNxNbO+gLCg78aOKNQ==
X-Google-Smtp-Source: AA0mqf7zHL9OPjuvZK8XwHqVWhV2NQG2jVqmNmEgt/FKvDN9oZInR0G9aLnHXbm/iEZBpd1iAWjRE3qWfJhnMeZKqss=
X-Received: by 2002:a05:6870:3482:b0:132:96be:4d67 with SMTP id n2-20020a056870348200b0013296be4d67mr38388753oah.22.1669830291850; Wed, 30 Nov 2022 09:44:51 -0800 (PST)
MIME-Version: 1.0
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <CWXP123MB516352292E412470C7CAB5E5D3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAJgLMKt8uvW77QL5emk5fUq+k2osyn5AHka7ye2+vSZS5A5PFQ@mail.gmail.com> <CWXP123MB51634E2B32B3643F0FC0274CD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM> <CAPt1N1nqjZyMdGcagHeqOwwZZay=gCdaP_iq-M=JGOZ92=t+aQ@mail.gmail.com> <CWXP123MB516372E5FF9C699BB8180FABD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP123MB516372E5FF9C699BB8180FABD3159@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
From: Timothy Winters <tim@qacafe.com>
Date: Wed, 30 Nov 2022 12:44:40 -0500
Message-ID: <CAJgLMKs=CTBAdW=-GaFT+j+rjnd=sdDe6ytoqpZhYE1KW29jUQ@mail.gmail.com>
To: Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>
Cc: Ted Lemon <mellon@fugue.com>, IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000061c29405eeb3a96c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KpeA4TBf7UuCMKyyGuE-T42ZqGo>
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: Wed, 30 Nov 2022 17:44:57 -0000
Hi Olorunloba, I'm suggesting that when users have there own gateways, that will still work with this update. As Ole mentioned, I think a flat model is easier than a tree model. ~Tim On Wed, Nov 30, 2022 at 12:42 PM Olorunloba Olopade < loba.olopade@virginmediao2.co.uk> wrote: > I agree with your general thoughts here – we should fix the spec where it > is wrong. However, I disagree with the specific here that the spec is > clearly wrong. > > > > And I’ve tried to argue from both angles – existing implementation and > right approach. > > > > To re-state my points on right approach > > - Resulting tree mirrors topology > - Removes limitation on a specific prefix size > - More flexible design > > > > And as per use case, I’ve seen scenarios where our customer doesn’t want > to use the ISP CPE (which is allocated the /56). They want to use their own > gateway, and might also want to have a separate DMZ for some internal > servers. In this scenario, the /64 isn’t adequate. > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* 30 November 2022 16:44 > *To:* Olorunloba Olopade <loba.olopade@virginmediao2.co.uk> > *Cc:* IPv6 Operations <v6ops@ietf.org>; Timothy Winters <tim@qacafe.com> > *Subject:* Re: [v6ops] Updating RFC 7084 - alternate logic > > > > I think it’s important to be clear on the distinction between what some > spec may require and what will actually work best. When the spec is wrong, > we should update it. This doesn’t mean every implementation has to be > updated, but if we realize that the spec is wrong, we should definitely fix > it, not live with it forever. > > > > In this case, the spec is clearly wrong: it’s requiring an allocation > strategy that will never in practice be correct. This is why we didn’t > adopt this work in the IETF. This was a known issue at the time. > > > > If you have some use case where you think this is the right thing, then > you should argue from that position. Arguing from the position that we > can’t fix a past mistake just doesn’t make sense. > > > > Op wo 30 nov. 2022 om 11:24 schreef Olorunloba Olopade <loba.olopade= > 40virginmediao2.co.uk@dmarc.ietf.org> > > Yes, it is a MUST in the requirements. > > > > I don’t have a large enough pool to conclude how widely it is implemented. > But it is implemented (somewhat) in ALL the CPEs I’ve come across. > > > > If the issue is the tree, this is a by product of the physical topology. > By avoiding a complex physical topology, we can avoid a complex tree. > Personally, I still prefer the tree as it mirrors the topology and would > make troubleshooting easier. I expect that it would be more difficult to > troubleshoot with relays. > > > > I also don’t see a problem with under utilised prefixes (something we > generally don’t have a problem with, when it comes to v6). I see more of a > problem where I want something later than a /64, and I cannot get it. Yes, > my scenario for wanting something larger than a /64 is possibly not SNAC > related, but this comes under general CE requirements. > > > > *From:* Timothy Winters <tim@qacafe.com> > *Sent:* 30 November 2022 15:56 > *To:* Olorunloba Olopade <loba.olopade@virginmediao2.co.uk> > *Cc:* IPv6 Operations <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 - alternate logic > > > > Hi Olorunloba, > > > > I was aware of the requirements, there were a couple of things I was > trying to avoid. This model creates a tree that can lead to under > utilized prefixes which was somehting I wanted to avoid. Additionally, I'm > aware that it's not widely implemented due to the complexity. Do you know > if all eRouters are required to support this? > > > > ~Tim > > On Wed, Nov 30, 2022 at 10:16 AM Olorunloba Olopade < > loba.olopade@virginmediao2.co.uk> wrote: > > Hello, > > > > Wile RFC7084 doesn’t cover the DHCP requirements, there are other spec > (e.g. cablelabs) that does. And we have implementation of this. > > > > I agree that we should support DHCP on the CE, but don’t support limiting > the sub-delegation to /64, which would make some of the current > implementations non-compliant. I will suggest something like the following, > which is an amendment of the cablelabs spec > > > > • If the Topology mode is set to “favor config”, then divide the delegated > prefix into sizes specified by the CE config. > > • If the provisioned MSO assigned IA_PD is smaller than a /56 (e.g., a > /60) and the Topology mode is set to "favor depth", the CE MUST divide the > delegated prefix on two (2)-bit boundaries into four (4) sub[1]prefixes by > default. > > • If the provisioned MSO assigned IA_PD is smaller than a /56 (e.g., a > /60) and the Topology mode is set to "favor width", the CE MUST divide the > delegated prefix on three (3)-bit boundaries into eight (8) sub[1]prefixes > by default. > > • If the provisioned MSO assigned IA_PD is a /56 or larger and the > Topology mode is set to "favor depth", the CE MUST divide the delegated > prefix on three (3)-bit boundaries into eight (8) sub-prefixes by default. > > • If the provisioned MSO assigned IA_PD is a /56 or larger and the > Topology mode is set to "favor width", the CE MUST divide the delegated > prefix on four (4)-bit boundaries into sixteen (16) sub-prefixes by default. > > • If the provisioned MSO assigned IA_PD is too small to divide in the > manner described, the CE MUST divide the delegated prefix into as many /64 > sub-prefixes as possible and log an error message indicating the fault > > > > > > *From:* v6ops <v6ops-bounces@ietf.org> *On Behalf Of *Timothy Winters > *Sent:* 18 November 2022 14:47 > *To:* IPv6 Operations <v6ops@ietf.org> > *Subject:* [v6ops] Updating RFC 7084 > > > > Hello, > > > > I've started a draft to update RFC 7084 to support prefix delegation on > the LAN interfaces. The current state of IPv6 in home networks is ISP are > assigning prefixes of appropriate sizes but they currently are under > utilized due to the lack of prefix delegation on LAN interfaces. > > > > This draft is an attempt to add that support to the draft. > > > > https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ > > > > This is only an update to 7084 at the moment, there has been some > discussion on the snac working group about leveraging this work as well. > > > > One item being discussed is this currently doesn't solve multi-homed > networks. > > > > I welcome any feedback about the proposal. > > > > ~Tim > > > > > > Save Paper - *Do you really need to print this e-mail?* > > > > This email contains information from Virgin Media and/or Telefonica UK > Limited (O2) and may be confidential and legally privileged. Statements and > opinions expressed in this email or any attachment may not represent either > those of Virgin Media or Telefonica UK Limited. Any representations or > commitments in this email or any attachment are subject to contract. The > information in this email is intended solely for the attention of the > addressee(s) and if you are not the intended recipient please delete it > (including any attachment) from your system, and be aware that any > disclosure, copying distribution or use of any of this information is not > permitted. > > > > If you are in receipt of a suspicious email or you have received an email > in error from Virgin Media, please report it to > www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please > report it to www.o2.co.uk/help/safety-and-security. > > > > *Registered offices:* > > > > *Virgin Media Limited*, 500 Brook Drive, Reading, RG2 6UU > <https://www.google.com/maps/search/500+Brook+Drive,+Reading,+RG2+6UU?entry=gmail&source=g>. > Registered in England and Wales: 2591237 > > > > *Telefonica UK Limited*, 260 Bath Road, Slough, Berkshire SL1 4DX > <https://www.google.com/maps/search/260+Bath+Road,+Slough,+Berkshire+SL1+4DX?entry=gmail&source=g>. > Registered in England and Wales: 1743099 > > > > *VMED O2 UK Limited*, Griffin House, 161 Hammersmith Road, London, > United Kingdom, W6 8BS > <https://www.google.com/maps/search/161+Hammersmith+Road,+London,+United+Kingdom,+W6+8BS?entry=gmail&source=g>. > Registered in England and Wales: 12580944 > > > > > > Save Paper - *Do you really need to print this e-mail?* > > > > This email contains information from Virgin Media and/or Telefonica UK > Limited (O2) and may be confidential and legally privileged. Statements and > opinions expressed in this email or any attachment may not represent either > those of Virgin Media or Telefonica UK Limited. Any representations or > commitments in this email or any attachment are subject to contract. The > information in this email is intended solely for the attention of the > addressee(s) and if you are not the intended recipient please delete it > (including any attachment) from your system, and be aware that any > disclosure, copying distribution or use of any of this information is not > permitted. > > > > If you are in receipt of a suspicious email or you have received an email > in error from Virgin Media, please report it to > www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please > report it to www.o2.co.uk/help/safety-and-security. > > > > *Registered offices:* > > > > *Virgin Media Limited*, 500 Brook Drive, Reading, RG2 6UU > <https://www.google.com/maps/search/500+Brook+Drive,+Reading,+RG2+6UU?entry=gmail&source=g>. > Registered in England and Wales: 2591237 > > > > *Telefonica UK Limited*, 260 Bath Road, Slough, Berkshire SL1 4DX > <https://www.google.com/maps/search/260+Bath+Road,+Slough,+Berkshire+SL1+4DX?entry=gmail&source=g>. > Registered in England and Wales: 1743099 > > > > *VMED O2 UK Limited*, Griffin House, 161 Hammersmith Road, London, > United Kingdom, W6 8BS > <https://www.google.com/maps/search/161+Hammersmith+Road,+London,+United+Kingdom,%0D%0AW6+8BS?entry=gmail&source=g>. > Registered in England and Wales: 12580944 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > Save Paper - *Do you really need to print this e-mail?* > > > > This email contains information from Virgin Media and/or Telefonica UK > Limited (O2) and may be confidential and legally privileged. Statements and > opinions expressed in this email or any attachment may not represent either > those of Virgin Media or Telefonica UK Limited. Any representations or > commitments in this email or any attachment are subject to contract. The > information in this email is intended solely for the attention of the > addressee(s) and if you are not the intended recipient please delete it > (including any attachment) from your system, and be aware that any > disclosure, copying distribution or use of any of this information is not > permitted. > > > > If you are in receipt of a suspicious email or you have received an email > in error from Virgin Media, please report it to > www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please > report it to www.o2.co.uk/help/safety-and-security. > > > > *Registered offices:* > > > > *Virgin Media Limited*, 500 Brook Drive, Reading, RG2 6UU. Registered in > England and Wales: 2591237 > > > > *Telefonica UK Limited*, 260 Bath Road, Slough, Berkshire SL1 4DX. > Registered in England and Wales: 1743099 > > > > *VMED O2 UK Limited*, Griffin House, 161 Hammersmith Road, London, > United Kingdom, W6 8BS. Registered in England and Wales: 12580944 >
- [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ole Troan
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Chongfeng Xie
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 David Farmer
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Gert Doering
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic otroan
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu