Site Multihoming by IPv6 Intermediation WG (SHIM6) Monday, March 20, 2006 1740-1840 Afternoon Session III 1850-1950 Afternoon Session IV =============================== CHAIRS: Geoff Huston Kurtis Lindqvist AGENDA 1. Agenda Bashing, Victimization of scribe [5 minutes] The agenda is broken into 2 sections. Agenda items 2 - 6 address topics related to the current set of drafts and necessary steps to progress these documents through the WG. Agenda items 7 - 9 are a followup to the current consideration of (loosely phrased) "TE" considerations for possible extensions to Shim6 framework, and the related aspect of re-chartering this WG to study this topic. 2. Review of Document Status and WG Roadmap Chairs The question to the working group is whether to adopt draft-huitema-shim6-ingress-filtering-00 as a WG document [5 minutes] noone has read this document ** to the mailing list! 3. Review of Shim6 Protocol Specification draft-ietf-shim6-proto-03.txt (-04 to be submitted) Erik Nordmark The question to the working group following a review of the document updates is whether the WG is ready for a WG Last Call on this document. [15 minutes] 4. Review of Shim6 Failure Detection Specification draft-ietf-shim6-failure-detection-03.txt Jari Arkko Illitsch vav Beijnum The question to the working group following a review of the document updates is whether the WG is ready for a WG Last Call on this document. [10 minutes] 5. Privacy Analysis for the SHIM6 protocol draft-bagnulo-shim6-privacy-00 Marcelo Bagnulo Do the privacy issues identified in the draft need to be addressed? i.e. do we need to define some extensions to address the privacy concerns identified in the draft? [15 minutes] 6. Default Address Selection in RFC3484 draft-arifumi-ipv6-policy-dist-00.txt draft-fujisaki-dhc-addr-select-opt-01.txt Arifumi Matsumoto This draft raises some issues about default address selection of RFC 3484 and proposes some solutions towards them. (This is an informational briefing to the WG.) [10 minutes] 7. Report on IAB BOFs on multi-homing Dave Meyer [10 minutes] 8. Extended Shim6 Design for ID/loc split and Traffic Engineering draft-nordmark-shim6-esd-00.txt Erik Nordmark [35 minutes] 9. WG Discussion on Re-Chartering Chairs [15 minutes] Recommended Reading: a) active wg documents to be discussed at the meeting draft-ietf-shim6-proto-03 draft-ietf-shim6-failure-detection-03 b) other documents whose status will be considered draft-huitema-shim6-ingress-filtering-00.txt draft-bagnulo-shim6-privacy-00 draft-arifumi-ipv6-policy-dist-00.txt draft-fujisaki-dhc-addr-select-opt-01.txt draft-nordmark-shim6-esd-00a.txt c) other shim6 documents that may be referred to draft-ietf-shim6-arch-00.txt draft-iietf-shim6-applicability-00.txt draft-ietf-shim6-applicability-00.txt NOTES ===== Notes by Nevil Brownlee Intro by Kurt Agenda bashing by Geoff Overview: Doc Status, Road Map: 3 core docs, IP-stack-centric view of shim6 one i-d with ADs, waiting on other two. What do we need to do to complete these base specs? IAB BOF report on multihoming; site-based policies, TE shim6 may want to know details of transport(s) WG next steps Ingress filtering draft (Christian Huitema). Should that be a WG doc? It is part of the wg charter. No-one has read it. Take to mailing list. Part I: Erik Nordmark: Core Spec draft, -04 changes 03 to 04. Mainly editorial. no IPv6 NATs now an explicit assumption. text ordering reworked Locator pereference options: requirement that any with element length >3 must have flags, priority, .. retrans rules for I2bis (ocpied from I2 rules) fixed security hole where single message could cause CT (peer) to be updated. Now require a 3way handshake. Context Recovery 02 to 03 Context recovery redone expanded context tag, 32 to 47 bits specified how context recovery and forked contexts work together picked initial retransmit times fir I1 and I2, 4s. binary exp backoff. Require R1/R2bus verifiers be usable for some minimum time, initiator knows how long it is safe to retransmit I2 before going back to sending I1. Message type codes 0-63 don't generate R1bis messsages, 64-127 will lots of editorial changes Is it now ready for last call? Comments: Jim Bound: very political. Thinks its OK, but we (or someone) should look at other options. Geoff response - shim6 follows multi6, it's not the only way. Jim: this is a lot of work to implement, could break things, doesn't see customer pressure for it. Geoff: Erik isn't saying "put it into production s/w" The WG question is "is this draft ready for last call?" Jim: Yes. Architecturally its a good thing. Thomas Narten: not trying to push shim6 as 'the' approach. Who do we want to implement this? Geoff: WIDE Kame project is one example. But not ready yet for companies to cimmit to making production code. Thomas: Expermental? Plus app stmt saying "will eventually hit standards track" Goal is to have it production-ready in, say, 2 years? Dave Thaler: what's relationship betw shim6 / mobileIP6 / hip ? supports 'experimental' Jari Akko: need to look at this Dave: want community consensus on relationship between these. Should people implement all three? Kurt: chairs/ADs should try to make a doc on this. Dave will co-author. Brian Carpenter: reminder about *proposed* standards Marcelo Bagnulo: mobileIP and HIP interactions. What do you want to do? why would you use shim and hip together? Dave: want to know which scenarious are likely Jari: need to know how this works with exising stuff, not neccessary with new Margaret Waserman: Have a stack doing shim6, need to understand its interactions with others. Which one turns off what?? Group is chartered to make a stds track doc, and started with 32 variations! Pekka Nikkander: draft on hip and mobileip exists pkt formagt for shim6 and hip is roughly the same, could implement them in same s/w module. Erik: can you run them on the same host? Yes. Are there cases when you need to use both together?? Charter addresses optimisations. Doc handwaves on this. Jari Arko: Exploration redesign of exploration protocol -03 being considered for last call issues: termination states, needs more detail Erik: it doesn't, by itself, terminate Have exp terminate at time we throw away the context; fate sharing makes things simpler Timers: Erik: comparison with TCP timer settings. Don't know whether probe packets will work, be aggressive, but not too aggressive Geoff: what is sensible limit to exponential backoff? Deprecated addresses (Marcelo) draft recoimmends moving away from deprecated addresses. Need to update the draft, and get more reviews John Loughney: has read draft, will senmd comments Geoff: will proceed to WG Last Call after next rev Marcelo: Privacy Analysis Scenarios ULID-pair conext, estab exchange Packets with the payload header Update messages keepalive & probe msgs Draft doesn;t go into solution space Do we care about privacy? Erik: haven't written down: be careful with rfc 3041 temprary addresses, etc. Need to write these down. Hiding doesn;t seem to achieve much. Dave: never combine temp and non-temp address, 3041bis ?? ?: 3041bis currently stalled Geoff: does anyone think that this should be part of the shim6 applicability doc? Agreed to fold that into the applicability doc. Extensions to 3484 are currently with ADs rather than this WG. They will decide what to do about further updates/revisions. Arifumi Matsumoto: 3484 & shim initial contact must succeed if we use deferred shim context setup. if dest host isn't shim-enabled, you can;t reach it! initial contact failure reasons "you can't implement a large SO with ULA" Address selection policy forinitial contact Redundancy for initial contact - an app should cycle dst & src TE for initial contact 3484 is useable, not enough for redundancy and TE No discussion Dave Meyer Notes from Operator Workshops NANOG35 end-system complexity, DNS latency, inbound TE current multihoming is site based, not host based. This is a big change. hosts and routers may not be managed by same group of people IPv6 routing and addressing architectures still an open problem APRICOT06 Will continue the series, RIPE 52 in Turkey Scot Lybrand: present this at NANOG? yes Jim Bound: This is good, want to see more. need to get managters along to those meetings too! ?: go one-by-one to operators. Part II: Erik: Is shim6 a brick wall, or part of an interesting architecture? What's missing? We need to determine whether shin6 could reduce pressure for IPv6 PI space ID-locator separation Unreachable ULID format - only know how to do scalable lookups from a hierarchically allocated 'name' Could do lookups in DNS (as an example) ULIDs could be in a reverse lookup, e.g. ip6.arpa get back SRV records Traffic Engineering Static and Dynamic TE Locator rewriting by routers Jim Bound: Hasn't read draft yet, but - CGA isn't happening in the market, it has IPR problems, it breaks IPsec, ... Erik agrees it could break e2e encryption. Receiver will see the IPv6 packet. Jim understands Leslie: if path changes, might inject different addresses - will shim6 switch back? would end nodes have to know what the routers would inject?? No, user app would never see the shim6 addresses IPv4 addresses as locators Conclusion: non-routabloe ULIDs doesn't place any new reqs on shim6 mechanism. If we want to use router rewriting, define it now. Dave: remarks about hip and CGA. hip has many of the same issues. (lots of) convergence is good. Jim: Now wants to go to Last Call for shim6. Maybe we should just use identifiers (rather than addresses)? That would make shim same as hip. Erik likes having both adress-based and identity-based (?) IDs Geoff: recycling names is expensive, uniqueness is not cheap. Pekka: IPv4 - was IPv4 a header extension? Erik: not decided, no work done yet. Tom Henderson: hip research group has looked at what happens if you use non-routable identifiers. Ongoing. Geoff: we will explore these extensions Erik talked about. Request WG to start writing some drafts about an API.