1 IPv6 Operations and IPv6 Maintenance Joint Meeting - IETF 112
Thursday, November 11, 2021 14:30-15:30 UTC
* Chairs: Ron Bonica, Fred Baker
* Minute taker: Barbara Stark, Giuseppe Fioccola
* Jabber Scribe: none
* Jabber Room:Êv6ops@jabber.ietf.org
* AD: Warren Kumari
Friday, November 12, 2021 12:00-14:00 UTC (joint with 6man)
* Chairs: Ole Tr¿an, Ron Bonica, Fred Baker, Bob Hinden
* Minute taker: Barbara Stark, Shuping Peng
* Jabber Scribe: none
* Jabber Room:Êv6ops@jabber.ietf.org
* ADs: Warren Kumari, Erik Kline
Meetecho:
* Thursday session:Êhttps://meetings.conf.meetecho.com/ietf112/?group=v6ops&short=&item=1
* Friday session:Êhttps://meetings.conf.meetecho.com/ietf112/?group=v6ops&short=&item=2
2 Agenda
Thursday, November 11, 2021 14:30-15:30 UTC
* Administrivia
* Pros and Cons of IPv6 Transition Technologies for IPv4aaS (draft-ietf-v6ops-transition-comparison)
* Scalability of IPv6 Transition Technologies for IPv4aaS (draft-lencse-v6ops-transition-scalability)
* Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop Deployments (draft-xiao-v6ops-nd-deployment-guidelines
Friday, November 12, 2021 12:00-14:00 UTC
* Administrivia (5 minutes)
* Goals of this meeting (10 minutes)
* Requirement and solution drafts
o Operational Issues with Processing of the Hop-by-Hop Options Header, draft-ietf-v6ops-hbh (20 min)
o IPv6 Hop-by-Hop Options Processing Procedures, draft-hinden-6man-hbh-processing (20 min)
o Limits on Sending and Processing IPv6 Extension Headers, draft-herbert-6man-eh-limits (20 min)
* Lightening talks on use-cases (20 minutes, strictly limited to 5 minutes and 3 slides per talk)
o IPv6 Minimum Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option
o Approaches on Supporting IOAM in IPv6, draft-song-ippm-ioam-ipv6-support
o Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension, draft-dong-6man-enhanced-vpn-vtn-id
o IPv6 Application of the Alternate Marking Method, draft-ietf-6man-ipv6-alt-mark
* Structured group discussion of the following questions (25 minutes)
o Do we want to proceed with rehabilitation of the HBH?
o Do we want to take some other action (e.g., deprecate the HBH Option)?
o Do we need to reexamine currently defined HBH options?
o Do we want to deprecate selected HBH options?
o What work / documents need to progress to make this happen?
3 Thursday Notes
4 Administrivia
Notewell was displayed. There was no other administrivia, no chair slides displayed, and the chairs went straight into presentations.
5 Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Draft:Êdraft-ietf-v6ops-transition-comparison
Gabor Lencse presented. Slides:ÊScalability of IPv6 Transition Technologies for IPv4aaS
There were no comments
Ron: We will start WGLC next week.
6 Scalability of IPv6 Transition Technologies for IPv4aaS
Draft:Êdraft-ietf-v6ops-transition-comparison
Gabor Lencse presented. Slides:ÊPros and Cons of IPv6 Transition Technologies for IPv4aaS
Gabor: We would appreciate feedback.
Ron: Comments? There are no comments. Note that Fred Baker (co-chair) is having problems connecting to Meetecho.
7 Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop Deployments
Draft:Êdraft-xiao-v6ops-nd-deployment-guidelines
XiPeng Xiao presented. Slides:ÊIsolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop Deployments
Dave Thaler: Good presentation. Thank you. There is an IAB RFC that you could reference: RFC 4903. I noticed that was not in list of references.
XiPeng: Thank you. We will look and add to the references.
Nalini Elkins: This is a big area of confusion. I will have various people take a look at this who manage private networks and we will provide feedback.
XiPeng: Thanks.
Jen Linkova: Thank you. Very interesting. Especially interested in L2 isolation. How does isolation help with poisoning the router? If I look at this from enterprise perspective, IÕm not sure if there is a solution. Do you have any deployment recommendations?
XiPeng: If you do L2 isolation, you may require many interfaces. Even if you do L2 isolation, other hosts may still poison therouter. I agree with you. L2 isolation does not automatically solve problems. You also need to enhance the router. If we look at L2 isolation and unique prefix Ð all of this requires the router have additional capabilities. Our draft talks about where it is and isnÕt appropriate to introduce many interfaces. So donÕt do it where it isnÕt appropriate.
Jen: Are you talking about existing technology that could be used to enhace the router?
XiPeng: RFC 8273 authors say that implementation exists. But the implementation is not clearly specified (what routers need to do). I think we need a draft that says what routers need to do to support RFC 8273.
Erik Kline: IÕm concerned with how much discussion of Wireless ND there is. When operators discover there is no Wireless ND (WiND) implementations I think there will be concern.
XiPeng: There are some WiND RFCs published by IETF. I will discuss more with you offline to understand better.
Erik: You do mention it is appropriate for 6lo cases, but I donÕt think this will be clear to an operator.
XiPeng: Some operators are starting to to do IoT, so I do want to understand how to address your concern.
Pascal Thubet: WeÕve never resolved whether that was applicable. We need to study.
Ron: Can the 3 of you get together to determine whether or how WiND should be included?
Pascal: I do think it could be useful.
Erik: I think itÕs fair to include it. But more guidance needs to be provided to operators.
8 Close Thursday
Ron: We have the Friday session tomorrow. Are there any other comments or topics for today? No.
9 Friday Notes
10 Administrivia
Ole Tr¿an presented the first few slides. Slides:ÊJoint Meeting Note Well and Agenda
No-one bashed the agenda.
11 Goals of this meeting
Ron Bonica presented. Slides:ÊChair Slides
12 Operational Issues with Processing of the Hop-by-Hop Options Header, draft-ietf-v6ops-hbh
Gyan Mishra presented. Slides:ÊOperational Issues with Processing of the Hop-by-Hop Options Header
Ron: To stay on agenda we will hold questions until the 25 minute Q&A time at end of this session.
13 IPv6 Hop-by-Hop Options Processing Procedures, draft-hinden-6man-hbh-processing
Bob Hinden and Gorry Fairhurst presented. Slides:ÊIPv6 Hop-by-Hop Options Processing Procedures
Bob: Want to add that there needs to be compelling use case for a specific HBH option that would encourage it to be deployed Internet-wide.
Ole: We will hold further discussion to end of this session.
14 Limits on Sending and Processing IPv6 Extension Headers, draft-herbert-6man-eh-limits
Tom Herbert presented. Slides:ÊExtension Header Limits
Ole: Thank you, Tom. We will now start the use case talks.
15 IPv6 Minimum Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option
Gorry Fairhurst presented. Slides:ÊIPv6 Minimum Path MTU Hop-by-Hop Option
16 Approaches on Supporting IOAM in IPv6, draft-song-ippm-ioam-ipv6-support
Haoyu Song presented. Slides:Êdraft-song-ippm-ioam-ipv6-support-02
17 IPv6 Application of the Alternate Marking Method, draft-ietf-6man-ipv6-alt-mark
This presentation was moved before ÒCarrying Virtual Transport Network (VTN) Identifier in IPv6 ExtensionÓ to allow Jie Dong time to fix audio issues.
Giuseppe Fioccola presented. Slides:ÊHBH Use Case: IPv6 Application of the Alternate Marking Method
18 Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension, draft-dong-6man-enhanced-vpn-vtn-id
Jie Dong presented. Slides:ÊCarrying VTN Identifier in IPv6 Extension Header
19 Structured group discussion of the following questions
20 Do we want to proceed with rehabilitation of the HBH?
Displayed last slide of:ÊChair Slides
Eduard Vasilenko: I donÕt think itÕs possible to enforce use. If there is no business case, people will still ignore it. Enforcement is not a good idea. The 2nd type of solution is to restrict number. But if there is not case for 1, limiting to No more than n will not help. IÕm against any restriction. 3rd type of solution is to change the architecture Ð characterize some options as going to control plane and others to data plane. In general, IÕm supportive and think it makes sense to try.
Tom Herbert: In BobÕs draft you mentioned that in RFC 8200 it made no impact when that change was made. Do you have data to shpw that was true?
Bob: Use of HBH has not occurred.
Tom: Do you have evidence that previous practices have not changed?
Bob: We documented the current state Ð what was happening in practice.
Ron: Default for most routers is to punt to the control plane. Otherwise, they drop. I know of at least one vendor who allows ignoring the header.
Tom: Having router vendors ignore instead of drop would get us halfway there.
Pascal Thubert: HBH is useful and can contain useful information. But most useful cases are in limited domains. What is meant by Internet-wide usage? Interest is across much of people who use the Internet. Does that count?
Ron: I donÕt think so.
Shuping Peng: Thank you for having this session. Several colleagues did present use cases. You can see from drafts there are 3 operators who want to use HBH header but currently have to block it. We are looking to solutions described in BobÕs draft. In our draft, we also talk about migration strategy. We need to talk about how to use it in a real network. Make sure we can co-exist with current set of devices.
Jen Linkova: There are definitely people who want to make this work. So there is no reason to talk about deprecation. We should talk about how to make these usable. Find use case for them and then solution. But donÕt try to solve in absence of use case.
Cheng Li: We need these. Customers want this.
Chongfeng Xie: I support work because it can support many functions (IOAM, etc.). HBH has not been widely used, but this does not mean that operators are opposed. They donÕt know how to use them because theyÕre new. We should also consider manufacturers in this draft.
Warren Kumari: I was going to save this for the end. When we oroginally plannned this session, I was concerned with how session would go. IÕm happy and impressed with attitude and willingness to move forward,
Jie Dong: I support work on HBH header. We already have several use cases for limited domain. Before considering larger Internet-wide case we need to work on these.
Ron: IÕm opening up for further discussion. Assuming we go forward with the work, IÕd like to look at last 2 questions:
* Do we need to reexamine currently defined HBH options?
* What work / documents need to progress to make this happen?
Gorry Fairhurst: Surely we can find dead wood in current options. Some of what we have in RFC series isnÕt used. We may find that odd-sized things donÕt exist.
Ron: Getting rid of dead wood doesnÕt do much except Router Alert option. How do people feel about deprecating that?
Shuping Peng: Whether to deprecate Ð IÕm not sure how we want to do this? You never know. Regarding document nd work Ð the requirements were just mentioned. In our draft we have dedicated a section on these requirements. YouÕre welcome to join us to help make it more reasonable and guide solutions.
Eduard: Reading RFCs is a research project because you have to go through references. ItÕs a huge job. In Wi-Fi they try to use a single primary document. ItÕs possible to take a single document and read everything. So they have thousands of pages. ItÕs madness Ð the opposite extreme. You shouldnÕt have to be an expert to understand.
ƒric Vyncke: I want HBH routing. IÕm unsure of deprecation of some options. They wonÕt be removed from old routers. Maybe we could go for BCP to not enable them? MLD snooping may still be required.
Ron: What does deprecate actually mean? I think it means it can still be used, but new protocols cannot use it. Does it mean more?
ƒric: Important question. I will have to look into that.
Bob: It usually means what Ron said. A deprecation document can define what it means in that context.
Erik Kline: And it means no re-allocation. Speaking as AD, we should have adoption calls for one or more of the drafts presented today.
Warren: Deprecate is like ÒupdatesÓ. No-one knows what it means so you need to explain inside the document where you use the term.
Bob: Queue is clearing. Final comments?
Erik Kline: Thank you all (chairs and presenters) for taking time for this and making a good effort.
Ron: Chairs, are there any next steps you would like to mention?
Fred Baker: I asked Tom to write a draft for 6man for a BCP for ignoring HBH options. That is a part of the path forward.
Ron: With no hats on Ð I think we probably need something like 3 documents we saw at beginning of this session: requirements, use cases, limitations. Do we need a house-cleaning document, to deprecate dead wood?
Fred: I agree that deprecation draft would be good.
Bob: I do think it would be better to write requirements, evaluations of each current HBH option in a draft would be good, rather than just in email. Also, I think this has been a useful session.
Gorry: I wanted to come back to meaning of deprecation for MLD and Router Alerts. I think there is something useful to write down.