Skip to main content

Minutes IETF103: 6man
minutes-103-6man-00

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2018-11-06 06:50
Title Minutes IETF103: 6man
State Active
Other versions plain text
Last updated 2018-11-09

minutes-103-6man-00
6MAN Working Group - Bangkok IETF Meeting
Tuesday, 6 November 2018, 13:50-15:50, Chitlada 3 

Chairs: Bob Hinden, Ole Trøan 

Minute taker: Barbara Stark, Max Stucchi
Jabber Scribe: Mikael Abrahamsson

Jabber Room: 6man@jabber.ietf.org 
Meetecho: https://www.meetecho.com/ietf103/6man 

------------------------------------------------------------------
------------------------------------------------------------------

Agenda
-------

Introduction, Agenda Bashing, Document Status, Chairs, 10 min. 

Working Group Drafts 

   IPv6 Segment Routing Header (SRH),
   draft-ietf-6man-segment-routing-header, Darren Dukes, 15 min.

   IPv6 Router Advertisement IPv6-Only Flag,
   draft-ietf-6man-ipv6only-flag, Brian Carpenter, 15 min.

Active Individual Drafts 

   Discovering PREF64 in Router Advertisements,
   draft-pref64folks-6man-ra-pref64, Jen Linkova, 15 min.

   Making IPv6 options an option, draft-herbert-ipv6-update-opts,
   draft-herbert-6man-icmp-limits, Tom Herbert, 20 minutes.

   Path MTU Solution Space, draft-troan-6man-pmtu-solution-space, Ole
   Trøan, 10 min.

   Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option, Bob Hinden /
   Gorry Fairhurst, 15 min.

   Destination Originates Internet Control Message Protocol (ICMP) Packet
   Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica, 15 min.

New Individual Drafts 

   In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options-01,
   Frank Brockners, 5 min.

   OAM in Segment Routing Networks with IPv6 Data plane,
   draft-ali-spring-srv6-oam, Zafar Ali, 5 min.


==========================================
Introduction, Agenda Bashing, Document Status, Chairs, 10 min. 
==========================================

Bob and Ole went through Introduction and Document status slides
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-introduction-and-document-status-01

Note well.
No changes to the agenda.

Suresh Krishnan: draft-ietf-ipwave-ipv6-over-80211ocb-30 will be sent
back to 6man to look over once it has completed other reviews.

Zafar Ali: Will discuss comments to draft-ali-spring-srv6-oam-01 on the
mailing list.


==========================================
IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header 
==========================================

Darren Dukes presented the slides
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-segment-routing-header-srh-00

Darren:  Goal is to close all of the issues by the end of December.

Joel Halpern: Thanks for work. We've agreed on need for using
encapsulation mode and I agree on clarification. But why don't we use
that mode all the time? It would make everything so much simpler.

Darren: <explained how it works>

Joel: If it uses the encapsulation mode, it works fine. There are no
special cases. Much cleaner.

Darren: Maybe we need to continue as separate thread on the list.

Joel: It seems the appropriate thing to do.

Ron Bonica: Thank you. Many good changes over last 6 months.

Ole: Thank you.

Suresh: Will you do another WG last call?

Ole: It will go into last call when all the issues are resolved.




===========================================
IPv6 Router Advertisement IPv6-Only Flag
draft-ietf-6man-ipv6only-flag
===========================================

Bob Hinden presented slides
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-ra-ipv6-only-flag-00

Lorenzo Colitti: I have no problems with this. I have some nits.

Bob: OK. Send them to us.

Lorenzo: The nature of IPv6 provisioning is always slower than IPv4 at
the moment. You can avoid turning IPv4 off if you notice it's already
working, and I suggest not looking at this flag in this case to avoid
lots of attacks.

Bob: OK. Suggest some text.

Eric Vyncke: There is a point in the introduction where you discuss lots
of benefits. There is a sentence that it's true, but I would remove it.

Bob: I would agree to removing it. There was discussion on the list about
it and I remember it.

Suresh: AD hat on: I don't want you to go down the same path as ?. Are we
trying to cram 3 values into 1 bit? We need to be careful.

Bob: I'm not sure what I should take based on your suggestions.

Suresh: Try to be clearer on expected behavior. More description on what
does and doesn't happen. How things actually work isn't clear.

Bob: There could be reasons for keeping this as suggested behaviour. MUST
may not be the right word or approach.

Mikael Abrahamsson: I think this SHOULD is perfect and we can leave it to
the system to decide how to handle this. Let people find out what works
and what doesn't, and then we'll work on a new document.  Bob: v6ops will
get to work on this in three years.

Suresh: Mikael, do you want the host behaviour removed ?

Mikael: I'm fine with it as SHOULD. We can have a BCP in 2-3 years.

Suresh: That's where people are rat-holing on. 

Lorenzo Colitti: The M and O bits were controversial because they arose
from a big fight. That's why they are controversial. As an implementer,
I'm fine with current recommendations. We are not going to have a
one-size fits all solution.

Bob: When we ran the IPv6 only network some meetings ago, that's when we
realized we needed this.

Jen Linkova: I like this draft, and as a network operator, I think the
host behaviour section is clear enough on what I expect hosts to
behave. I like Lorenzo's comment on ignoring expiring routers'
lifetime. I think overall it's quite good.

Ole: I'm not sure what I hear here is representative of the mailing list.
Suresh: I don't think it is. We have fairly significant support for the
text as of now. I'm not sure it's holding the mailing list. There are
people there feeling otherwise. Let's post it there and see how it goes.

Ole: My problem is that there's no consensus on the list.

Suresh: Yes, this is a problem I have with current state.

Bob: It seems a lot of email discussion was just about the email
discussion and not focused on the text. Commenting on the text might be
simpler.

Suresh: Like the one that started it all that said "I'm really against
it"

Mikael: Relaying Bjoern Zeeb: The -04 draft says MAY and not SHOULD. If
v6 worked why turn on v4 again ?

Ole: We could do some consensus calls. We could ask about the flag being
prescriptive or not, making it just a hint. Given what's going on in the
ML, we can try this call in the meeting room and then we'll see how it
goes on the list.

Mikael: I talked to one of the large host implementors and I got the
feeling they wanted the hint. The feedback was similar to what Lorenzo
said.

Ole: It is already quite prescriptive.

Mikael: We're not the protocol police. It should be SHOULD.

Ole: As an implementor, how would you know what to do ?

Lorenzo: Your life as an implementor is not knowing what to do. We're
overstating the level of requirements that a SHOULD imposes. We're here
to make sure implementations are interoperable.

Mikael: What Lorenzo said, that's my take on it. It would happen anyway,
even if we put a SHOULD. I think this document is fine as it is.

Ole: Thank you. Should we ask questions?

Mikael: I think if we point out that the SHOULD leaves space to
implementors, we can have consensus.

Lorenzo: Who is arguing for MUST ?

Mikael: I've seen people on the list asking for it. I could be
misinterpreting it, though.

Bob: The text in the document is not prescriptive, but it is unless you
have a reason to do otherwise.

Mikael: For me that's fine and it gives implementors leeway to do their
thing.

Lorenzo: I think if you change the text to really mean a hint, then you
could get consensus. That could be a possible way forward, together with
security concerns.

Ole: At some point the flag will have little value.

Lorenzo: It's a useful statement of intent. It's easier to see it and
then take action.

Bob: It's a signal from the administrator.

Mikael: Also on the security section: If you don't have first hop
security, you have problems anyways. I'm pretty tired of repeating the
same concepts.

Ole: I wonder if I should sit with Mikael and Lorenzo and write the short
paragraph and send to list.

Suresh: Can you get Bob to do it with Lorenzo and Mikael ?

Ole: Yes, I will do that.

===========================================
Discovering PREF64 in Router Advertisements
draft-pref64folks-6man-ra-pref64
===========================================

Jen Linkova presented slides.
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-discovering-pref64-in-router-advertisements-00

Fred Baker: I support adoption of the document. I have an issue,
though. You don't want to translate private addresses into an IPv6
prefix. That creates a problem. In a case I witnessed, where they would
like to run NAT64, they would have to get a public address for every
location.

Jen: It's well-known prefix. It's not us. Private address space must not
be translated using well-known prefix. Other translation is
ok. Translation RFC (will get reference during break) says this is the
rule.

Fred: That needs to be in the draft. We need to be able to put private addresses.

Jordi Palet: Fred, I don't think that's a problem. support the
document. I sent comments to list. For selection of prefix I think the
order is the same as what we have. See my draft of 464xlat-05.

Ole: Jordi, please let's take this to the list.

Mark Andrews: This is an IPv6 only network. We are going to have lots of
networks with DNS64 from the ISP and dual-stack internal. We need to
cover this scenario. We need to know which local addresses are excluded
from the process. We can do it relatively easily by pointing at a DNS
Entry.

Jen: I think it would be tricky to do it with DNS.

Mark: I can have the entire ACL in DNS signed (?)

Jen: I actually think you can just use well-known prefix.

Mark: We're dictating how network operators number their space here.

Jen: Kind of.

Mark: The option is not flexible enough for real life scenarios.

Lorenzo: Not true. No other mechanism has support for this as of now.

Ole: Mark, Are you able to propose text?

Mark: I suggested to add a DNS name that points to a
record/option. That's already on the list.

Jen: Then let's take it on the list.

Xing Li: I support this document. Please don't limit it to a /96. Make it
variable length. We've seen the need for this in our implementation.

Jen: Should we consider 2 options, one of flexible variable length so you
can minimize size when possible?

Suresh: It says the DNS type is an ADNS option type. DO you mean that ?

Jen: It might be a typo. I'll correct it.

Suresh: Lifetime is unspecified.

Jen: It makes it easy to change the prefix. 

Suresh: Then you need 2 lifetimes?

Jen: No

Suresh: I think we need better specification on the lifetime. Let's take
it to the list.

Lorenzo: I don't object on things I'm not going to implement anyway. I
leave it to the WG. We should think about putting things we're not going
to use and will stay with us for a long time.

Erik Kline: If the option is 8 bytes long, there should be a length field
in there somewhere.

Ole: Can we take comments back to mailing list and summarize? I think
there is support for the draft.

Chairs will do adoption call on the IPv6 list.


===========================================
Making IPv6 options an option
draft-herbert-ipv6-update-opts
draft-herbert-6man-icmp-limits 
===========================================

Tom Herbert presented slides remotely.
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-making-ipv6-options-an-option-00

Ron Bonica: I think this draft maybe premature. You bring one rule
mentioning destination option. The one in 8200 contradicts you. Who's
right ? Lacking the operational experience, do we want to make the rule
now or do we want to wait until we can use this option ?

Tom: So this was motivated by segment routing. Using destination option
before routing header was to satisfy requirement that segment routing
header TLVs have.

Ron: Is it possible that someone might want to use the destination option
before another EH ?

Tom: We don't want case where nodes are ignoring these.

Ron: A better approach might be to say that if a packet has a SRH, maybe
t's better to have the option before that.

Tom: The TLVs in the SR header are redundant to the DO

Eric Vyncke: Regarding the ICMP message to be sent when router hits its
processing limit (of extension headers), I support it but it is expired:
do you intent to write a rev ?

Tom: Yes, I can updated. Please comment on list.

Bob: This needs more discussion on list. The 2 drafts need to be
considered separately.


============================================
Path MTU Solution Space
draft-troan-6man-pmtu-solution-space
============================================

Ole Troan presented the slides
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-pmtu-solution-space-00

Mikael: If I say all of the above proposed solutions could be a way to go
? We're going to need everybody to do a little of everything. Some of the
ideas are nice, but what did the hardware people say about truncation ?
In summary. We should work on this. I can help, we have to figure out
what we want to do.

Ole: So we need multiple solutions.

Mikael: Yes, I want all of them.


============================================
Path MTU Hop-by-Hop Option
draft-hinden-6man-mtu-option
============================================

Bob Hinden and Gorry Fairhurst tag-teamed presenting slides.
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-minimum-path-mtu-hop-by-hop-option-00

Mikael: I think this draft didn't specify which MTU. Is it whatever
packet type MTU you want back ? I also made a point about which MTU needs
to be chosen when dealing with more interfaces. If the MRU is smaller
than the MTU, what happens ?

Bob: You only do it to the out-going interface and don't send it in big
packets. You only update the number if it's smaller than the previous
number.

Mikael: I think there should be text on this.

Gorry: I think I understand what you're saying.

Suresh: I don't understand the feedback mechanism. What happens to the
socket ?

Gorry: We were hoping that the packet too big from the destination would
be dropped.

Jen: I want to get you some data taken from RIPE Atlas. I have a
question: I couldn't find it on the draft. Are you sure that routers are
not doing load balancing, so the packets are going through a different
path ?

Bob: It's a good question.

Jen: You have to ask the vendors how they do it.

Lorenzo: You know it's not going to work at all ?

Gorry: Talk to us and tell us what you need.

Mikael channeling Peter Van Dijk: For the specific case of DNS, where a
resolver sends a query to an auth, the auth sends a response; the
resolver might issue the PTB and then throw the packet away. However, it
is the resolver that wants to know this number because it can communicate
it as EDNS bufsize. So, for both this proposal and the next one, it would
be wonderful if we could expose this number *on the receiving end* to the
application layer.


==============================================
Destination Originates Internet Control Message Protocol (ICMP) Packet
Too Big (PTB) Messages
draft-leddy-6man-truncate
==============================================

Ron Bonica presented slides
https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-packet-truncation-00

Ole: you have -2 minutes. Take one comment.

Igor Lubashev: It is calculated all the time in middle boxes now.

Ron: I tend to agree with that.

Bob: I reserved a room on Friday with the goal of discussing between 6MAN
and TSVWG. It would be useful to continue this discussion there, and
later on the list.  The meeting location and time will be announced on
both mailing lists.


==============================================
Meeting Adjourned
==============================================