Feedback-ID: i1136489e:Fastmail
MIME-Version: 1.0
Date: Fri, 04 Jul 2025 18:26:42 +0200
From: "Ted Lemon" <mellon@fugue.com>
To: "Nick Buraglio" <buraglio@forwardingplane.net>
Message-Id: <e16baa49-9e68-4867-9b00-892eec67ebb5@app.fastmail.com>
In-Reply-To: 
 <CACMsEX-Vbd=XkQzEEN3jn9Oez1RQ5QpqrWcXibHCFfqK+OO_Ww@mail.gmail.com>
References: 
 <175071730132.502784.5026151083314117768@dt-datatracker-6754d69b7c-p2xd7>
 <CAKD1Yr3zcThnQx2qE3xB3n+tmzgq7vAZ9nH4CcEVHHfp=AH44Q@mail.gmail.com>
 <CACMsEX8eUxE2c0HPBpRqziJ=mL=+ef1iNRxpqdjT7cDBG-3gVw@mail.gmail.com>
 <4AE1AC9E-5603-4EB2-AE40-F946AB60B1E9@gmail.com>
 <CACMsEX-M5u6gv0kaSxM0uezy8f==caUwUKudDE1d-Jrb1ADVZA@mail.gmail.com>
 <16856.1751464682@obiwan.sandelman.ca>
 <1D359801-41B8-410F-9AFE-9FFA92A69941@fugue.com>
 <32467.1751482387@obiwan.sandelman.ca>
 <62c4ec95-c647-474f-b2a6-1fcc6ab67193@app.fastmail.com>
 <CACMsEX-Vbd=XkQzEEN3jn9Oez1RQ5QpqrWcXibHCFfqK+OO_Ww@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary=b356eb03ef5348dc932364c4849f86a2
Message-ID-Hash: QW3WPIMKVVXF7HLJFGRYROT3ETEWTEFE
CC: Michael Richardson <mcr+ietf@sandelman.ca>, snac@ietf.org,
 Bob Hinden <bob.hinden@gmail.com>,
 draft-ietf-6man-rfc6724-update.authors@ietf.org,
 6man Chairs <6man-chairs@ietf.org>,
 "6man-ads@tools.ietf.org" <6man-ads@ietf.org>,
 IETF IPv6 Mailing List <ipv6@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BIPv6=5DRe=3A_=5BSnac=5D_Re=3A_I-D_Action=3A_draft-ietf-6man-rfc?=
	=?utf-8?q?6724-update-21=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipv6/ORsNgiBbKlPH0C4LnyROiJAuQps>

--b356eb03ef5348dc932364c4849f86a2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

LGTM. Thanks, Nick!

On Fri, Jul 4, 2025, at 6:06 PM, Nick Buraglio wrote:
> Before I submit a new draft, can folks take a look at the diff to conf=
irm that these are what we want? The changes are in section 3.3 and addr=
ess:
>=20
> Erroneous re-import of rule 6 (now removed)=20
> SNAC generated GUA changed to ULA in rule 5 per Ted.=20
>=20
> https://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull/52=
/files
>=20
> On Wed, Jul 2, 2025 at 2:41=E2=80=AFPM Ted Lemon <mellon@fugue.com> wr=
ote:
>> __
>> A network can have more than one non-SNAC subnet. On such a network, =
if a device on an infrastructure link adjacent to the SNAC link treats t=
he SNAC-advertised ULA prefix as known-local, it might attempt to use it=
 as a source address when communicating with a device on a non-SNAC-adja=
cent link. This would fail because the SNAC ULA prefix can=E2=80=99t be =
routed. Hence the prohibition on using SNAC router RAs when identifying =
ULAs as known local.=20
>>=20
>> Regarding ULAs and PD on the local link, it is expected that CE route=
rs will generate a ULA prefix, and that they will delegate /64s from it.=
 These /can/ and /should/ be treated as known-local. But since  /64s fro=
m this prefix will be advertised on non-SNAC links in the home network, =
the ULA /64 prefix allocated to the SNAC router should also be treated a=
s known-local, even if the SNAC router=E2=80=99s RA is ignored for the p=
urposes of deciding which ULA prefixes are known-local.
>>=20
>> On Wed, Jul 2, 2025, at 8:53 PM, Michael Richardson wrote:
>>>=20
>>> Ted Lemon <mellon@fugue.com> wrote:
>>>     > The fix is to just change SNAC-generated GUAs to SNAC-generate=
d ULAs.
>>>=20
>>> Glad to know I didn't get something wrong here.
>>> I was like... wait... did I mis-understand SNAC in some fundamental =
way?
>>> Yes, change it to "SNAC-generated ULAs"
>>>=20
>>> But, I'm still surprised any text needs to mention SNAC and the S-bi=
t.
>>>=20
>>>     > That said, it's also true that if a SNAC router gets a ULA fro=
m a DHCP
>>>     > prefix delegation, that _is_ provided by infrastructure, and _=
could_ be
>>>     > treated as known-local. Hopefully infrastructure is advertisin=
g a
>>>     > prefix in infrastructure-provided RAs that covers the delegate=
d /64. I
>>>     > don't think we can really solve this problem in some other way=
, but in
>>>     > practice I think it's unlikely to be a problem.
>>>=20
>>> A home router could generate a RIO for the entire (GUA) prefix deleg=
ated by
>>> the ISP.   I've never seen that done.  More and more pubs in Ottawa =
seem to
>>> have v6 with PD.  They likely don't have a stub network (yet).
>>>=20
>>> I think that source address selection works fine when going to a GUA=
 prefix
>>> not on the infrastructure link.   The rules pick the GUA, and assumi=
ng the
>>> home router is doing the right hair-pin routing to get packets there=
, there
>>> should be no issue.
>>>=20
>>> Now, you actually wrote, above, that the SNAC router gets a **ULA** =
from DHCPv6.
>>> This would be in the ULA that the home router has randomly allocated=
 to be
>>> local. (as per 7804, etc.)
>>>=20
>>> But, then you wrote "delegated /64", and I was confused, because the=
 ISP
>>> didn't delegate a ULA, but you mean the /64 that the home router del=
egated to
>>> the SNAC Stub Router.
>>>=20
>>> My understanding is that the overall effect of all this work is that=
 we'll
>>> mark the entire /48 as local and higher priority than NAT44, so ever=
ything
>>> should just work even if there were v4-addresses for the STUB networ=
k, which
>>> there ought not to be.  Again, I'm not sure why we had to exclude S-=
bit RAs.
>>> If a host (ignorant of these changes) picks its GUA to talk to the S=
NAC
>>> delegated ULA, then that also ought to work.
>>>=20
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca <mailto:mcr%2BIETF@sandelm=
an.ca>>   . o O ( IPv6 I=C3=B8T consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>=20
>>>=20
>>> *Attachments:*
>>>  =E2=80=A2 signature.asc
>>=20

--b356eb03ef5348dc932364c4849f86a2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>LGTM. Thanks=
, Nick!</div><div><br></div><div>On Fri, Jul 4, 2025, at 6:06 PM, Nick B=
uraglio wrote:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div =
dir=3D"ltr"><div>Before I submit a new draft, can folks&nbsp;take a look=
 at the diff to confirm that these are what we want? The changes are in =
section 3.3 and address:</div><div><br></div><div>Erroneous&nbsp;re-impo=
rt of rule 6 (now removed)&nbsp;</div><div><div>SNAC generated GUA chang=
ed to ULA in rule 5 per Ted.&nbsp;</div><div><br></div><div><a href=3D"h=
ttps://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull/52/fi=
les">https://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull=
/52/files</a></div></div></div><div><br></div><div class=3D"qt-gmail_quo=
te qt-gmail_quote_container"><div dir=3D"ltr" class=3D"qt-gmail_attr">On=
 Wed, Jul 2, 2025 at 2:41=E2=80=AFPM Ted Lemon &lt;<a href=3D"mailto:mel=
lon@fugue.com">mellon@fugue.com</a>&gt; wrote:</div><blockquote class=3D=
"qt-gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:=
0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><u></u><br></di=
v><div><div>A network can have more than one non-SNAC subnet. On such a =
network, if a device on an infrastructure link adjacent to the SNAC link=
 treats the SNAC-advertised ULA prefix as known-local, it might attempt =
to use it as a source address when communicating with a device on a non-=
SNAC-adjacent link. This would fail because the SNAC ULA prefix can=E2=80=
=99t be routed. Hence the prohibition on using SNAC router RAs when iden=
tifying ULAs as known local.&nbsp;</div><div><br></div><div>Regarding UL=
As and PD on the local link, it is expected that CE routers will generat=
e a ULA prefix, and that they will delegate /64s from it. These /can/ an=
d /should/ be treated as known-local. But since&nbsp; /64s from this pre=
fix will be advertised on non-SNAC links in the home network, the ULA /6=
4 prefix allocated to the SNAC router should also be treated as known-lo=
cal, even if the SNAC router=E2=80=99s RA is ignored for the purposes of=
 deciding which ULA prefixes are known-local.</div><div><br></div><div>O=
n Wed, Jul 2, 2025, at 8:53 PM, Michael Richardson wrote:</div><blockquo=
te type=3D"cite" id=3D"qt-m_-2971805652583346495qt"><div><br></div><div>=
Ted Lemon &lt;<a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mell=
on@fugue.com</a>&gt; wrote:</div><div>&nbsp;&nbsp;&nbsp; &gt; The fix is=
 to just change SNAC-generated GUAs to SNAC-generated ULAs.</div><div><b=
r></div><div>Glad to know I didn't get something wrong here.</div><div>I=
 was like... wait... did I mis-understand SNAC in some fundamental way?<=
/div><div>Yes, change it to "SNAC-generated ULAs"</div><div><br></div><d=
iv>But, I'm still surprised any text needs to mention SNAC and the S-bit=
.</div><div><br></div><div>&nbsp;&nbsp;&nbsp; &gt; That said, it's also =
true that if a SNAC router gets a ULA from a DHCP</div><div>&nbsp;&nbsp;=
&nbsp; &gt; prefix delegation, that _is_ provided by infrastructure, and=
 _could_ be</div><div>&nbsp;&nbsp;&nbsp; &gt; treated as known-local. Ho=
pefully infrastructure is advertising a</div><div>&nbsp;&nbsp;&nbsp; &gt=
; prefix in infrastructure-provided RAs that covers the delegated /64. I=
</div><div>&nbsp;&nbsp;&nbsp; &gt; don't think we can really solve this =
problem in some other way, but in</div><div>&nbsp;&nbsp;&nbsp; &gt; prac=
tice I think it's unlikely to be a problem.</div><div><br></div><div>A h=
ome router could generate a RIO for the entire (GUA) prefix delegated by=
</div><div>the ISP.&nbsp;&nbsp; I've never seen that done.&nbsp; More an=
d more pubs in Ottawa seem to</div><div>have v6 with PD.&nbsp; They like=
ly don't have a stub network (yet).</div><div><br></div><div>I think tha=
t source address selection works fine when going to a GUA prefix</div><d=
iv>not on the infrastructure link.&nbsp;&nbsp; The rules pick the GUA, a=
nd assuming the</div><div>home router is doing the right hair-pin routin=
g to get packets there, there</div><div>should be no issue.</div><div><b=
r></div><div>Now, you actually wrote, above, that the SNAC router gets a=
 **ULA** from DHCPv6.</div><div>This would be in the ULA that the home r=
outer has randomly allocated to be</div><div>local. (as per 7804, etc.)<=
/div><div><br></div><div>But, then you wrote "delegated /64", and I was =
confused, because the ISP</div><div>didn't delegate a ULA, but you mean =
the /64 that the home router delegated to</div><div>the SNAC Stub Router=
.</div><div><br></div><div>My understanding is that the overall effect o=
f all this work is that we'll</div><div>mark the entire /48 as local and=
 higher priority than NAT44, so everything</div><div>should just work ev=
en if there were v4-addresses for the STUB network, which</div><div>ther=
e ought not to be.&nbsp; Again, I'm not sure why we had to exclude S-bit=
 RAs.</div><div>If a host (ignorant of these changes) picks its GUA to t=
alk to the SNAC</div><div>delegated ULA, then that also ought to work.</=
div><div><br></div><div>--</div><div>Michael Richardson &lt;<a href=3D"m=
ailto:mcr%2BIETF@sandelman.ca" target=3D"_blank">mcr+IETF@sandelman.ca</=
a>&gt;&nbsp;&nbsp; . o O ( IPv6 I=C3=B8T consulting )</div><div>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sandelman Software =
Works Inc, Ottawa and Worldwide</div><div><br></div><div><br></div><div>=
<b>Attachments:</b></div><ul><li>signature.asc</li></ul></blockquote><di=
v><br></div></div></blockquote></div></blockquote><div><br></div></body>=
</html>
--b356eb03ef5348dc932364c4849f86a2--