# SNAC 118 Meeting   {#snac-118-meeting}

Document editiong session based issues created for "Automatically
Connecting Stub Networks to Unmanaged Infrastructure"  
 I.D: https://datatracker.ietf.org/doc/draft-ietf-snac-simple/  
 issues: https://github.com/ietf-wg-snac/draft-ietf-snac-simple  
 collaborative workspace: https://notes.ietf.org/R-tkJFdYSCCWqeBDXMReLQ

*Post meeting key take aways*: (1) The document clearly needs to reflect
all scenarios of prefix advertisements on both stub networks and AIL.
The prefix on stub and AIL can potentially be same or different. It also
includes specifying behavior with GUA, ULA and prefix lengths. (2)
Construction of RAs and their behavior will lead to writing down new
text in the document. (3) demand for inter-op and implementation from
the spec.

# Discussion on Issues   {#discussion-on-issues}

## 1. Add a state machine for NAT64 #25   {#1-add-a-state-machine-for-nat64-25}

## 2. Some points to address from Darren Dukes’ review #29   {#2-some-points-to-address-from-darren-dukes-review-29}

section 5.2.1 discusses stub router restarts. I assume the two stub
routers are connected to the same AIL and to the same stub network. I
also assume the remembered prefix time includes remembering the prefix…
The text doesn’t state this clearly.

\[Esko\] There are different combinations of options possible, such as
same stub router + same network + different AIL, different stub routers
+ same network + same AIL, etc. could multiple AIL be out of scope?  
[Ted](confirmed it is in the scope of simple document.) whether
multi-AIL case is in simple-document needs to be confirmed.  
[Ted](confirmed it is in the scope of simple document.) For single AIL,
it does not matter if 2 routers are serving the same stub network
because some stub router has to advertise ipv6 prefix on AIL. In fact it
is possible that with 2 stub networks, stub-routers will ping pong back
and forth.  
[Ted](confirmed it is in the scope of simple document.) The text should
say we have to remember the prefix and the time.  
\[Esko\] what 'time' is it?  
[Ted](confirmed it is in the scope of simple document.) Additional
editorial comments at the end of the section. In Thread implementation
generated prefix are same across all stub routers for a particular stub
network (... which does not prevent us from having 2 stub networks and
still having the problem).

[Ted](confirmed it is in the scope of simple document.) Whenever
possible we probably try to have all the stub routers use the same
prefix. E.g. Thread uses a constant (XPANID) that's part of the thread
network. For wifi SSID is an option to be used as prefix. One approach
we could use would be to, to just say use an identifier for the stub
network. and leave it unspecified.

\[Juliusz\] We cannot assume that the SSID is unique for a stub network.
putting the same SSID on multiple.   
\[Eric\] Why not use BSSID or MAC for uniqueness?  
\[MCR\] could confuse users.  
\[Judith Kravachak\], MCR is probably right. But this can happen when
same prefixes are randomly assigned in different subnets.  
\[MCR\] There are no cases that it's gonna break that they're not
already broken.  
\[Lorenzo\] on "the host will prefer the prefix that was most recently
announced" - we should not rely on this scheme.

\[Jen\] In my network, I have a case of same SSID for different subnets,
But from my experience, if hosts support rule 5.5 of default address
selection (see: https://www.rfc-editor.org/rfc/rfc6724#section-5), : if
your local address is different then it works; If same link local
address: will have a problem. So the combination of unique link local ID
+ 5.5 support on the host solve all those like broken things, which are
broken.   
\[Lorenzo\] I guess what Jen was saying that you can make this work,
but, when you come back and lose state and reboot, you might wanna pick
a new link local address.  
[Ted](confirmed it is in the scope of simple document.) Please propose
text for this.   
note-taker: Inline editing around line 789...

\[Discussion\] on whether it conforms to the RFC 4193. Since each stub
network  
advertises its own prefix, it doesnt (wont pick same ULA in a site).

## 3. Add restriction that usable prefix must be /64; reference RFC 7084 section 4.3 requirement L-2 #30   {#3-add-restriction-that-usable-prefix-must-be-64-reference-rfc-7084-section-43-requirement-l-2-30}

Section 5.2.3

\[Esko\] This restriction should be relaxed both on infrastructure and
stub network side, but it contradicts whatever we have been typing so
far. clarify what does a usable prefix mean. Will anything other than
/64 be usable prefix? Some reference will be useful.  
note-taker: Inline editing around line 506...

\[Lorenzo\] Saying something that's outside the current specification is
not usable. Seems like a resonable thing to say.   
\[Jen\] We can find tech somewhere that says Slaac only works for /64.  
this might be enough.  
[Ted](confirmed it is in the scope of simple document.) has updated
section 5.1.1 (look for reference RFC 7421 in this section)

\[Juliusz\] Like to see a wholesale replacement of usable with  
something that is a little bit less biased. (room suggested: suitable). 

\[Darren\] define usable prefix what intention is? TBD. Eric - define it
in terminology.

## 4. Relax the requirement on a single ‘root’ ULA prefix generated by stub router #31   {#4-relax-the-requirement-on-a-single-root-ula-prefix-generated-by-stub-router-31}

Section 5.2.2

\[Esko\]: We know that prefixes on stub and AIL can be different. So we
should change 'same prefix' text.  
\[Jonathan\] could remove entirely.  
[Ted](confirmed it is in the scope of simple document.) reason for text
is for stub routers to have to allocate a prefix they can advertise on
the stub network. This text is needed so that if stub network
partitions, both networks sould have different prefixes.  
\[Esko\] we are stretching the concept of site as defined in 4193.
(could say u are not doing ULA procedure properly).  
[Ted](confirmed it is in the scope of simple document.) this is ok -
since te spec doesnt define what a site is.  
\[Mcr\] each stub router with different prefixes will have multiple
upstreams, multiple default routes.  
[Ted](confirmed it is in the scope of simple document.) but only one
gets advertised even after unpartitioned.  
\[Eric\] add explanation on partitioned/unpartitioned.

\[Éric Vyncke\] editorial: don’t forget to shoulder every SHOULD with a
“unless” clause. imho, the text about (un)partitioning would benefit of
having its own sub-section

\[Tim Chown\] Does the last sentence of 522 mean that as a sub router
moves between different networks, it's gonna renumber the devices that
are attached through it. (dont achieve the stability provided by ULAs). 

\[Esko\] last sentence is dangling.   
\[Lorenzo\] do we say which stub router prefix is chosen by AIL.   
[Ted](confirmed it is in the scope of simple document.) we say
numerically lowest.  
\[Lorenzo\] what happens with global prefix is renumbered? (separate
text to split for stub and AIL part)  
[Ted](confirmed it is in the scope of simple document.) we assume 7084
is followed and stable ULA is provided on LAN side. (Q. from Esko on
/48) When I say the ULA prefix, I mean, the the /48. You can then
generate prefixes from the /48. Maybe use ULA site prefix and ULA stub
network prefix to differentiate.  
\[Jonathan\] We need to make 2 usecases clear seperately  
note-taker: (The one where only one /48 ULA is generated by stub router
and second where AIL and stub routers can have different ULAs)  
note-taker: Inline editing around line 789...  
\[Tim Chown\] in the infrastructure if only GUAs are used and stub
network apprears will it generate ULAs? ULA to gUA is proabably
misconfiguration?  
[Ted](confirmed it is in the scope of simple document.) home router if
there is GUA, ULA should exist (7084 conformance) else ULA will talk to
GUA (it will not cause operational problem).

## 5. \[x\] Should a stub router learn RA header parameters from other routers? #32   {#5-x-should-a-stub-router-learn-ra-header-parameters-from-other-routers-32}

Section 5.1.2.4  
\[Lorenzo\] per RFC 4861 the host believes the most recently observed
flag - linux is known to comply.  
\[Esko\] make explicit that dont take stub router RA as source of truth
(they are copying).  
[Ted](confirmed it is in the scope of simple document.) - three cases -
no advertisements on link(except for stub), one advertisment on link,
conflicting advertisement on link  
[Ted](confirmed it is in the scope of simple document.) - New section to
describe how RA flags are used (use last that was observed) and how
they’re constructed (on stub and not)  
\[ACTION\] - Ted or Jonathan to write the section text post-meeting -
consider writing a state machine if clear

## 6. Clarify text “as needed” #33   {#6-clarify-text-as-needed-33}

Section 5.2.2  
[Ted](confirmed it is in the scope of simple document.) This needs to be
addressed as part of point 5.  
\[Esko\] ad a forward pointer to discussion on what happens when
allocate prefix on AIL etc.Helpful, if others can add text with name.

## 7. Add requirements for not advertising default router/route on AIL #34   {#7-add-requirements-for-not-advertising-default-routerroute-on-ail-34}

[Ted](confirmed it is in the scope of simple document.) This needs to be
addressed as part of point 5. Goes into the details of RA.

## 8. Clarify SNAC solution assumes the IPv6 host on AIL is a Type C Host #35   {#8-clarify-snac-solution-assumes-the-ipv6-host-on-ail-is-a-type-c-host-35}

Section 5.3??  
\[Darren\] sounded like conclusion was Type C works, A and B may not
work in all cases and this is OK.  
\[Juliusz\] failure mode is acceptable.  
\[Jonathan\] clarify in section 5.3 that stub router should not
advertise default route.  
\[Lorenzo\] Talk about the RA Guard, wont work without
prefix-delegation.

## 9. Make all contents of RA sent by stub router explicit, and with rationale #36   {#9-make-all-contents-of-ra-sent-by-stub-router-explicit-and-with-rationale-36}

\[Darren\] sounded like this requires the same update in RA section as
per item 8

## 10. More details on DHCPv6-PD prefix renew/rebind conditions + AIL change situations #37   {#10-more-details-on-dhcpv6-pd-prefix-renewrebind-conditions--ail-change-situations-37}

Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub
router.  
However, there are no details here what should trigger the stub router
to  
renew/rebind the prefix lease.

[Ted](confirmed it is in the scope of simple document.) These
clarifications should be brought to the DHC working group. Out of scope
for stub network doc.  
\[Darren\] Jen noted RFC8415bis last call closes soon, Esko will
initiate a thread on this.  
\[Lorenzo\] P flag draft in 6man wont work here since stub router will
unconditionally ask for PD.

## 11. Review if any of the draft-ietf-v6ops-dhcp-pd-per-device-04 are useful /   {#11-review-if-any-of-the-draft-ietf-v6ops-dhcp-pd-per-device-04-are-useful-}

\[Darren\] when prefixes change for any reason we need to support that -
short lifetimes initially  
\[Lorenzo/Esko\] Mention PD release in the doc.

applicable to stub router #3