IntArea WG Agenda IETF 105 - Montreal 15:20-16:50 Tuesday, July 23rd, Afternoon Session II, Duluth Chairs: Juan Carlos Zuniga (SIGFOX) Wassim Haddad (Ericsson) Note Taker: Tommy Pauly (Mirja Kühlewind as backup for first presentation) Discovering Provisioning Domain Names and Data, Tommy Pauly Proposed changes (https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/11): - Association of DHCPv6 to RA-based PvDs (main discussion) - Removal of names and localized names from PvD additional info (group agreed) - Improved security considerations (group agreed) --- Lorenzo Colliti: moving the problem to when we need to select the PVD. In a DHCPv6 only network: RA without PIO (for default route) and DHCPv6 (for address(es)). If I can't select something that does give me connectivity that's not very useful. Ted Lemon: Stateless DHCP information should also be associated with all explicite PvD Erik Kline: Applications can mix and match information. PvD gives you explicit information Suresh: I try to understand what you mean by match the prefix. Let's go into specific DHCP-PD option with a /48 and say matches a /64 PIO ? In my mind they do not match Lorenzo: what about a PIO with A=L=0 ? That can allow a configuration to have a PIO and be associated. (It is a NOP normally) Tommy: Please add comments to PR! Dave Thaler: About the registration of media type. The doc doesn't provide any argumentation for use of JSON. But contraint devices might not use that but cbor. The memo should include rationale for using only JSON. Tommy: Not clear if IoT devices would need that Paul Hoffman: Co-existence of things that does have an address assigned. If you have multiple PvDs you may have different resolvers with different views. Not clear which PVD to use. Tommy: Depends more on main PVD architecture. If you don't specify specific interfacee you get default resolver. If you select PVD, you get that resolver that is specified in there. Paul: Not clear in doc that applications need to be aware and what interactions there are. Erik: API requirements document Gorry Fairhurst: Back-off Timers MUST send at a certain time or do you mean delayed by a certain time? Tommy: Yes that might not be possible. Juan Carlos: Have you addressed all the comments from the SecDir? Tommy: Yes, we believe so IPv6 Support for Segment Routing: SRv6+, Ron Bonica --- MPLS and IPv6 flavors for segment routing; this is a proposal for another IPv6 approach. Will be shown in SPRING, this is an intro. Wanting to encode path state in each packet; programmable SR paths; leverage existing IPv6 features; minimize overhead. Strictly-routed and loosely-routed segment types exist Per-segment (send a packet to a policy enforcer) and per-path service instructions SRv6+ defines a new routing header "compressed routing header". Encodes segment identifiers, to translate into addresses. Very small routing header! Also defines new options for per segment and per service instructions Several drafts (listed in slides) requested to read. Main one to read is draft-bonica-spring-srv6-plus David Marbell: Do you see this as an evolution of SRV6? Ron: Not sure yet; can coexist, can evolve. Will work out in SPRING. Erik Kline: Is there a SID distribution protocol? Ron: Yes! There are two :) ISIS and OSPF SOCKS Protocol Version 6, Vladimir Olteanu --- Covering changes in version -07. Aligned fields are hard in SOCKS due to hostnames. Now has all aligned fields, with padding to fill out domain names that don't align. Refactored options encoding Added options to have the proxy resolve addresses on behalf of the client. Imitates gethostbyname/getaddrinfo. One use case for proxied resolution is UDP; UDP proxied packets require the remote endpoint, and the address is smaller than the hostname in some cases. Ben Schwartz: Many applications need more than just the address records, such as ESNI. This is often not compatible with proxy protocols. Vladimir: Let's talk about that, yes. Suresh: It would be good to present this work to transport area as well. Gorry: As TSVWG chair, we have noted this draft in previous meetings. We'd be happy to get slides to the group. Tommy: +1 to Ben's point, we want to be able to get ESNI through; but also if we are just asking for A and AAAA, we don't necessarily want to block. See happy eyeballs v2 RFC. Vladimir: Focused on something that is simple and addresses needs of TOR group. But can also look at other use cases. Tommy: UDP proxying efficiency doesn't really need to do DNS resolution to the client just to get a short identifier (like and address). You could also just define a mapping of "long host name" to a constant-length identifier. Guidelines and Registration Procedures for Interface Types and Tunnel, Dave Thaler --- Issue raised, to clarify that various forms are not a new registry, but just alternate formats. New section added to discuss this. Recommends to IANA about how to clarify this in the website in a conceptual fashion. Also clarified ifType vs tunnelType; added Tunnel Types to the main title. Updated registration template for tunnel types Trying to figure out principle of when you define a new type (alternate values) versus reuse a generic one. The principle is that cases like UDP generic values have specific implications on multicast that don't apply to many other UDP tunnel types. Suresh: This is really good! I raised the issue for UDP for softwire, and it's good that this is clarified. Dave: We believe all issues have been addressed. Please raise new ones if you think there are issues. Suresh: I plan to send this to IETF last call right after this week. Gorry: Do we want transport area specific review? Dave: Don't think so. We may want some OPS area input re: the yang module and MIB module, seeing if this sets a precedent. Dan Romascanu (jabber): Reviews from the TSV Area and OPS-DIR would be welcome Michelle Cotton: Re looking into tools, not sure how long that is going to take. If this document gets approved, it will still be sitting for a while potentially. The publication of the document may not need to wait on the tooling, so you may want a blurb for that.