SNAC @ IETF123

When: Friday 25 July 2025, 09:30-11:30, Madrid
Where: Patio 3,
https://meetings.conf.meetecho.com/ietf123/?session=34285
Chairs: Darren Dukes & David Lou
Note taker: David Lamparter

Administrative & Agenda Bashing (5min, Chairs)

• A reordering of items (Interim Scheduling before possibly long
  discussion on connecting) was agreed upon

Providing DNSSD Service on Infrastructure （15min, Mathieu Kardous）

09:33 → 09:51

Éric Vyncke: interesting, missing more on how to do it?

Ted Lemon: I can answer these questions. Just submitted -00 draft that
describes this; but haven't done RA option yet. RA option does more than
DNS-SD though. Advertising proxy document talked about it, but it was
removed because was already complicated. This should cover most stuff
that will be in snac-simple. It's here because it's relevant to snac but
may progress in dnssd. 6man will need to review RA option, but that
should be simple part.

Jen Linkova: bit of a problem with everything requiring a bit in IPv6
coming to 6man. Happy to review in 6man but don't need separate doc,
happy to talk about bits & hand out bits, don't need to own doc.

Esko Dijk: DNS-SD bits in DNS-SD working group // using RA to advertise
presence, right? Also lifetime isn't clear yet, & how specifically this
will be announced.

Mathieu Kardous: bit just declares difference between infrastructure and
non-infrastructure devices. Giving priority to infrastructure routers.

Esko Dijk: don't have the RA lifetime because SNAC router doesn't
advertise a default route, need to be clear. Reasons on doing it in mDNS
vs. RA?

Mathieu Kardous: RA is better for constrained devices since they receive
the RA anyway.

François Michel: if the service registry is separate, that's a new
single point of failure? If mDNS isn't there anymore… looking at SRP
registration draft.

Mathieu Kardous: still falling back to mDNS for discovery and looking at
RA for steady state operation. (?)

Ted Lemon: was just looking at this. Noticed missing things: there may
be more than 1 infrastructure router, need to pick one, but how to pick?
Doc now says register with both (if they use SRP). Not sure this is the
place to discuss this. On fallback to mDNS: in addition to RA, service
will be in mDNS. But customer of service doing discovery wants SRP to
know when to fall back on mDNS. If we find it, great, if it breaks, need
mDNS. If e.g. doing DNS push and that drops, connection will break.

Tim Winters: want this to work on CE routers and SNAC routers. 7084 CE
doc doesn't have text about DNS-SD at all. Not sure what to do about CE
routers doing it, and that draft is open in revision right now. Do we
want to include something? Is the intention to have this in regular CEs?

Ted Lemon: Right now, no plan for adding this to CE doc as requirement —
maybe we could? Might also be part of Matter router requirements (which
are more demanding) but fundamentally think the requirements should be
the same. PCP too (Tim Winters: already there). Hoping to learn from
people here actually deploying it & might need a -bis doc.

Tim Winters: inclined to add as MAY and then circle around to it later.

Ted Lemon: would really like to finish this quickly, hopefully by the
end of the year (- laughter -), feels unlikely, but either way.

Philipp Tiesel: also seeing enterprise use cases, e.g. displays in
meeting rooms offering services, but want more control in those cases.
Network exerting more control there, but valid and applicable use case.

Ted Lemon: ACK, another reason for progressing this quickly. May need
some additional rules for whole routing infrastructure. This is piece of
solution.

Philipp Tiesel: SRP in general, even non-SNAC, makes a lot of sense.

Ted Lemon: yes; infrastructure service, in enterprise setting — routers
can set the bit. Could say, if the bit is set, then whatever RDNSS says
that is also mDNS service, and things go there. — everything just works.

Philipp Tiesel: ACK

Darren Dukes: hoping for lots of discussion on the list.

Comment from Daniel Bernier after queue closed: @Ted adding Matter
integration seems a natural evolution if you look at what is happening
in BBF through TR-181 lots of enterprises (branch, etc.) are not that
different to broadband deployments.

Schedule Interims between IETF 123 and IETF 124

09:51 → 09:56

Polls:

• "late August interim": 3/1/11 Y/N/noop

Ted Lemon: European summer slot…

Darren Dukes: for September, sending out on list.

Ted Lemon: would suggest just scheduling a week in September. Would
really like buttoning this draft up. Can renegotiate anyways.

• "weekly September": 4/0/9

Will schedule something in September.

Automatically Connecting Stub Networks to Unmanaged Infrastructure

10:00 →

• ID: https://datatracker.ietf.org/doc/draft-ietf-snac-simple/
• Document update session: Discuss and resolve open issues (link
  below). Propose revised text for each issue. link:
  https://github.com/ietf-wg-snac/draft-ietf-snac-simple

Reviewing issues tracked on GitHub.

Esko Dijk: have flagged some as editorial.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/130

Esko Dijk: (summary of issue & concerns) ULA vs. GUA - stability vs.
churn.

Ted Lemon: hard question; feel like failing into direction of
functionality = GUA? More likely to produce correct behavior in more
cases. But on Thread, frequent GUA renumbering will cause a lot of
congestion… mitigations? Thread group could think about making that less
painful.

Esko Dijk: SNAC router delegate from both & SNAC devices choose? Only
problem is not putting too many prefixes into network data… some
technology specific problems. Could define some recommendation though.

Ted Lemon: can of worms with PvD; multihomed SNAC router… multiple GUAs,
hopefully not multiple ULAs (but possible); then address selection
becomes an open problem that is somewhat unsolved. Should make sure we
don't screw it up.

Tim Winters: PD on LAN RFC says GUA first before ULA, have constrained
devices take the first one. Would also recommend giving everything
multiple addresses.

Ted Lemon: incompatible address is an issue

Éric Vyncke: using preferred & valid lifetimes as input in selection?

Ted Lemon: good input — short lifetime on GUA influence away from it,
long lifetime to it? ULA, even if short lifetime, would be assumed
stable. Not a problem for wifi, but things like Thread. Not sure what
requirements to place here.

Jen Linkova: a bit scared about lifetime as differentiator. Short
lifetime might just be safety net, recovery mechanism so hosts aren't
stuck with broken addresses. Also relative to how often you get an RA.
Not sure how much information content is in the lifetime.

Éric Vyncke: would be surprised though to see very low lifetimes, e.g.
half an hour — at least a day? Otherwise poorly usable, need to reload
DHCP server and all?

Ted Lemon: flash renumbering is just bad and we can't do anything. SNAC
router could track that though. Outside of flash renumbering, could
detect renumbering and do some special process on the stub net to just
replace prefix?

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/121

Esko Dijk: some confusion with Fernando's review comment.

Ted Lemon: change text to "no local communication, only Internet"

(text discussion)

Ted Lemon: just need to be clear a SNAC router on a guest network won't
be able to integrate with other local devices.

Esko Dijk: also depends on how guest network is configured.

Ted Lemon: how much detail on this? Have no control on what'll happen,
point is more to prevent/advise people against sticking SNAC routers on
guest networks.

Éric Vyncke: have read text, seems clear to me, would ignore comment.

(meta-discussion; some comments seem to have different understanding of
what SNAC networks are)

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/116

Ted Lemon: unclear if this is even relevant. (IPv4 RAs RFC 1256)

Darren Dukes: have a PR for this.
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/131

David Lamparter: we implement this (1256, IRDP), about to remove it,
nobody uses it.

Ted Lemon: everything's DHCP. Feels like a distraction. IETF policy is
no new work on IPv4.

Darren Dukes: suggest: "lack of broadly implemented mechanism"

Ted Lemon: should check PR

Bob Hinden: isn't IPv4 out of scope for this WG?

Ted Lemon: good point. Kinda support IPv4 with NAT64.

Bob Hinden: you can just ignore IPv4, enough stuff to do in IPv6.

Ted Lemon: need to keep practical considerations in mind to make things
actually work, though.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/136

Ted Lemon: don't agree with changes; not wrong but implementor who reads
this won't know what it means/the number is. Feels "more correct" but
creates actual problems for implementers, should prioritize clarity for
implementers.

Esko Dijk: /64 is the case everywhere & hardcoded in places. Would still
imply it's in fact required to be /64.

Ted Lemon: need to tweak, right suggestion, but… text like "for most
cases will be /64"

Tim Winters: have text in some of my RFCs/drafts, says "as supported,
normally /64" (notetaking constrained, please look up actual text)

Darren Dukes & Ted Lemon: can you drop a reference in the PR?

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/105

Ted Lemon: discussion in 6man, is 30min the right number? Heard 45
maybe? OK with just leaving it but might get pushback. Approve edit?

Stuart Cheshire: not a fan of changing explicit text to some symbol you
need to find in the text. Works in code, but this is a standard, it's
not like we need to change the constant? Why would we make it easy to
change it.

Ted Lemon: rationale is to use it in more than one place, and might
change it during editing process — avoiding mistakes if that happens and
we forget to update somewhere.

Stuart Cheshire: responsibility is with the editors; clarity in reading
is more important.

Ted Lemon: agree, would be nice if there was a way to make it a manifest
constant.

Stuart Cheshire: could have something in parenthesis.

Esko Dijk: proposed PR having suggests it might be changed. Then it's
good to have this. If it'll never be changed, yes, it should be in the
text. But also feature to be able to do Ctrl+F for other uses of the
same constant, better than searching for "30" or "30 min".

Ted Lemon: not sure this makes sense, text say "or more". Compromise:
"MIN_SUITABLE_PREFIX_PREFERRED_LIFETIME (30min) or more" - add value
in parens.

Darren Dukes: two parts — what is the value? (Only place in the doc
where it's done like this.) — what if it's shorter? Request for
discussion on the 30min value as well.

Ted Lemon: would be great if it's clickable… not sure if possible.
Separate out so we can have links?

…

Ted Lemon: open new issue for reference link on all constants.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/138

Ted Lemon: SNAC router must really handle this, sourcedest routing can
otherwise break this, but…

Darren Dukes: will look at this PR.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/134

(… general agreement/nits only …)

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/133

Ted Lemon: thought we discussed & decided we can't do anything.

David Lamparter: same problem with multihome/multiprefix/same link
scenario. Kinda unsolvable situation as soon as M bit set anywhere.

Ted Lemon: is that a suggestion to clear M bit?

David Lamparter: mhm, maybe too far.

Ted Lemon: indeed long discussion; long text; …

(…some details missed due to notetaker==commenter…)

Ted Lemon: is discussion here useful, or take offline?

Esko Dijk: what if the rule isn't present, what will happen, even if
it's not supposed to happen? Move to appendix describing problem maybe.
If the rule is applied correctly, this shouldn't happen.

Ted Lemon: need to read & check if it makes things better; inclined to
accept.

Tim Winters: think we do need to say something, keep having problems
with this flag.

Ted Lemon: somebody needs to say "this is a problem, here's what you can
do"

Tim Winters: seeing problems like routers restarting their DHCP servers.
Not saying anything will just make it worse.

Ted Lemon: taking action item & to list.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/132

Ted Lemon: probably another one to review on ML.

(agreement)

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/131

Darren Dukes: just to make statement technically correct.

—asking for disagreement from the room— ⇒ none

Ted Lemon: approving PR

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/100

Ted Lemon: talking about router advertisements like NAT64 is somehow
responsible for monitoring, but there are other users. Need an RA state
machine, and then how to integrate that into the other state machines?
Would make document clearer. Don't want 5 state machines all sending RS.
Probably no action item, but want to make WG aware.

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/96

Ted Lemon: text that was added— (…) diagram looks good, but text needs
review. Taking to ML, appreciate feedback.

Any other Business (AoB)

Darren Dukes: Tuesdays in September? For interim — midday Europe?

Ted Lemon: anybody in an Asian TZ? … everybody's kinda used to TZ
problems.