Tuesday, 11:00 - 12:40 UTC, 28 July 2020
Friday, 13:00 - 13:50 UTC, 31 July 2020
Chairs: Bob Hinden, Ole Troan
Minute taker: Barbara Stark, George Michaelson
Jabber Scribe: None
AD: Erik Kline
Introduction, Agenda Bashing, Document Status, Chairs, 5 min.
Working Group Drafts
IPv6 Application of the Alternate Marking Method, draft-ietf-6man-ipv6-alt-mark,
Giuseppe Fioccola, 10 min.
Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events, draft-ietf-6man-slaac-renum, Fernando Gont, 35 min.
Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers, draft-ietf-6man-grand, Jen Linkova, 15 min.
Active Individual Drafts
Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces, draft-templin-6man-omni-interface, Fred Templin, 20 min.
New Individual Drafts (as time allows)
Self-configuring Stub Networks: Problem Statement, draft-lemon-stub-networks-ps , Ted Lemon, 15 min.
Introduction, Agenda Bashing, Chairs, 5 min.
Working Group Drafts
IPv6 Minimum Path MTU Hop-by-Hop Option, draft-ietf-6man-mtu-option , Ana Custura, Gorry Fairhurst, 15 min.
New Individual Drafts (as time allows)
Attribution Option for Extension Header Insertion, draft-herbert-6man-eh-attrib , Tom Herbert, 10 min.
BIER in IPv6 (BIERin6), draft-zhang-bier-bierin6 , Jeffrey Zhang, 10 min.
Carrying VTN Identifier in IPv6 Extension Header, draft-dong-6man-enhanced-vpn-vtn-id , Jie Dong, 10 min.
IPv6 hosts detection, draft-li-6man-6hosts-detection , Jiang Li, 5 min.
Chair Slides: Introduction, Agenda Bashing, Document Status
Bob walked through the chair slides. There was no jabber scribe volunteer but Ole opined perhaps we don’t need one.
No Agenda Bashing occurred.
Ole does document status. 1 doc in edit queue (ICMPv6) temp address extensions submitted to IESG. nothing in last call
Two in WGLC. OAM doc passed all outstanding comments, ready to advance.
Two WG docs, path MTU (friday) and the alternate marking method (talked to later)
Two “contentiuous” last calls: the compact routing header. statement sent out as shown “impasse” awaiting SPRING WG outcomes. Timeline issues. planned to report, IETF109/110.
Andrew: (Liquid Telcom) Question the timeline. Been following. Status in SPRING “at best” is IETF110. Leaves me concerned. Quite a way away, doc has been around a while. Do we have to sit and wait until IETF110, CRH is likely to go full production, in code/routers in the next month or two. deployed, functional. To have to sit around and wait… more development on something outside of the IETF -> problems later on. What to do, if we cannot bring timeframe forward?
Bob: I was expecting a report to be available in September, and agree that timeline is longer than desired. We are discussing this with ADs and understand your concern.
Ron: Do we have a “red line date” of when we say we’ll wait no longer.
Bob: No. We were expecting something sooner this was news to us when we heard it on Monday’s Spring w.g. session.
Ron: Can you publish a date?
Joel Halpern (in jabber): The SPRING chairs have suggested that a first report should occur in mid-September. SPRING obviously can not tell 6man when we will have a final answer or whether or how long to wait.
Cheng Li (in jabber): Though the time line is the rough consensus of the first meeting of the DT, but we will try to speed up for sure.
Ron: No date / no answer is the same as refusing to do.
Ole: adopted “robustness for SLAAC” (on agenda later) other comments?
Fernando: when describing result of consensus process, there was consensus/agreement to work on problem but not solution. I went through comments on the ML, there were 2-3 comments with concerns with one specific section of the document but what I have seen so far, is not ‘objections’ against the rest of the document. When it comes to some of the objections made, they were vague. ‘its fragile’ when I asked for clarifications, hard to agree or disagree with a vague statement. But during my presentation we can focus on the topic and people can raise them.
Igor: (Akamai) I think this is important to have loss information, an dit has been presented in TSWG multiple times, great there is more thinking in 6MAN. Concerned that the thinking right now is purely about controlled domains: limited area. Very important to have loss information especially in the presence of encrypted protocols in the wide, e2e in the internet. Non-optional flowMarkingID could be considered by many people as a privacy concern. Looks like in context of Transports which provide flow identification themselves may not be neccessary to be mandatory. Second: we call it “loss-bit” better to call it ‘upstream-loss-bit’ and in TSWG we had an additional bit for ‘downstream-loss’ -additional bit is useful. Have draft to show how to do it for any generic transport protocol keeping track of loss.
Giuseppe: Thank you. Regarding the last comment. We don’t have loss bit measurements. It doesn’t make sense because this is just one direction. If you want to make 2 directions, you have to make it work. It is not bi-directional.
Igor: I recommend you review our draft. Upstream loss bit is also sent in the same direction as downstream. You do not need to observe any return traffic. It is the same sender sending additional markings for upstream loss in this direction. I invite you to read the draft again.
Bob take to the list, have to manage time.
Fernando: Start with question I wanted to ask before (during chair slides): You mentioned there was consensus to work on a problem but not the solution. I went through the mailing list and there were concerns with specific sections but didn’t see objections against the rest of the document. Some of the objections that were made were vague (e.g., this is fragile). When I pushed for specifics, people did not provide specifics.
Bob: we want to see specific text, and the WG response to that.
Fernando proceeds with going through slides. He pauses after slide 2 to see if there are comments.
Dave Thaler: slide looks ok to me as long as one thing is true: is it the case that a host only extends the lifetime and never reduces it on receipt of a PIO? One router counting down to zero, but not quite zero yet, confirm host always uses the maximum across RAs I think its fine then.
Fernando: We underspecified it in that respect. But we should be explicit and use the maximum, as you say.
On slide 7…
Dave Thaler: You mean this is a previous PIO from that particular router
Jen: I am confused here, is it more or less the same algorithm you had in the text before adoption?
Fernando: Yes. What we are doing is discussing…
Jen: this algorithm looks a bit ‘fragile’ in the event of data being lost or multiple RA. Not sure what it means for existing implementations.
Fernando: I’m not sure why you think it is fragile. Can you elaborate?
Jen: I will take to the list, I am just confused, a lot of disagreement about this particular section before adoption so not sure why you propose the same text again.
Fernando: What the chairs suggested is that the group would discuss each of the mitigations in the doc. If you look at doc, you will see that none of the mitigations in these slides are in the doc. I am presenting the proposed mitigations here for people to agree / disagree. I would appreciate if you elaborate on scenario where things might break because it’s difficult to respond if I don’t know what you mean.
Ted Lemon: Do we actually have any data about this? The question that Fernando and Jen is debating is not a theoretical question, we could collect data and see if this is a real problem or not. I wonder if this presentation and the draft has been motivated by data which can be looked at which would help. Have you formally collected data in a manner which can be analysed? difficult to answer the questions unless there is data to refer to.
Fernando: What specific data are you referring to? What would you like to see measurered?
Ted: We could do some data collection on IPv6 networks, notice if RA are being missed or not. prefixes lost. and then implement this algorithm, run on devices, see what happens. Do we loose PIO’s which shouldn’t have been lost?
Fernando: When you say “losing PIO” do you mean flash renumbering occurs or RAs get lost…?
Ted: we know on a flash renumbering event there is going to be issues. But, if we did this thing, this mitigation, what would happen… you could set up some code, ‘how often do I miss a PIO’ if I ran this algorithm how often would I lose my prefix. it would be nice to have the data
Fernando: OK. Point taken.
Dave Thaler: looking back at RFC4861. if I have a bunch of off-link prefixes, can be split across multiple RA instances… each with a subset of options. what do you want to happen in that case?
Fernando: What would happen is, when you receive 1 it would reduce the lifetime but then things will continue normally. The algorithm does accommodate situation where you split the RAs. This is not on the slides. But we can discuss.
Moving on to slide 9…
Fernando: please describe scenario, what you have in mind where things might break. To find something that we missed, or we think the scenario can be mitigated or not a problem, in order to tell.
Bob: Thank you. We will continue on the email list. We can go forward from that, and discuss indivual issues there.
Dave Thaler: I have a vague recollection that I asked a question at a previous IETF meeting, but can’t find any discussion in this doc. Does this require the host and the router to BOTH change, so it may be a long time before it has any impact? Have you looked at having the router do something that works with existing hosts?
Jen: initially we had one draft (in v6ops) discussing all possible things we might do, then the document discussed pro’s and con’s and the document said… “do this” -the document had to be published together. AFAIK there are implementations on the router which are doing this. Node SHOULD not … does not say MUST NOT The only thing you can do without making any changes on the host, could start ND for that address. the problems with that is, if you have 2 routers on the network e.g. first hop redundency there is no guarantee same router used for exit traffic. requirement discussed, want all routers to have this, to see GUA packet There are different things you can do, not prohibited by RFC, this one we have to update, nothing prevents you from reading v6 RFC (ND cache draft) and doing.
Dave: I think you’re saying the answer to my question is in the v6ops draft and not in this one and you expect these 2 drafts to proceed at the same time, and reference each other. Thanks. That answers my question.
Ole: need another round on the mailing list before we advance this document.
Bob: May have to move Ted’s talk to Friday unless Fred can reduce time in his upcoming presentation.
Bob: Ole and I have discussed. There is a lot. We will ask mailing list if there is interest in forming a design team to work on this. I think it will require detailed work and there isn’t enough traffic on the list. So we will proceed that way unless we hear otherwise.
Éric Vyncke (AD): I just wanted to confirm what we discussed with Bob and Ole. Also it looks like doc has changed since November when I last read it. The doc is quite complex. Is there any chance you can separate into multiple docs to make things easier to swallow?
Fred: already have this (work) as two documents. Also in the (related) mobility spec, we don’t have as a topic for discussion, we have functions separated out. I believe all the pieces in the OMNI spec need to be there.
Éric: OK I need to review again. And we need to start adoption call and get design team.
Bob: OK, we will start that later in this week.
Ted: Taking to ‘INT’ area but wanted this on 6MAN radar
Ole: We can continue on mailing list. We are almost out of time. But are there any quick questions now?
Alexander Petrescu: This IPv4 target: where does it come from?
Ted: some people don’t have native IPv6 connectivity, so we still need to make that work in principle. you may not even need IPv4 connectivity in any case, may operate locally in the home, in the building infrastructure, but in the case of devices which do need to connect to cloud services I think it is neccessary to support IPv4.
Bob: Thank you. We will see you all on Friday.
Ole and Bob opened the Friday session and displayed the agenda for this session.
Éric Vyncke: Thank you. My concern is there is a headend bias. Can you comment?
Ana: Yes, we would love to diversifu the test setup. We would like to do this with web servers as well.
Éric: I would like to get a wall of shame of people dropping those legal packets. Just a personal comment.
Ana: We are working with Comcast to resolve this.
Toerless: The Linux API header says extensions can be received.
Ana: there needs to be code added to define this specific option. There is no generic option.
Gorry/Bob: Ana and Gorry are planning to revise the doc to bring it back to the WG.
Erik Kline: Asking about the assertion that inserting errors doesn’t change the ECMP processing .
Tom: If devices are doing that it will still work. If not, they are breaking IPv6.
Erik: No guarantee that header insertion will not break header insertion.
Tom: We are not changing any of the fields used by ECMP.
Erik: But you may be considering too much information.
Tom: I think this is the so-called parsing buffer issue. But this should be in a controlled domain where the admin can address the issue.
Éric Vyncke: I was wondering – it’s not really an extension header you are requesting. It’s more like a transport header. Is 6man the right place?
Jefffrey: This is in bier, but I wanted to present to 6man to get comments.
Éric: We may want to involve transport and routing.
Jeffrey: bier is just a payload.
Toerless: If this is just information to 6man, that’s ok. But if there is a request for more I would like to understand better.
Jingrong Xie: (could not quite hear)–there is no difference of IPv6 next header for upper-layer or IPv4 protocol.
Jeffrey: You are correct. I made a mistake in that slide.
In middle of presentation…
Joel Halpern: This draft assumes a new header is needed and then finds a convoluted solution. But I challenge the premise that a new identifier to be processed in the network is needed.
Jie: I would like to finish the presentation first. (continues with presentation)
Bob: (before completion of presentation) We need to wrap this up. I think you should answer Joel’s question now, rather than explaining the proposed solution in more detail.
Jie: I answered in email. This is different kind of identifier. Different concept and different functionality.
Bob: Thank you. Continue on mailing list.
[Slides](https://datatracker.ietf.org/meeting/10d defer further discussion to mailing list.
Bob: We are out of time.