[v6ops] Re: [IPv6]Re: Is the P flag even necessary? M flag already does enough (Re: Re: A detail review of draft-ietf-6man-pio-pflag-04)
"Philipp S. Tiesel" <phils@in-panik.de> Mon, 09 September 2024 14:11 UTC
Return-Path: <phils@in-panik.de>
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 27E6CC15109A for <v6ops@ietfa.amsl.com>; Mon, 9 Sep 2024 07:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.504
X-Spam-Level:
X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 6cMHy1cTLHVr for <v6ops@ietfa.amsl.com>; Mon, 9 Sep 2024 07:11:13 -0700 (PDT)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A74C15107F for <v6ops@ietf.org>; Mon, 9 Sep 2024 07:11:11 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de ([IPv6:2a0a:4580:1018:0:5054:ff:feb2:aa6a]) by einhorn.in-berlin.de with ESMTPS id 489EB7mu2972546 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 9 Sep 2024 16:11:07 +0200
Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpa (Exim 4.94.2) (envelope-from <phils@in-panik.de>) id 1snf6g-0002cO-IS; Mon, 09 Sep 2024 16:11:06 +0200
From: "Philipp S. Tiesel" <phils@in-panik.de>
Message-Id: <F97308C4-390C-4FB2-948E-9E9AFC7902EC@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CCBA6F3B-F523-486C-BD1E-C67070F584FD"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Date: Mon, 09 Sep 2024 16:10:55 +0200
In-Reply-To: <CAJgLMKvYwZ85cUwdOgKziAgfM-xFyqRBAhENdydjAuznU0wm-g@mail.gmail.com>
To: Timothy Winters <tim@qacafe.com>
References: <CAN-Dau1R=oszbFx40a2U+Cnx354vi44Osk4ruuGcGDodzYKo7A@mail.gmail.com> <CAFU7BASyraNzL3htxxGkbeo5akCS-fLeH8_49GFb-fTc4TB0fQ@mail.gmail.com> <CAN-Dau2wNs=6QO6+vHHb0OQj2GV1HRe76BHo4rdomjCFUBES_g@mail.gmail.com> <CAPt1N1=NaGHxwQ29Z_Uk2royyb-Nix21kcY+12JC9=FDHtOQ+A@mail.gmail.com> <CAN-Dau1+WyvDyxXZBEKFVQ=Pjf38-ku_V9WbmLRBuys5v2R3Pg@mail.gmail.com> <CAPt1N1=1bXJrUNvSOe322SdTHGfe-Odw67NSnTE4NY0ZGyqJ8g@mail.gmail.com> <CAN-Dau3WdgCQFurWJjiC-Tr4a5hj25pjOvhNG8O=tne=JwA0eA@mail.gmail.com> <CAPt1N1nKo2b1XyW1-bBvAk9N2DuDkqbury6d+z900P+FxQTzrg@mail.gmail.com> <CAN-Dau2vMX4-6BD-SLQYk-DDj8ia3ySSLwLdMrRAU1canMjJsw@mail.gmail.com> <CAFU7BARVGGCaD-aO2Y+tE0c=JDY0kCjxmfZ-yUeSuR8S554omg@mail.gmail.com> <CAO42Z2w9PcN4ej6_Ly-jLoKcMeWP+-UA00xGHPG9jm2dz4_F2A@mail.gmail.com> <CAPt1N1nmk9+G_QadBV8D=Ty_0sxMFNYxijd+CERr7w8YWhJaxQ@mail.gmail.com> <CAO42Z2wAjamRg4sNnpAF0KBB5SrHgJUxcoy1rXvdrR3SWC3xog@mail.gmail.com> <CAKD1Yr33a9LZ4A0UZsFUMsR-SZ2GfO1q-2Cifts+KsAd_g5ObQ@mail.gmail.com> <CAO42Z2z8S426+G+AbpPDjrLdbmYDsArXaoAFMRuSbx41weWoHw@mail.gmail.com> <DB9PR07MB77717BE049C3B0DA943F19CCD6BE2@DB9PR07MB7771.eurprd07.prod.outlook.com> <CAPt1N1nNC0HEGOxP3-8-G+wdLxGywCOH-_4W7fodM+0YmtLcRA@mail.gmail.com> <CAJgLMKuwtpSpF2JnR5dYfh6hmo+-LunbJxe7Z6WTTaNh=nAtVw@mail.gmail.com> <CAPt1N1kx79vyHnU-=tfGLrRDgiRiKTu0D1aYdYn_vYTQUMK99w@mail.gmail.com> <AF94B18E-9173-4D6F-AEFB-BA8E3F860ABE@ilsf.eu> <CACyFTPHaELmgB4tyyHxG53TZQuD9g2tOv=zwQTeKjBkiceJ2BQ@mail.gmail.com> <CAJgLMKvYwZ85cUwdOgKziAgfM-xFyqRBAhENdydjAuznU0wm-g@mail.gmail.com>
X-Mailer: Apple Mail (2.3776.700.51)
Message-ID-Hash: HHDO5ISP3K3PDO6NCPK4UJGQ26BTN5QK
X-Message-ID-Hash: HHDO5ISP3K3PDO6NCPK4UJGQ26BTN5QK
X-MailFrom: phils@in-panik.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org>, IPv6 Ops WG <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [IPv6]Re: Is the P flag even necessary? M flag already does enough (Re: Re: A detail review of draft-ietf-6man-pio-pflag-04)
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bPzBKTHFhmlLlJgDZCR8rhb0S3g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>
Hi, > On 6. Aug 2024, at 15:04, Timothy Winters <tim@qacafe.com> wrote: > > > Hi Daryll, > On Mon, Aug 5, 2024 at 7:29 PM Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org <mailto:40daryllswer.com@dmarc.ietf.org>> wrote: >> > I’m currently struggling with a CE router that receives a /48 from the ISP and, whatever an inner router requests via IA_PD, this device always delegates /57. >> >> Can you share more details about the make/model of this router that does this /57 delegation by default? I've typically, taken the ISP's ia_pd, and then manually put it into pools, where a downstream client, can request, so for example, I get a /48, put it into a pool, and then each unique VLAN downstream can get a /60 or /56 via ia_pd with the DHCPv6 server running directly on the CE. > This is the current PD length that several DOCSIS operators use in the North America. I'm not aware of it being documented anywhere, but it seems to be "common" practice. There is a RIPE BCP for Europe to refer to: https://www.ripe.net/publications/docs/ripe-690/#4-2-2---48-for-business-customers-and--56-for-residential-customers >> >> -- >> Best Regards >> Daryll Swer >> Website: daryllswer.com <https://mailtrack.io/l/a696d9c0cc74ff3993981c8199a51589b9b7260c?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=1d721c58c64433e2> >> >> >> On Tue, 6 Aug 2024 at 03:03, Michael Breuer <michael.breuer@ilsf.eu <mailto:michael.breuer@ilsf.eu>> wrote: >>> Hey Ted, >>> >>> Thanks for bringing this up. >>> >>> I’m currently struggling with a CE router that receives a /48 from the ISP and, whatever an inner router requests via IA_PD, this device always delegates /57. >>> >>> Coming from this example to the more general. In my experience, CE router makers do a lot of weird things and, for the better of the Internet, they really need precise and good guidance. >>> >>> So, whatever the WG thinks is the right prefix length, the document should give explicit guidance on the prefix length. >>> >>> > On 5. Aug 2024, at 20:30, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote: >>> > >>> > On Mon, Aug 5, 2024 at 11:16 AM Timothy Winters <tim@qacafe.com <mailto:tim@qacafe.com>> wrote: >>> > v6ops has a draft for PD on the LAN to improve this situation. >>> > >>> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/ >>> > >>> > Please feel free to send comments, we are about to do WGLC on it. >>> > >>> > Hey, Tim. I hadn't read the document in a while. I see this text in the last requirement: >>> > >>> > The IPv6 CE Router SHOULD by default provision IA_PD IA prefixes with a prefix-length of 64. >>> > >>> > I read this as "if the DHCP client doesn't specify a narrower prefix, the CE router SHOULD .. 64" >>> > >>> > Is that what you intended? If not, I think you need to say more. If that is what you intended, this won't work, because if we stack CE routers, I expect every CE router to ask for a /48, rather than not specifying, and that would mean that we'd always delegate the narrowest remaining subset of the outer CE router's delegation to the first inner router that makes a request. >>> >>> _______________________________________________ >>> v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org> >>> To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org> >> _______________________________________________ >> v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org> >> To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org> > _______________________________________________ > v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org> > To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Ted Lemon
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Michael Breuer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Daryll Swer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Timothy Winters
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Michael Breuer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Ted Lemon
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Timothy Winters
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Timothy Winters
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Daryll Swer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Ted Lemon
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Daryll Swer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Philipp S. Tiesel
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Daryll Swer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Timothy Winters
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Ted Lemon
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Daryll Swer
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Timothy Winters
- [v6ops] Re: [IPv6]Re: Is the P flag even necessar… Ted Lemon