Minutes IETF112: v6ops
minutes-112-v6ops-01

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.