IETF 77, 6MAN Working Group Chairs: Robert Hinden & Brian Haberman * Agenda bashing - DHCPv6 Route Option removed from agenda * Draft status - IANA Routing Header : IESG Evaluation (Jari Arkko holds work token) - IPv6 Subnet Model : IESG Evaluation (DISCUSS on on-link assumptions) - Canonical IPv6 Address Format : IESG Review - Overlapping Fragments : published as RFC 5722 * Node Requirements Update - Presenter : Thomas Narten - New version recently posted - Clarify that document is an applicability statement - IP-over-foo documents are recommendations - SEND now a MAY - Privacy extensions section needs further review - MIPv6 Route Optimization reduced to a SHOULD - NEMO not discussed Comment (Dave Thaler) - AH/ESP level of support conflicts in RFCs Response (Narten) - The language matches the discussion/decisions that IPsec is a MUST Comment (Hui Deng) - ESP is mandatory, authentication optional if you do AH Response (Narten) - Remove cut-and-paste text and re-word Comment (Hinden) - Summarization can make it worse Comment (Thaler) - Text in current IPsec RFCs is cleaner and more consistent - Still inappropriate to mandate IKEv2 Comment (Behcet Sarikaya) - Why a MUST for IPsec? Not appropriate for resource constrained nodes Response (Narten) - Vendors can always drop out parts of spec, which means the user must beware * Moving DNS Option for Rtr. Adv. (RFC 5006) to Standards Track - Presenter : Dan Wing - Discussion in v6ops trends towards the work being useful and interesting - Approach works, causes no harm, and is useful without DHCPv6 Comment (Narten) - Is this option sufficient or is the search path needed? Where do we stop? What is useful? Comment (Thaler) - Is the DNS address sufficient? How does this work with the Container Option for RAs? Comment (Ralph Droms) - If this is an experiment, would like to know if the Lifetime is useful. At this point the Container Option is deferred. Comment (Brian Carpenter) - Useful approach to support plug-and-play Comment (Jari Arkko) - NDP covers everything a host needs. This option is implemented and recommend it be more widely used rather than creating something new. Comment (Tony Hain) - This option must be done, but don't exclude discussion of generic container option. Comment (Carpenter) - Is timing of work an issue? Response (Hain) - Yes, this should have been done five years ago. Simple RA-based networks should be able to stand alone. Comment (Chris Morrow) - Small networks without DHCPv6 are fine, but don't add other random DHCP information to RAs. Comment (Thaler) - Agrees with un-managed networks. However, set of hosts has chosen disjoint solutions (RFC 5006 or stateless DHCP), so network providers may have to support both. Comment (James Woodyatt) - Discussed some operational experience with RFC 5006. RA approach makes re-configuration easier. Feels there may need to be some revisions on way to standards track. Comment (Droms) - Keep discussion of Container Option and RFC 5006 separate in order to keep focus and effort moving forward. Comment (Erik Nordmark) - Need to add security to block ports from sending rogue DNS server information Comment (Hinden) - Good to mention in Node Requirements update. Appears to be consensus to begin work on moving RFC 5006 to Standards Track. Comment (Narten) - How do we merge/sort information you get from DHCP and RA. Comment (Arkko) - More work in security considerations needed. * UDP Zero Checksum - Presenter : Gorry Fairhurst - RFC 2460 mandates UDP checksum calculation. - IPv6 relies on transport checksum for src/dst addr/port verification. - In tunnels, UDP checksum provides protection, but many tunnel applications rely on inner tunneled packet header. - IPv4 allows UDP zero checksum and implementers want the same in IPv6. - Non-trivial issues and pitfalls documented in the draft. - If zero checksum is wanted: - Off by default - No fragmentation - Integrity checks needed - No nested tunnels Comment (Narten) - Who does fragmentation? Response (Magnus Wusterland) - Ingress might fragment, but should not allow in the tunnel, i.e., don't add fragmentation header. Comment (Narten) - How do you prevent nested tunnels? Comment (Arkko) - Should be able to allow nested tunnels as long as something has a checksum. Needs more work. - Authors believe draft should be published regardless of outcome. Wants draft to be adopted by WG. Comment (Brian Haberman) - Unclear if this work should be done in Transport Area or 6MAN. IPNGWG/IPv6 WG had transport work when it handled all IPv6 work in IETF. Response (Arkko) - Needs input from transport and other areas, but 6MAN should be primary home. Comment (Hinden) - This is the 3rd or 4th meeting where this issue has been presented in 6MAN. Comment (Wusterland) - This work impacts core IPv6 specification, so 6MAN is a reasonable place. Comment (Marshall Eubanks) - LISP in Cisco IOS will probably have UDP over IPv6 with zero checksum. Comment (Hinden) - 6MAN will adopt this work and move it forward. Comment (Thaler) - Does this work need a charter milestone? A milestone on making a decision since other work is blocked. Response (Arkko) - Both milestones are needed. * ECMP with the IPv6 Flow Label - Presenter : Brian Carpenter - Equal-Cost Multi-Path spreads traffic, roughly equally, over modulo(N) paths based on a hash of header fields. - Problems arise with tunneled traffic where the header fields are all the same. - For Foo-in-IPv6 tunnels, set a flow label in the encapsulating header. - For IP-in-IPv6 it is still based on the 5-tuple of the inner packet. - Routers hashing for ECMP add the flow label to the hash function. - Fully conforms with RFC 3697. - Comment (Thaler) - IP-in-IPv6 means either version? - Response (Carpenter) - Yes. If IPv6-in-IPv6 tunnel, propagate the flow label. - Comment (Haberman) - Similar handling with encrypted packets? - Response (Shane Amante) - Various scenarios are not fined grained enough and port information is needed. - Comment (Tony Hain) - For many cases of encrypted packets, you don't want to expose the inner fields. Leads to information leaking. Has objection to MAY. - Comment (Thaler) - I was talking about TEP. If the inner packet has a non-zero flow label, MAY base the hash on it. - Comment (Erik Nordmark) - I don't want to punt on encrypted flows, probably want to use the SPI. - Broad support in the working group to work on this effort. * IPv6 Flow Label Specification Update - Presenter : Brian Carpenter - Existing Flow Label spec (RFC 3697) poses difficulties for many use cases: 1. QoS routing - ingress router encodes useful information in the flow label 2. Pseudo-random assignments - Proposing to update RFC 3697, use most-significant bit of flow label to distinguish between the two above types of use. - Include rules for backwards compatibility. - Don't export local semantics out of administrative domain Comment (Hinden) - What if someone uses the flow label for something with the MSB set? Response (Carpenter) - Little breakage given the lack of use today. - Alternatively, define a DSCP value that takes the place of the MSB approach. Comment (Hinden) - Is anyone using the DSCP? Response (Lorenzo Colitti) - Yes! - Is the basic idea useful? - Is the DSCP alternative better? - Should there be detailed rules for domain boundary? Comment (Narten) - Flow label should be renamed to "Nuisance Bits" and we should leave them alone until there is a compelling use case. Comment (Hain) - Idea is not useful. Taking DSCP bits is not a better option. There needs to be a signaling prototocol for the flow label values in order to use it effectively. Comment (Remi Despres) - We need to permit new uses of the flow label. The DSCP approach is not better. Comment (Amante) - I support Thomas' comment. Don't overload flow label for application uses. Comment (Tina Tsou) - We have a use-case for a 20-bit flow label. Comment (Narten) - Over a 10-year history, proposals have come and gone. Define the problem and determine whether it is compelling. Comment (Chris Donley) - Flow label can be very useful for operators. Flow label could be put to better use. Comment (Hinden) - No clear consensus to work on this. Comment (Carpenter) - We should examine use cases. * IPv6 Flow Label for Transport Protocol and Port Signaling - Presenter : Chris Donley - Proposes to use the flow label to encode transport protocol and 10-bits of port information - Protocol and port information obscured by extension headers and precludes QoS and special handling in low-power home gateways. Comment (Hinden) - Who sets these bits? Response (Donley) - Home gateway/CPE. Comment (Amante) - Very bad idea. Hard to believe that residential gateways can't look at hext header. Need that level of functionality to hash protocol/port information. Comment (Arkko) - Useful for TCP port 80 applications. Comment (Chris Morrow) - Home gateways can already handle extension headers and are getting more capable anyway. Response (Donley) - We are seeing DS-Lite on low-end devices Comment (Hain) - Really bad idea. Use RSVP to signal rather than pre-define the flow label. * Unique IPv4-Mapped Addresses - Presenter : Dave Thaler - ::FFFF:w.x.y.z format allows single listening socket for both IPv4 and IPv6. - But, non-global IPv4 addresses are ambiguous, don't work with multi-homed hosts. - As IPv4 address depletion increases, more use of net 10 addresses makes the problem worse. - IPv6 has a scope ID. Incentivize the agnostic API by giving users the advantage of getting the scope ID for free. - RFC 3484 requires IPv4-mapped addresses to be treated as globals. - Make the address unambiguous by embedding the network ID into the address itself. - Associate the v4-mapped range with a well-known prefix and add a 40-bit number for the network ID (same as ULA). - Impact on API getaddrinfo() and sockopt. Comment (Nordmark) - Is this for local meaning only? Response (Thaler) - This is a private address. Same use as ULA space. Comment (Nordmark) - Scope ID only used in link-locals. Forces implementations to be realm aware. Comment (Narten) - The global ID must make sense in context. Fundamentally hard problem. How confident are you that this can be made to work? Comment (Unknown) - Are mapped addresses permitted in all situations? Comment (Erik Klein) - How are global IDs exchanged? Response (Thaler) - By other means. No worse than site-local. Comment (Deng) - Worry about destination address selection first, consider source address later. Response (Thaler) - RFC 3484 says for each destination, sort on source address. Comment (Nordmark) - With multiple interfaces, how many realms are we connected to? Response (Thaler) - Assume the worst. * Using 127-bit Prefixes on Inter-Router Links - Presenter : Yoshinobu Matsuzki - Concern over exhausting neighbor cache entries on links using 64-bit prefixes. Comment (Joel Halpern) - Ping-pong issue is an implementation bug. Neighbor cache is an issue for any link. Response (Matsuzki) - Agreed. - Using 127-bit prefixes works today and subnet-router anycast not widely implemented. - Recommendation that inter-router links MAY be assigned /127 prefixes. Comment (Narten) - Fine with /127 recommendation. Does this update RFC 4291? What changes are needed in other specifications? Response (Matsuzki) - Subnet-router anycast MUST be disabled for the prefix. Comment (Carpenter) - Informational document cannot update a standards-track one. Must also state whether the local/global bit has normal significance. Comment (Unknown) - Many operators use /126 by choice, but RFCs say /127 is a bad idea. Is /126 a reasonable compromise? Response (Matsuzki) - No broadcast address in IPv6. Comment (Bush) - Be careful with the language. Operators allocate a /64, but number as a /127. Comemnt (Nordmark) - In practice, this is not a problem. The subnet-anycast doesn't apply. Comment (Halpern) - Then this is a point-to-point link. Comment (Nordmark) - How to do neighbor discovery is a problem for the reader. Comment (Narten) - Is this on links with more than 2 nodes? Comment (Carpenter) - This seems to be a good idea. Needs to be written as a standards-track document. Comment (Bush) - Most links are Ethernet, but used to connect two devices. So /127 works fine. Comment (Colitti) - We don't want this to apply to hosts. Comment (Hinden) - Word updats to other specifications carefully. Comment (James Woodyatt) - Residential CPE is both host and router, are they obligated? Comment (Narten) - If you want to use SLAAC, you need a /64. Comment (Colitti) - RFC 2460 defines a host as something that is not a router. Comment (Narten) - Host/router classification is per interface... Comment (Haberman) - Authors need to post new draft with revised wording and then the chairs will poll the mailing list for adoption. * Address Selection - Presenter : Arifumi Matsumoto - 4 drafts in progress - In solution space, investigating pros/cons of simultaneous connection approach. - Host tries all pairs of src/dst addresses in a short period. - Decreases timeouts. - Adds load to network. - Policy needed to prevent exposure of internal-use addresses. - Policy distribution via either normal or aggressive host/DHCP interaction - Aggressive stack leverages SHIM6 experience. Comment (Deng) - Most phones don't use DHCP, configuration comes via XML. Comment (Carpenter) - SHIM6 does not have much deployment experience. Aggressive mode does reduce recovery time, but not as much as one would expect. Comment (Hain) - No reason to wait for the aggressive stack, more work is needed on it. Is DHC the right place to follow-on? Maybe XML is better. Comment (Haberman) - General working model is that DHC WG acts as reviewer/approver of DHCP work done in other WGs. We should keep discussing this on the mailing list. Comment (Hain) - Design team needs one more pass of discussion on their list. Comemnt (Hinden) - Don't wait to move this discussion to the main list until the next meeting. * An IPv6 Option for RPL - Presenter : Jonathan Hui - ROLL WG looking for a routing protocol for lossy links. - RPL Distance Vector routing for IPV6. - Slow proactive approach with some inconsistencies during propagation. Piggyback routing inforamation in data plane to speed up reaction. - Uses an IPv6 Hop-by-hop to carry TLV. Only used within RPL domain. Edge router MUST remove it, MAY add it on ingress. Comment (Nordmark) - Upper bound on size? Response (Hui) - Not yet. May carry source route information. Comment (Nordmark) - Introduces Path MTU issues since the original sender does not know bytes are added. Architectural complexity unless a well-defined upper-bound is available. Comment (Narten) - Is the option only for use by the routing protocol? Who adds them? Response (Hui) - Normal packets include this option, RPL edge routers need to know where to put the bits. Comment (Narten) - Would like to know how the bits are being used before recommending where to put them. Response (JP Vasseur) - Discuss details on the mailing list. Basic content known, but may add some later. Comment (Narten) - Please flesh it out in the draft. Comment (Hinden) - At some point there needs to be a proposal on the option. There has been some objection to hop-by-hop options. Response (Vasseur) - We have one TLV defined already. To save time, we wanted to run this by the group before defining everything. Comment (Narten) - This may be a good use of hop-by-hop. Comment (Nordmark) - Please address the Path MTU issue. - What is the architecturally correct place? Seems like hop-by-hop options, so there is little to decide. Comment (Nordmark) - MPLS sits in front of IPv6... * Vendor-specific Option in Neighbor Discovery - presenter : Suresh Krishnan - Defining an approach that allows other SDOs to deploy specialized extensions. - More than the experimental bits. - No reason for global standardization. - Vendor-specific options, enterprise ID to identify the vendor or SDO. - Only for small-scale trials, minor enhancements, prior to bringing to IETF. - Conform with SEND. - Unknown options SHOULD be ignored. Comment (Nordmark) - Good fundraiser for IANA. Managed non-interoperability is a good reason to use vendor-specific options. Not a good idea in a generic protocol. Comment (Unknown) - Terrible idea. Once it is there, they will use it for everything and never come to the IETF for standardization. Comment (Narten) - What constitutes "minor enhancement"? Between their own devices? Any examples where it is needed today? Response (Krishnan) - Broken link models that cannot be fixed easily. Need for that SDO to do something. Such as RFC 4562. Comment (Hinden) - This type of approach requires some thought. Comment (Hain) - Need something in this space, but this may not be the right approach. Comment (Nordmark) - Moving to SLAAC is an architectural change. If we need to add something to NDP, let's discuss that. Comment (Narten) - Developing the fixes right in the right place is a better idea than piecemeal somewhere else. * RS Marking for the BBF - Presenter : Suresh Krishnan - Multiple subscribers on the edge router, BNG does not know which premises it came from. - Some objections to line identifying option in DHCPv6. - BBF does not like tunneling approaches. - DSLAM does not have an IP stack. - No IP address on the access node, no way to tunnel downstream. - Need something to make SLAAC work without a line ID approach. - Need to reconcile IETF and BBF objections. Comment (Nordmark) - How could these devices not have an IP stack? They already do a lot of header manipulation. Use of unspecified address might solve their problems. Response (Krishnan) - No tunneling downstream. Comment (Nordmark) - Nothing special needed downstream. Comment (Narten) - Need a design team to get this done correctly.