6MAN Working Group - IETF 85, Atlanta Monday, Morning Session I 0900-1130, Room Name: Salon D Chairs: Bob Hinden, Ole Troan Minutes: Hassan Zaheer, Bill VerSteeg Jabber: Joel Jaeggli Slides can be found at: https://datatracker.ietf.org/meeting/85/materials.html ====================================== Agenda Introduction, Agenda Bashing, Document Status, Chairs, 15 min. IESG comments on the UDP zero documents, Magnus Westerlund, 15 min. draft-ietf-6man-udpchecksums-04 draft-ietf-6man-udpzero-06 IESG comments on Representing IPv6 Zone Identifiers in Uniform Resource Identifiers, Brian Carpenter, 15 min. draft-ietf-6man-uri-zoneid-04 WGLC follow up. Distributing Address Selection Policy using DHCPv6, Arifumi Matsumoto, 15 min. draft-ietf-6man-addr-select-opt-06 Transmission of IPv6 Extension Headers, Brian Carpenter / Sheng Jiang, 15 min. draft-carpenter-6man-ext-transmit-00 Efficiency aware IPv6 Neighbor Discovery Optimizations, Samita Chakrabarti, 20 min. draft-chakrabarti-nordmark-6man-efficient-nd-00 IPv6 RA Options for Multiple Interface Next Hop Routes, Behcet Sarikaya, 10 min. draft-sarikaya-mif-6man-ra-route-01, IPv6 RA Options for Translation Multicast Prefixes, Behcet Sarikaya, 10 min. draft-sarikaya-softwire-6man-raoptions-00 Corresponding Auto Names for IPv6 Addresses, Hiroshi Kitamura, 10 min. draft-kitamura-ipv6-auto-name-03 Prefix Delegation extension to Neighbor Discovery protocol, Alexandru Petrescu, 10 min. draft-kaiser-nd-pd-00 ============ Introduction, Agenda Bashing, Document Status, Chairs, 15 min. The chairs went over the agenda and the wg document status. Slides at http://www.ietf.org/proceedings/85/slides/slides-85-6man-4.pdf ============ IESG comments on the UDP zero documents, Magnus Westerlund, 15 min. draft-ietf-6man-udpchecksums-04 draft-ietf-6man-udpzero-06 Presentation from the slides No questions from the mic. Working group agreed with proposed changes. New versions of each draft will be needed to resolve the IESG issues. ACTION: Will need new w.g. last call, and then resubmit to IESG (for IETF last call). ============ IESG comments on Representing IPv6 Zone Identifiers in Uniform Resource Identifiers, Brian Carpenter, 15 min. draft-ietf-6man-uri-zoneid-04 Presentation from the slide From the mic (scribe did not get name)- Apps area review of this document upcoming Dave Thaler - agrees with document - typo in document on ABNF line, sent note to the authors Brian - clarification on the syntax of the ABNF, document is correct but slide is briefer Dave Thaler - URIs not used in just web browsing - liberal vs conservative in quoting URIs? Note: Brian will also present at the App area meeting (running at the same time as 6man). ============ WGLC follow up. Distributing Address Selection Policy using DHCPv6, Arifumi Matsumoto, 15 min. draft-ietf-6man-addr-select-opt-06 Presentation from the slides Chairs - no need for a new WGLC, just needs acks from the comments - need to have new draft quickly, then can be advanced to the IESG. ============ Transmission of IPv6 Extension Headers, Brian Carpenter / Sheng Jiang, 15 min. draft-carpenter-6man-ext-transmit-00 Dave Thaler from the mic- please clarify the wording on the bottom of slide 7. Two ways to interpret the words. Either "Must Drop" or "configurable defaults". Needs clarification Lorenzo Colitti -What people want to do is not look at extension headers, but look at upper layer headers. Need to walk the chain and find the end of the chain Lorenzo- draft needs to go further - the node MUST recognize all fields in all extension headers Shuresh Krishnan - future extension headers also need to be considered Michael Richardson - comes down to the word "valid" - wrong word. Should be "all syntactically correct" Brian - on to slide 8 Dave Thaler - either create a separate registry or augment the existing IANA registries Lorenzo - previous comment was incorrect - the confused names space is worse, because it is meaningless Brian - this is correct, firewalls are broken if they need to look up these values in real time. Can't ask IANA in real time per packet Lorenzo - won't work operationally Brian - chance for breakage because walking the headers Lorenzo- Can we multiplex it with another option. Assume additional resources are available. Do not ask IANA for every packets. Can we cap the existing methods? Brian - we can discuss this Floor - we tried this and it failed Lorenzo - can we try again Bob Hinden - making a list at IANA is a good idea - higher level problem is introducing a new transport protocol. Boxes that look for this stuff do not know about the new extensions. The problem is broader. Brian - not growing quickly because they do not work well. Stateless firewalling is difficult due to walking through lots of headers Shuresh Krishnan - not very difficult to do do extension header - just find header type and skip several bytes. Hop by hop is much more difficult. Lorenzo - opens a can of worms - this group is tasked with evaluating whether any changes need to made to the spec to make it more deployable. Need to think about what packet processing is done on the network. Any bytes past a certain point in a packet will not be processed by today's middleboxes. If an operator can only qualify a single software release per year, making code changes to handle new options is tough. Maybe a pointer to the upper-layer header? Brian - there is a draft that does exactly that, not much uptake. Fernando Gont- hop by hop options are more expensive. What is the difference between a hop-by-hop and multiple extension headers. Is not a simple trade off. Comments on slide 10 Lorenzo - need to make this easy for existing boxes Suresh - this work needs to be done Brian - feedback on the list, need another version of the draft Chairs - Conclusion is that the working group is interested in this draft, but it needs more discussion. ============ Efficiency aware IPv6 Neighbor Discovery Optimizations, Samita Chakrabarti, 20 min. draft-chakrabarti-nordmark-6man-efficient-nd-00 Erik Nordmark did the presentation remotely using Meetecho. [Note that audio was a bit garbled and difficult to follow for the first part of this talk] No comments/questions from the mic Chairs - Is there interest in working on this? Hum - chairs indicate weak support, will take it up on mailing list ============ IPv6 RA Options for Multiple Interface Next Hop Routes, Behcet Sarikaya, 10 min. draft-sarikaya-mif-6man-ra-route-01, Presenting the slides Slide 3 Dave Thaler - need to motivate the "why" prior to describing the mechanisms. Wants to understand why preference value is not sufficient. Need to see what has changed to motivate this Behcet - many more mulit-node element on interent Dave - existing RFC 4191 methods work Ole Tran (from the mic) - +1 to what Dave said then () Lorenzo - the only time you need the next hop is when you have one router redirect in line. This is brittle, because it does not share fate. The new router should advertise himself. We need a provisioning method to tell the first hop router what prefixes it is authoritative for. Behcet - please put those comments into the list Alex Petrescu - first comment - two other drafts using route advertisement, will send to list - second comment - which scenario is addressed by this draft is a valid question - agrees on RFC4191 comments, but there may be a need for router to router exchange in addition to router to host ============ IPv6 RA Options for Translation Multicast Prefixes, Behcet Sarikaya, 10 min. draft-sarikaya-softwire-6man-raoptions-00 Presenting the slides Dave Thaler - this is a very simple topology. If you extend this to the more general case with multiple routers/interfaces, what is the scope of the addressing? Behcet - according to the existing drafts, SSM single value and ASM can have multiple values Dave - if a given SIP gives the same answer to every customer, Dave thinks that this is the wrong way to do it. Use DHCP instead of this method Behcet - there was a DHCP proposal, but it did not move forward. Chairs - There doesn't appear to be any support for this work in the w.g. ============ Corresponding Auto Names for IPv6 Addresses, Hiroshi Kitamura, 10 min. draft-kitamura-ipv6-auto-name-03 Presenting the slides Eric Klein Slide 10 - in the context of operators and people on hosts, this is useful. From the network, the mapping needs to be precise in the system-wide context if it is to be useful. Is the interface ID from the host perspective? Hiroshi - asks for additional detail Eric - It should be the result of the ifnameIndex call. How is the interface index mapped? Hiroshi - special meaning for 0-9, see the draft Eric - zero is generally reserved for "any" interface, probably should use that for DNS. You only need as many bits for the NGI part to make it unique Eric - Is there a reason for using a different interface? Hoiroshi- ID shows that 0-9 are manual, with the rest programatic Eric - need to be able to iterate through the interface table and map into the names . Maintaining other mappings may be to complicated. DNS is separate, should be the global name/interface Hiroshi - please send comments to the list Chairs - is there support for this work in the WG? - one hand, not very much support ============ Prefix Delegation extension to Neighbor Discovery protocol, Alexandru Petrescu, 10 min. draft-kaiser-nd-pd-00 Presenting the slides Slide 3 Michael Richardson - do the vehicles trust/know each other? Alex- security is . . . . Michael - is about relationships, not just security Alex- only the IV has a trust relationship with the operator, and can trust any nearby vehicle. A Hot-spot like model. Currently Thomas Narten- We need to understand the trust model. At a stoplight with 5 cars, what actually happens. This is such more important than the bits on the wire Alex - traffic jam or stop light, finding a beacon vehicle could be useful, or malicious. Lorenzo - have you clarified why V6 DHCP variants are not sufficient? Alex - next slide covers deltas from DHCP-PD Lorenzo - is there a way to do DHCPV6 PD with rapid commit, would that work better Alex - will look at it. Not clear where the server should sit, and the relationship between John xxx - similar discussion in 2002. "this should work like DHCP". We have a solution, not sure why we need to do it again. No relays in prefix delegation. Harder problem to solve than the bits layout. Alex- since 2002, people keep suggesting this, so there may be a need. Particularly use cases make DHCP unnecessary burden. Machine class devices require as few protocols as possible. John - how is a new state machine better than the DHCP state machine – they both add state and messages. Gang Chen - consider the case of a multiple routers fan outs with multiple prefixes? Alex - Have not considered it yet xxx- DHCP it is legal to use rapid commit. Thomas - this is looking at the problem at the wrong level. Need to consider the questions of how to do prefix delegation in an ad-hoc nature. This is a less managed environment Alex - will consider the trust relationships Thomas - what is the overall architecture - it is missing Michael Richardson - as long as you add security, you will be over 2 messages anyway. Go ahead and send lots of packets, may not have much processing power. Also does not think there is a prefix delegation problem, but there are routing problems. Need use cases. Chairs - need to wrap up - there is an interesting technical problem, but need to consider higher level issues, but talking about the bits on the wire is premature. ========================= Meeting Adjourned =========================