SNAC 2022-11-10, 9:30am Room Richmond 2
meetecho: https://wws.conf.meetecho.com/conference/?group=snac
Taking notes poorly: Michael Richardson
WG Chairs
ID:https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks
Presenter: Ted Lemon
Ted: The reason to include DHCPv6-PD in the document already now is to
avoid having to later modify the state machine.
MCR: if the ISP has provided an IPv6-only network, and provided NAT64 in
their network, then we would fail if we didn't have DHCPv6 PD.
Ted: agree, didn't consider this case yet.
Eric Vyncke: Michael stole my words about DHCPv6, and he was concerned
with the complexity of NAT64, but the use case convinced him.
Tim Winters: want to turn on southbound PD. (ACTION) maybe this is in
v6ops?
Please talk more about reachability issues. Will send notes.(ACTION)
Bob Hinden: if there is NAT64 at the ISP, then whatever this is
defining, shouldn't have to do anything.
-> Ted, when we wrote the Thread spec, did not want to break DNSSEC, so
the host has to do the DNS64 synthesis... but we might want to do RAs,
but Thread carries this internally.
Bob: not to have to do anything. Try to have as little as possible in
the document. (Not grow it too complex)
Ted: the reason we are doing this is so that we can have an autonomous
router, no manual setup.
Lorenzo Colitti: should have DHCPv6-PD in the base spec. Maybe we should
split up the document into one routing/reachability doc, vs another
discoverability doc.
Stuart Cheshire: everyone else said the same thing, want to talk about
state machine, and how it goes away... had a discussion with Erik Kline,
and he got a different impression of this work... and that we were
building an overlay network to connect stubs... but that's the point, we
want hosts to communicate. Our goal is not to build a private overlay,
but to get "public" connectivity... Thread would like a unique IPv6 that
it can use for connectivity. Focus on ideal case, and then talk about
compenstations.
Ted: CLEAR consensus that we have DHCPv6-PD in the document.
Juliusz: there are other possibilities, such as IPv4 in IPv6, but that
requires a full IPv4 stack in the stub network. If all we need is HTTP
access, wouldn't it be enough to have a SOCKSv5 proxy on the stub
router?
Ted: very heavy to do SOCKS.... you may as well put a full IP router
there.
J: Could we split the document?
Ted: but this results in more text that is more confusing.
Esko Dijk: maybe to have IPv4 also on the stub network nodes is not
realistic... 6LoWPAN networks could be stub networks. Thread is one
example 6LoWPAN network where it is not feasible. Sometimes see a
separate problem statement document in a WG, and maybe we should have
that?
Ted: we did write a Problem Statement (PS) document, it just expired,
but we could do one. The text got pulled out and placed into the
solution document.
Marc Blanchet(MB): the PS document was "comprehensive", so was dropped.
Better to have a short statement in the document.
https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
ID:
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-prefix-registration
Presenter: Pascal Thubert
Pascal: not a SNAC-specific presentation, but presented to 6lo WG. May
contain useful tools to fill the SNAC toolbox, to consider as a
solution.
"Autoconf" concept can maybe be applied also to IPv6 prefixes, not just
for address conf.
Ted: some useful things in here, thanks. Better not use another protocol
than DHCPv6-PD for prefix delegation, we already have that protocol.
Some parts may need to be done in other WG(s).
Lorenzo: if you want to do EARO for energy savings, that's a good way...
but if the node is sleepy, then you can't change anything on the
network, then you can't talk to them to tell them to change.
Pascal: when they sleep they don't need to know that the prefix has
changed. when node waked up it gets a PIO, and then it finds out that
the network has changed.
Lorenzo: good for managed network where the network does not change
prefixes.
Pascal: maybe we can reduce the amount of multicast so that sleepy
devices can listen to what's left?
Lorenzo: no, even listening to the beacon is expensive.
UNSURE: if one has legacy hosts, then avoiding the hairpin is better,
and just send the RA.
Michael Richardson: (refers to IETF 113 presentation on energy networks)
multiple layers of NAT44 hosts was presented there as security feature,
but was bad architecture. Energy network operators generally don't want
any new stuff on it nor touch it.
But, SNAC could provide for something equivalent to the NAT44 stuff, but
allow for connectivity. The EARO work can then be used when that same
vendor provides a second installation, which needs to talk to the first.
Thread mesh network are not going to change because of what we in IETF
would define; we're about 10 years late here.
Ted Lemon: some of these concepts worth to be talking about in Thread.
Eric: I would prefer to have one line to add DHCPv6-PD to be supported,
and then the document should be adopted.
Lorenzo: do we have to do that? There seems to be solid support in the
room to support DHCPv6-PD.
Eric admits to being a process freak, and that one line.
Lorenzo: but don't want PD in a different document.
BobHinden: adoption usually means that the WG wants to work on it, but
not final agreement about what is in it. Not sure why we need another
step here.
Ted (later in the WG meeting): revised I-D published with DHCP-PD
MB: There is another deliverable. The complex case.
Ted: Where there is additional functionality enabled from non-adjacent
link
MCR: needs a network diagram for this case.
Pascal: if I have a phone and I have service from the phone provider,
and if I have wifi tether, and I still want service... the phone is the
stub router. (when my fiber is cut)
Ted: what pascal just described falls into the homenet charter, and the
reason we constrained our charter the way we did, is because we wanted
to get something done.
Lorenzo: this does not require a new protocol, just options on the phone
to become a router.
Esko: cellular in the home... cellular backup of your (home) router.
Maybe nothing special. Might not be expensive cellular... often faster
than the wifi network.
Pascal: I wanted more than the RA... that the devices don't effectively
change their addresses... would like the home router to forward the
packets to the phone.
Lorenzo: but the source addresses would be wrong, and BCP38. (we could
NAT66, but...) but all the phone needs to send an RA.
MB: it's just a flash renumber, or multiple router scenario.
Chairs polled WG with one question: "Do you think we should adopt stub
network doc as working group document if includes DHCPv6-PD?"
("raise_hand": 26, "do_not_raise_hand": 0).
done at 11:04.