Thursday, 7 November 2024, 09:30-11:30 (UTC)
Room: The Auditorium
Chairs: Bob Hinden, Jen Linkova
Minute taker: Adrian Farrel (somewhat, and enjoying that no one else has
helped with this, but thanks to Jie for fixing my record of what he
said). Formatting fixes from Ryo Yanagida.
Jabber Room: 6man@jabber.ietf.org
Meetecho (Full Client):
https://meetings.conf.meetecho.com/ietf121/?session=33353
Meetecho (Onsite Tool):
https://meetings.conf.meetecho.com/onsite121/?session=33353
Thursday, 7 November 2024, 09:30-11:30 (UTC)
Bob: Congratulations to Jen for Itojun award.
Bob: We don plan to spend time on draft-ietf-6man-rfc6724-update because
chairs declared concensus to advance.
Ted Lemon: Does this document mention stub router?
Jen: No, but should it?
Ted: I need to think this through. In terms of src address selection it
may be damaging to prefer it.
Jen: OK to leave off agenda, but we will allow a little time before
advancing it.
Suresh: For address assignment: we have talked to stakehlders.
Everything seems good.
Bob: When we do WGLC, please send that in an email.
Speaker: Ron Bonica (remote)
Richard Patterson: It is harder to inject an MPLS label than an address.
How do you validate that a customer doesn't generate a bogus VPN
identifier. (e.g. error, snooping, ...)
Ron: No way to tell. Current tech has same problem
Adrian: The draft that Ron mentioned that describes what an Experimental
I-D should include is
https://datatracker.ietf.org/doc/draft-bonica-gendispatch-exp/ We would
realy appreciate reviews and feedback. There is even a dedicated non-WG
mailing list for discussing it.
Ron: Yes. We are trying to be more specific about experiments.
Fabien: I haven't read the draft. Don't we already have SRv6?
Ron: Yes. SRv6 has VPN options. But this draft needs no change to
control plane or the 100s of pages that explain SRv6. For many operators
there is no TE requirement - just need a way to convey service info from
ingress to egress.
Fabien: This is also true for SRv6
Ron: Yes. But this is simple. So this is an experiment.
Jen: Can protect domain by filtering. But MPLS is fail-closed. So you
need to reflect this in the security considerations.
Ron: We do have something about that in our Sec Con already.
??? : There is a draft in SPRING on securiy considerations. Suggest to
read and consider in this context.
Speaker: Ron Bonica (remote)
Zafar Ali: Your assertion is incorrect. For RSVP-TE-v6 should continue
to use this. The industry is interested in this function. You need to
clarify where you are saying existing protocols can use, and where you
are prohibiting.
Ron: Appendix lists protocols that use RA. The document is not a mandate
for existing protocols to stop, just
Zafar: Just to clarify, there is no implementation of RSVP-TE-v6
Ron: Please look at appendix and see if it covers RSVP.
Tim Chown: s/IPv6 Router Address Option/IPv6 Router Alert Option/ !!!!
Tim: Are there any I-Ds that currently propose use of the option?
Ron: I don't know how to look for this.
Bob: Maybe search for reference to "Router Alert" RFC.
Tim: It seems that inter-domain is most likely to drop. So do we need to
spec this for intra-domain?
Ron: Yes, that is the problem, but if we can get it dropped forever it
would make things safer.
Lorenzo: Why does MLD use RA when it is link local?
Ron: I agree. But it isn't our business. Redirect to PIM
Lorenzo: And we can't change it anyway? We can say "defined that way"
and give advice
Ron: And some/most implementations don't even use RA
Zafar: I looked at appendix. It is pretty clear. Would be nice to call
it out. Your Abstract is very clear
Ron: OK. Would you like RSVP-TE-v6 to use RA?
Zafar: I would like it to use it
Ron: Why, when your v4 doesn't use it. Perhaps the reason to keep it in
is for other implementations
Suresh: OK until you said hope it will go away.
Ron: Yes, hoping it will wither away in 10 to 20 years
Suresh: I'd be worried about trying to kill it because of
implementations we don't know about
David: Need citation for your statement about MLD not using RA. I think
it is not true. You would fail conformance tests.
Dropped per chairs' agenda bash at top of notes
Speaker: Jie Dong
Greg Mirsky: Do you envision NRP field is identical to the NRP Selector?
The field is ambiguous. We agreed to use "NRP Selector" not "NRP ID"
Jie: The terminology for this field has been discussed between authors
of several drafts, and there is ongoing discussion in TEAS about this.
The draft reflects the feedbacks collected so far.
Greg: In MPLS WG there is a draft using different terms. Different
number of bits. Would be beneficial if both data planes use the same
size fields.
Jie: Discussion about this is also on TEAS list.
Greg: Does TEAS have control of or knowledge of MPLS data plane. Should
enable mapping between data planes.
Jie: TEAS is working on the terminology and general guidelines of NRP.
Welcome to discuss this on TEAS list. The encoding is specific to
different protocols and belong to 6man or MPLS.
Jen (as chair): Problem statement is in scope for TEAS. What you need
from us is just allocation. We will talk to TEAS chairs, and probably
issue joint WGLC. We will talk about early allocation after working
group last call.
Speaker: Richard Patterson
Tim Winters: They don't understand what "configuration change" means, so
they don't do it.
Richard: Include exmples of what changes lead to MUST send
notifications.
Tim: Or set more specific rules
Jen: Ditto
Suresh: Thahks for bringing this back. Recall conversation on this. Text
is a bit hand-wavy about attacks. Needs some better reasoning. How was
it evaluated and why it is not a valid issue any more
Richard: Yes
Suresh: OK with proof of lifetime going away
Tim: Agree need to be really clear.
Lots of "try" and "should" needs clean-up
Eric V: If you have IoT sleeping nodes you find that there are
problematic. May need advice of "should not use these values in these
environments"
Tim: 6374-update has come along since last time. May need to think about
ULA persistence across reboot
Richard: Not sure this changes the impact. Need to think
Fernando: Regarding Suresh's comment. Think we have some text about
this. Threat model for SLAAC is "tursting local devices"
Suresh: There is text. Needs more text. E.g., RA Guard
Richard: So no objeciton to what we are doing. Just need to justify it
Lorenzo: 60% is very optimistic.
Jen: Please send to list
Lorenzon: Up to or including 90%
Speaker: Jen Linkova
Fernando: In principle, seems smart. But I have open issues.
Going to list
Tim: If router has multiple link locals will it send multiple RAs
Jen: Yes
Tim: Need to give advice for routers to get this right.
You have text that says prefer over default router preferences. Need
some more guidance. I'll send note
Loernzo: If multiple RAs. Need to talk about synchronisation
I looked at RFC8208 and it is incompatible RFC6724. Maybe need to
deprecate it?
Jen: Not a problem with this I-D
Eric: ??????
Using the prefix as interface I-D
Jen only works if there is only one router with the prefix.
Eric: good
Eric: Need 6471bis
Tim: I like it. But is there anything for 6724 update?
Jen: Only change is to ask router to do something new
Bob (w/ chair hat on): Given the overlap between this draft and
draft-ietf-6man-slaac-renum these drafts should be merged. There is a
lot of overlap and it will be simplier for the working group to have a
single document. Authors should produce a merged version.
Speaker: Tim Winters
Tim: (For various proposed changes) Does anyone have a "please don't do
this"
--- nothing from room
Tim: re: RFC8028 — anyone got running code?
Lorenzo Colitti: Not possible to have running code for an RFC you can't
understand.
We assume if hosts do 5.5 then it just works, but not true. You have to
do src/dest as well.
Tim W: I will think about this and try to find out what current status
of implementations is
Lorenzo: People have said DHPv6 is a MUST. It is a SHOULD right now.
Tim: We should try MUST and see what people say. Enterprises and
Governments hate SHOULD
Lorenzo: So long as not say MUST do ILNA
Jen: Small networks. Don't need to say MUST
Tim: Have had arguments both ways. Will try to propose text
Jen: Don't agree we understand how multi-homing works. Need to write
some guidance. What do we expect host to do.
If we can cover 90% of typical scenarios that will be "enough".
Tim C: RFC8678 is entreprise multihoming? This assume 5.5. is there and
works. Also conditional RA work assumes 5.5, but not widely implemented.
So can't make it a MUST if tricky to implemented. 6724 update is making
it an unconditional MUST.
Jen: Might sit down and write some text about how multi-homing actually
works. Perhaps a separate I-D
Tim: So we have multiple questions and need clarity.
Philipp Tiesel: 2 remarks:
David L: 8028 says a host must select default router. So it essentially
requires src/dst routing
Suresh: 5175 flags option is MAY. This it should be a SHOULD. Note there
is a bit for SLAAC now
Lorenzo: For DHP stuff. Could say if n/w needs to track should use INA
or whatever. So should give advice
Bob: Chairs will proceed to an adoption-call.
Speaker: Ron Bonica (remote)
Zafar Ali: If I do HBH traceroute and look at what has changed, could I
not do similar thing?
Ron: Not really. Suppose I do traceroute through NAT. You'll not see the
NAT. This would show you.
Also traceroute only shows 16 bytes, so if HBH options have changed you
won't see that
The main thing is that NAT will obscure addresses
Tobias: A bit concerned about security considerations. Need to go into
rate limits and zero padding especially in the presence of compression
on link. Should this be off by default.
Ron: Agree with off by default
Lorenzo: Please avoid making it easier to debug NATs.
Ron: So you want to not make it easy to deploy NATs
Lorenzo: By making it hard to debug it makes it hard to deploy
Ron: Sounds antisocial
Lorenzo: We should really think about this in context of IAB's view on
NATs. Remove addresses - makes it smaller.
Taken to the mailing list.
Speaker: Fred L. Templin (remote)
Dan King: Highlight HP-WAN BoF. How does this fit in?
Fred: Not aware of BoF
Lorenzo: Trying to improve perf == good. Changing wire format seems
unachievable. Advantages over GRO seems not enough to justify this.
Fred: GRO as it stands, instead of individual packets, send as jumbogram
L: Again, changing wire format is a problem
Tobias Fiebig: Would lead to more path MTU issues. Not sure it can work
over the Internet.
Fred: Have a path probe service in this proposal
Tim Chown: HP-WAN BoF discussed jumbo pkts, but only in context of 9K,
not this work. This approach is "ambitious".
Bob: Suggestion that Fred should investigate what happened at the HP-WAN
BOF.
Unfortunately no time for "if time allowed" talks. Slides have been
uploaded.
Meeting adjourned,see you all at IETF 122 in Bangkok.