Tuesday 19th March 2024, 13:45-15:00 AEST
Chairs: Darren Dukes, Kiran Makhijani
Note taker: Stuart Cheshire
There have been two interim meetings since IETF 118.
Further interim meetings will be scheduled.
Goal is to have draft-ietf-snac-simple to be ready for Working Group
Last Call before IETF 120.
Does this belong in 6MAN or SNAC?
Jen Linkova (Google, 6MAN chair): This is on the agenda for 6MAN. There
is some discussion about changing the format of how it is represented.
Éric Vyncke (Cisco/INT AD): Suggests that Jonathan update the document
to make this small change, rename the document as draft-hui-6man-xxx and
then 6MAN can do the call for adoption.
Lorenzo Colitti (Google): If would be helpful if the document gave a
brief summary of what a stub network router is, without the reader
having to read all the SNAC documents.
Ted Lemon (Apple): Duplicating information in two different documents
risks the text being inconsistent.
Stuart Cheshire (Apple): Would it be better to combine these two
documents?
Lorenzo Colitti (Google): We could have a single document in SNAC and
have 6MAN review it.
Jen Linkova (Google, 6MAN chair): For 6MAN we should have a short
document summarizing what other implementers need to know, e.g., simply
say that hosts should ignore this bit.
Robert Hinden (Check Point Software, 6MAN chair): I am okay with having
two documents, that have normative references to each other.
Suresh Krishnan (Cisco): I would prefer a single document, in SNAC,
reviewed by 6MAN.
Lorenzo Colitti (Google): 6MAN should review all of this.
Éric Vyncke: We should not overthink the process.
Stuart Cheshire (Apple): Listening to the discussion, I think I agree
that maybe we do need a short document saying that end hosts and similar
devices should ignore this bit.
Ted Lemon (Apple): If we have a second document, it should be very
brief. We’re spending a lot of time talking about how to allocate a
single bit, that almost all devices should ignore.
Lorenzo Colitti (Google): There should be one draft, in SNAC, and 6MAN
should review it.
Mark Smith (APNIC Foundation): Are IPv6 RAs for communicating from
routers to hosts, or are they for inter-router communication? This would
be the first time RAs have been used for inter-router communication.
Timothy Winters (QA Cafe): Having two documents is fine. You definitely
need to specify how to ignore the bit. Otherwise devices will do the
wrong thing.
Kiran Makhijani (SNAC chair): We need an answer for this soon, to get
the IANA allocation done. We also need to start on
stub-router-advanced-scenarios.
Ted Lemon (Apple): I do not have the time to take on another document
until snac-simple is finished.
Lorenzo Colitti (Google): What do we expect to achieve in
stub-router-advanced-scenarios? Why not just use DHCPv6 PD?
Ted Lemon: The current document already requires DHCPv6 PD. The key
feature of stub-router-advanced-scenarios is multi-link service
advertising and discovery. The IETF already tried HOMENET and it was too
ambitious and it failed. We should be more conservative this time.
Éric Vyncke (Cisco/INT AD): The SNAC WG started with the simple case,
with an option in the charter to extend it to something more
complicated. Personally I would prefer to stick to the simple case and
avoid repeating the not-so-successful HOMENET work.
Lorenzo Colitti: If we decide that all we need to do here is multi-link
service advertising and discovery, doesn’t that belong in DNSSD?
Ted Lemon: Maybe SNAC might succeed in doing what HOMENET set out to
accomplish.
Kiran Makhijani (SNAC chair): We will consider whether we need
stub-router-advanced-scenarios.
Ted Lemon: The term “stub router” has two meanings: an unmanged
(self-configuring) router, or a router that connects to a leaf network,
or both. This is confusing. Do we need new terms?
Lorenzo Colitti: Can an infrastructure router also be a “stub router”?
Is it permissible for an infrastructure router to also act as a stub
router and advertise a self-allocated IPv6 ULA to facilitate IPv6
communication on the local network. It makes more sense to have this be
a centralized function on the customer’s existing infrastructure
equipment.
Suresh Krishnan (Cisco): This stub router RA flag is just like the
opposite of the neighbor advertisment override bit.
Priyanka Sinha: Can a stub network have multiple hops, like a MANET
(mobile ad hoc network)?
Ted Lemon: A stub network is always one logical “hop”.
Stuart Cheshire: Except a multi-hop Thread mesh is exactly like a
MANET, especially when some of the Thread nodes are mobile and move
around.
Lorenzo Colitti: So a stub router is the RA provider of last resort.
Ted Lemon: We don’t want inconsistent M and O bits on a single link.
Stub routers should learn the correct M and O settings from
infrastructure routers, if present.
Erik Kline (Aalyria): Isn’t this what PVD options are for? You’re
creating a private domain only to be used by devices that understand the
PVD option.
Ted Lemon: No. The point here is to create working IPv6 connectivity for
all IPv6-capable devices. It is not a private network restricted to
special new devices.
Suresh Krishnan (Cisco): If there are inconsistent M and O bits on a
single link then that’s a configuration error and the network
administrator should fix it. Existing hosts will not pay attention to
the S bit.
Ted Lemon: A network can have a mix of RAs from infrastructure routers
and from stub routers.
Suresh Krishnan: Hosts should ignore any information in RAs from stub
routers.
Ted Lemon: No, hosts should treat RAs from stub routers the same as any
others. That's why they are sent — to configure hosts on the network.
Lorenzo Colitti: We should say that hosts MUST ignore the M and O bits
in RAs from stub routers.
Ted Lemon: What if there are no other RAs on the network?
Lorenzo Colitti: Then hosts should act as if the M and O bits are both
zero.
Mark Smith (APNIC Foundation): Stub routers are like edge routers. They
can do whatever they want on the downstream side.
Stuart Cheshire (Apple): I think some people here don’t know all the
background.
This is not a hypothetical thing. This is not new. Stub routers (Thread
Border Routers) have been shipping since 2020. Now, in 2024, it is
increasingly common for customers to have multiple stub routers on their
home network, and this work is aimed as improving how that works.
Thread is used for home automation. Unlike Zigbee or Z-Wave, Thread
communicates using IPv6. We want to enable device-to-device IPv6
communication, from an existing IPv6 host to a Thread device, and vice
versa. A Thread Border Router is an IPv6 router. It’s not a NAT, and
it’s not an appliation-layer gateway. It’s a bidirectional IPv6 router.
It makes use of IPv6 RA, PIO (prefix information option), RIO (route
information option), etc. It has to work in the case where the existing
home network has no IPv6, and it has to work in the case when the home
network does already have IPv6, and it has to handle transitions between
those two states. HomeKit and Matter are two IP-based application layers
that work over Thread networks.
We cannot require replacing existing infrastructure equipment. The whole
point of this is to work on existing networks. Customers want to buy a
Thread Border Router and have it work, not be told they need to replace
their home network with a new one.
We’re not talking here about what Thread Border Routers do on their
“downstream” interface (the Thread mesh). We’re talking here about what
Thread Border Routers do on their “upstream” interface (the home
Ethernet or Wi-Fi network, where they may already be other IPv6 RAs from
the existing home gateway).
We cannot assume there is a network administrator to fix problems. A
self-configuring unmanaged stub router has to do the right thing even in
the absence of a network administrator.
Within a single link, no IPv6 ULA is needed, since IPv6 link-local is
sufficient.
Éric Vyncke (Cisco/INT AD): Looking at RFC 4861, maybe it doesn’t matter
much if the M and O bits are inconsistent.
Ted Lemon: Yes, hosts have to deal with that anyway.
Ted Lemon: I think we have decided we should have two documents. I’m
going to update the slides based on what Stuart just said, and I think
we should still present this in 6MAN.
Darren Dukes (SNAC chair): This has been a valuable discussion. We had
intended to spend some time doing live editing. We have 12 minutes left.
What should we tackle in the time remaining?
Ted Lemon: I have updated two of the issues.
Ted Lemon: I worked on the taxonomy issue. Someone was concerned
that SNAC routers might be harmful to some networks. After consideration
we determined that there are no problems. We made a list of scenarios,
and they all work correctly. If someone disagrees, they need to explain
why.
On unmanaged home networks, SNAC routers work, which is as designed. On
managed corporate networks with RA guard, SNAC routers do not work (as
the corporate administrator desires) and they do no harm.
Timothy Winters (QA Cafe): In the update to RFC 7084 someone is
proposing requiring RA guard on all home networks by default.
Ted Lemon: That would be a serious mistake because it would stop stub
routers from working. RA guard is something that should only be enabled
if the user chooses to do that and understands what it will break.
Timothy Winters: I will add text that says that.
Éric Vyncke (Cisco/INT AD): Cisco implements RA guard but does not have
it enabled by default, for this reason.
Lorenzo Colitti: If RA guard is turned on but not working properly then
RAs may leak through anyway.
Ted Lemon: It seems like that’s not our fault.
Ted Lemon: If a corporate network is using RA guard correctly and has
DHCPv6 PD working correctly and routed correctly, then SNAC routers will
work correctly and don’t need to advertise using RA.
Jen Linkova (Google): ULA prefixes advertised from SNAC routers will not
work as a CLAT address for clients that want to communiate globally.
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/25
Pretty involved. To be updated by the authors. But one way to resolve in
the scope is to identify how much of the SM is in scope for 'simple'. if
it is part of simple or next iteration of the document.
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/33
5.2.2 has currently:
A stub router MUST allocate a single ULA prefix for use in providing
on-link prefixes to the stub network and the infrastructure network,
as needed.
The "as needed" part here is not so clear and needs to be detailed. E.g.
This can be resolved easily by a pointer to other parts of the draft ("as defined in Section N"). Because there are still some pending PRs that impact the text here and add the details, this issue can be postponed until after these PRs are merged
Based on email
discussion: https://mailarchive.ietf.org/arch/msg/snac/cST1bdMJ7g52nnws0Si71jAF7io/
(lower part)
It's proposed to make all the elements of the stub router RA explicit,
including rationale for the settings.
This would also include the M / O flag settings of #32
(self-assigned by Darren.)
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/37
And what about the SHOULD requirement that involves "if the client
detects a significant change regarding the prefixes available on the
link (when new prefixes are added or existing prefixes are
deprecated), as this may indicate a configuration change.
For this issue, we could reference the improved text
in https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-04#name-refreshing-configuration-in instead
of RFC 8415.
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/38
See
draft: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device-04
which just passed WGLC today.
This has some potentially useful considerations and requirements related
to the SNAC stub router. In particular,
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/42
the text in this section can be confusing when dealing with 2 usable
prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there
are two suitable prefixes, one of them will still need to be deprecated.
According to Ted, this issue is orthogonal to reachability. Perhaps, we
should explain that this state-machine does not talk about reachability
for both the suitable prefixes. At least give forward reference to
section 5.4 for complete behavior.
This will explain that we can only transition to STATE-BEGIN-ADVERTIZING
and in no case we transition to STATE_USABLE.
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/47
(https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/48)
(https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/49)
(https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/50)
https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/52
Having a better overview of success/fail cases also helps reviewers
of the document to judge the risk.
FYI here's a pointer to one of the messages in the thread of 2023
that summarizes some cases and how it could be
documented: https://mailarchive.ietf.org/arch/msg/snac/q5hZdvzX_s4iCjoKjgg2B0eD8MQ/