[pim] Re: Last Call: <draft-ietf-pim-gaap-18.txt> (Group Address Allocation Protocol (GAAP)) to Experimenta l RFC
Mike McBride <[email protected]> Sat, 18 Jul 2026 04:14:17 +0200
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CAL3FGfxLi=aK+r5f=6_DzQCsivzmNORDq96ZSX7Q_t+-TOGF6g@mail.gmail.com> |
--===============7084422530677928639== Content-Type: multipart/alternative; boundary="000000000000a091850656d93b6c" --000000000000a091850656d93b6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nico, On that last question regarding encryption, how about we add this one sentence as you suggested: "Encryption SHOULD only be enabled within a coordinated administrative domain where all GAAP nodes share the same encryption configuration and key."? Thank you for the review. mike On Fri, Jul 17, 2026 at 9:53=E2=80=AFPM Dino Farinacci <[email protected]= > wrote: > Some quick replies. > > > On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak <[email protected]> wr= ote: > > > > Hi, > > > > I think this draft is a great step forward for multicast address > allocation, but I have some comments regarding section 8. > > Thanks. > > > How are collisions meant to be resolved across GAAP nodes with differen= t > encryption configurations, or lack > > These would be different domains that don't connect to each other. You ca= n > run separate instances, especially when there are multicast group > boundaries so the well-known groups stay disjoint. > > > thereof? It sounds like they'd just be allowed to collide given the tex= t > in section 8, which doesn=E2=80=99t seem ideal? > > If there are no group boundaries, then the packets go to all members of > the well-known group but are dropped by the ones without common encryptio= n > keys. > > > I'd imagine that applications wanting to use GAAP as a zero > configuration multicast address allocation protocol as highlighted in > [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] would just not use encryption > for "zero configuration=E2=80=9D? > > Right, a tradeoff between plug-and-play and secure communication. > > > Perhaps section 8 should be amended to only suggest encryption when > deployed in a coordinated administrative domain where all GAAP nodes shar= e > the same encryption configuration? > > I thought we had something like that. I'll leave this for Mike and Stig t= o > comment about. > > Dino > > > > > Thanks, > > Nico > > > >> On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG <[email protected]= g> wrote: > >> > >> > >> The IESG has received a request from the Protocols for IP Multicast WG > (pim) > >> to consider the following document: - 'Group Address Allocation Protoc= ol > >> (GAAP)' > >> <draft-ietf-pim-gaap-18.txt> as Experimental RFC > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > final > >> comments on this action. Please send substantive comments to the > >> [email protected] mailing lists by 2026-08-03. Exceptionally, > comments may > >> be sent to [email protected] instead. In either case, please retain the > beginning > >> of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> This document describes a design for a lightweight decentralized > >> multicast group address allocation protocol (named GAAP and > >> pronounced "gap" as in "mind the gap"). The base allocation protoco= l > >> requires no centralized service and minimal configuration, although > >> deployments using encryption or administrative scoping may require > >> configuration. The protocol runs among group participants which nee= d > >> a unique group address to send and receive multicast packets. > >> Tailored for IPv4 and IPv6 networks, this design offers a simple, > >> lightweight option rather than extending an existing protocol. > >> > >> > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/ > >> > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> pim mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > --000000000000a091850656d93b6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Nico,</div><div><br></div><div>On that last questi= on regarding encryption, how about we add this one sentence as you suggeste= d: "Encryption SHOULD only be enabled within a coordinated administrat= ive domain where all GAAP nodes share the same encryption configuration and= key."? Thank you for the review.</div><div><br></div><div>mike</div><= br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class= =3D"gmail_attr">On Fri, Jul 17, 2026 at 9:53=E2=80=AFPM Dino Farinacci <= <a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some quick replie= s.<br> <br> > On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > Hi,<br> > <br> > I think this draft is a great step forward for multicast address alloc= ation, but I have some comments regarding section 8.<br> <br> Thanks.<br> <br> > How are collisions meant to be resolved across GAAP nodes with differe= nt encryption configurations, or lack<br> <br> These would be different domains that don't connect to each other. You = can run separate instances, especially when there are multicast group bound= aries so the well-known groups stay disjoint.<br> <br> > thereof? It sounds like they'd just be allowed to collide given th= e text in section 8, which doesn=E2=80=99t seem ideal?<br> <br> If there are no group boundaries, then the packets go to all members of the= well-known group but are dropped by the ones without common encryption key= s.<br> <br> > I'd imagine that applications wanting to use GAAP as a zero config= uration multicast address allocation protocol as highlighted in [I-D.ietf-p= im-zeroconf-mcast-addr-alloc-ps] would just not use encryption for "ze= ro configuration=E2=80=9D?<br> <br> Right, a tradeoff between plug-and-play and secure communication.<br> <br> > Perhaps section 8 should be amended to only suggest encryption when de= ployed in a coordinated administrative domain where all GAAP nodes share th= e same encryption configuration?<br> <br> I thought we had something like that. I'll leave this for Mike and Stig= to comment about.<br> <br> Dino<br> <br> > <br> > Thanks,<br> > Nico<br> > <br> >> On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG <<a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</a>&g= t; wrote:<br> >> <br> >> <br> >> The IESG has received a request from the Protocols for IP Multicas= t WG (pim)<br> >> to consider the following document: - 'Group Address Allocatio= n Protocol<br> >> (GAAP)'<br> >>=C2=A0 <draft-ietf-pim-gaap-18.txt> as Experimental RFC<br> >> <br> >> The IESG plans to make a decision in the next few weeks, and solic= its final<br> >> comments on this action. Please send substantive comments to the<b= r> >> <a href=3D"mailto:[email protected]" target=3D"_blank">last-call@= ietf.org</a> mailing lists by 2026-08-03. Exceptionally, comments may<br> >> be sent to <a href=3D"mailto:[email protected]" target=3D"_blank">iesg= @ietf.org</a> instead. In either case, please retain the beginning<br> >> of the Subject line to allow automated sorting.<br> >> <br> >> Abstract<br> >> <br> >> <br> >>=C2=A0 =C2=A0This document describes a design for a lightweight dec= entralized<br> >>=C2=A0 =C2=A0multicast group address allocation protocol (named GAA= P and<br> >>=C2=A0 =C2=A0pronounced "gap" as in "mind the gap&qu= ot;).=C2=A0 The base allocation protocol<br> >>=C2=A0 =C2=A0requires no centralized service and minimal configurat= ion, although<br> >>=C2=A0 =C2=A0deployments using encryption or administrative scoping= may require<br> >>=C2=A0 =C2=A0configuration.=C2=A0 The protocol runs among group par= ticipants which need<br> >>=C2=A0 =C2=A0a unique group address to send and receive multicast p= ackets.<br> >>=C2=A0 =C2=A0Tailored for IPv4 and IPv6 networks, this design offer= s a simple,<br> >>=C2=A0 =C2=A0lightweight option rather than extending an existing p= rotocol.<br> >> <br> >> <br> >> <br> >> <br> >> The file can be obtained via<br> >> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/" = rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draft= -ietf-pim-gaap/</a><br> >> <br> >> <br> >> <br> >> No IPR declarations have been submitted directly on this I-D.<br> >> <br> >> <br> >> <br> >> <br> >> <br> >> _______________________________________________<br> >> pim mailing list -- <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a><br> >> To unsubscribe send an email to <a href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a><br> > <br> <br> </blockquote></div></div> --000000000000a091850656d93b6c-- --===============7084422530677928639== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============7084422530677928639==--