[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SHIM6 WG meeting notes from IETF 63
This is the draft of the notes of the SHIM6 meeting at IETF 63.
Thanks to Spencer for preparing these notes.
Are there any comments on these notes as a record of our meeting?
Thanks,
Kurtis & Geoff
-------------------------------------------------------------------------
Site multi-homing by IPv6 Intermediation WG (shim6)
Tuesday, August 2 at 0900-1000
Wednesday, August 3 at 0900-1000
================================
CHAIRS: Geoff Huston <gih@apnic.net>
Kurtis Lindqvist <kurtis@kurtis.pp.se>
Notes: Spencer Dawkins <spencer@mcsr-labs.org>
SUMMARY
Initial WG meeting. There are five areas of design activity namely
protocol, triggers, crypto-locator use, architecture and applicability.
Initial drafts in these areas are based on the concluding design team
work in the Multi6 Working Group
The current status on each of these areas was presented to the Working
Group for review.
Next steps will be based on further refinement of five working group
documents, using lead authors / editors assigned to each draft.
ACTIONS
* Pekka Nikkander, John Loughney and Christian Huitema
to prepare some initial ideas (slide pack / draft) on a bi-directional
SHIM / ULP API that would include the ability for the ULP to
obtain/share locator pair path info and then express a locator pair
preference to the SHIM (i.e. keep the notion of binding sessions at the
transport level but allow ULP signaling to include Loc Pair
preferences to be expressed) in addition to sending the SHIM the
trigger / heartbeat information associated with the current locator
pair.
NOTES
1. Agenda Bashing
- A very tight agenda.
- no changes proposed.
- Noted that the SHIM6 Charter discussion has already happened...
2. Review of status and proposed work areas
Overview
Kurtis Lindqvist
MULTI6 drafts moving to SHIM6 (with very few changes).
- Charter is very aggressive.
- A lot of questions are going to pop up as we work on a protocol,
including consideration of state management, identifier
characteristics, locator pair detection, etc.
Architecture
document: draft-ietf-shim6-arch-00.txt
Geoff Huston
- MULTI6 architecture draft is in RFC Editor Queue now, this is trying
to be a taxonomy as well (what layer, where identifiers are
rewritten, etc.)
- Includes a discussion of identities (ephemeral, persistent, etc.)
and implications.
- Includes a list of things that need to happen in a protocol that
does SHIM6 - how do you set up session state? how do you know to
re-home? what is Identity Equivalence? How do you select locators?
How do you remove state?
Aaron Falk: is this restoration and repair, or multi-homing? Open
question, but this is unicast, not multicast, so assuming
alternate paths are idle at session layer.
Jason Shiller: has to take into account more than just restoration
and repair - we can do load balancing in IPv4 today, for example.
Need to get the basics right first, though. There is discussion
about traffic engineering, but we'll need to do more.
- Initial draft, is incomplete - add equivalent state and design
tradeoffs, at a minimum.
- SHIM6 is in IP layer, and is actually below things like
fragmentation/reassembly, AH/ESP, etc.
- SHIM6 uses "the first" locator as the identifier, but can map other
locators to the same identifier - identifiers should be referable.
- Need more text on maintaining state in this draft. At IP level, we
don't have all the information that would be available at transport
or at application levels.
- Routing information isn't in hosts today - do site exit routers need
to signal hosts?
- Lots of possible triggers - what triggers are valid?
- Vertical signaling so you know when you can release state
information?
- Need to make decisions about dynamic locator sets - this would
affect a lot.
- Are there "distinguished locators" you always use to get a session
up?
- Is this purely IP datagrams?
- Next steps - review SHIM6 contributions, solicit explicit answers
from document editors, but this draft will be active for a while.
Protocol
document: draft-ietf-shim6-l3shim-00.txt
draft-ietf-shim6-functional-dec-00.txt
Erik Nordmark
- We will not have a distinct namespace for identifiers.
- We will not assume that a single FQDN is a single host (could be a
multi-host service) - we'll try multiple initial locators until one
works. Telnet does this today, so it's at least a plausible starting
point.
- Make sure we minimize failure impact during session initialization.
- Don't force every connection to set up SHIM6 state.
- Context establishment is a four-packet exchange - looks a lot like
HIP exchange.
- Include DOS protection on first packet received.
- Since these were MULTI6 drafts, changes have been editorial.
- Several open issues - packet formats (including demultiplexing),
state management, packet formats for control protocol, APIs for
advice, path maintenance and exploration protocol), etc.
- Pick one possible starting point and work out the details.
Alternative would be using 8-byte extension header for data packets
after failover.
Pekka Savola - Do we need functional decomposition document? Seems
redundant...
Jim Bound - If we change the upper layer identifier, we break TCP.
A lot of this stuff is already in SCTP now. Are we going to stay
compatible with the old APIs? SCTP is in most of our stacks now.
Are we going to dynamically change the ULID? Erik - no, locator
changes won't be visible to TCP (for example). It is interesting
to wonder about what SCTP over SHIM6 looks like... We're talking
about adding a lot of code to production stacks.
Pekka Nikander - If we are doing something at the IP layer, let
the session-level state still be at the transport layer. We need
to figure out SCTP over SHIM6. Why do we need anything in the IP
header at all? After you have a failure, you want to be able to
undo the address-swaps at the receiver correctly.
Christian Huitema - there is a LOT of interaction with transport
protocols. If we are assuming there's no impact, that's probably a
mistake. Look at what should change in transport protocol if it's
to take advantage of SHIM6. Need to interact with TSV working
groups.
Iljitsch van Beijnum - there are a handful of transports and
millions of applications, and we are already concerned about
changing transports...
??? If you're hiding multiple addresses, this may be sub-optimal.
Pekka Nikander - as an implementation option, maybe you don't re-
write the IP addresses, you pass them unchanged to SCTP? SCTP and
TCP interfaces may look different in the future. May also need to
think about path congestion versus session congestion - but this
is research.
Christian Huitema - there was running code several years ago for
TCP address changing - the issue was making sure you weren't
being spoofed when the addresses change.
Crytpo Locators
document: draft-ietf-shim6-hba-00.txt
refers to draft-ietf-send-cga-06.txt
Marcelo Bagnulo, Jari Arkko
- Concerns are preventing hijacking and flooding attacks in
multihomed environments - generate a set of securely established
prefixes
- Idea is to contain information about the set in the identifiers
themselves
- Using the IID bits (like CGAs) for HBAs - HBA would be a CGA
extension
- Includes a mechanism to add prefixes dynamically using hashes and
PK operations.
Dave Thaler - How does this work with temporary addresses/private
addresses?
response: HVA set is fixed for a given communication, but you can
have multiple HVAs.
Francis Dupont - IPR status of HVA?
response: No KNOWN IPR on this :-)
Triggers
document: draft-ietf-shim6-reach-detect-00.txt
Iljitsch van Beijnum
- goals - detect failures, and route around them ...
- note that "address pair" is a unidirectional path.
- Ping all source/dest pairs and pick best RTT or some other metric?
Doesn't detect unidirectional paths, doesn't scale well (M x N).
- Need better answer, so need more complexity - detect unidirectional
paths, stop probing when you find a reasonable path.
- Need heuristics (this is hard work), need a lightweight protocol.
- "CUD", similar to Neighbor Unreachability Detection, or "FBD",
requiring bidirectional communication (if you don't see
bidirectional communication, do full reachability exploration).
- CUD needs ULP feedback, FBD adds packets in an otherwise idle
direction.
- CUD detects failure in either direction, FBD in inbound direction.
- Several choices on granularity (host to host, locator to locator,
ULID to ULID, etc.).
- NATs and Firewalls - protocol may be reused for IPv4, so ... would
like IP options for fate-sharing, but this doesn't work with
NATs/firewalls. How important is sneaking past firewalls?
- Security - don't want too much reachability detection, but don't
want too little :-) Must be lightweight!
- Combine with draft on failure detection
John Loughney - need to clarify (on the list) how to go forward
based on architecture draft (transport layer? etc.) -
response: this is in the absence of session information coming
through transports, etc. - not either/or. Transports use ULIDs,
not locators, so the point where mapping from ULID to locator is
at the SHIM.
Hesham - Can you assume that all the addresses on an interface are
reachable?
response: This is site multi-homing, not host multi-homing, so ...
not in the SHIM6 context.
Spencer Dawkins - can people send info on unidrectional
applications to the list?
Jason Shiller - is this just reachability, or degradation? Don't
know the answer at this time.
Tony Hain - assuming all links are equal? Path selection may
depend on application (short T1 or long OC-48?) - use different
ULIDs for different applications?
Applicability
documents: draft-ietf-shim6-applicability-00.txt
draft-ietf-shim6-app-refer-00.txt
Joe Abley (reported by Geoff Huston)
- very short draft, mostly placeholders at this time!
3. Discussion about approach
- Geoff looking for co-author assistance with architecture draft
- At IP level, all paths are the same - do we need a richer set of
choices? Need to do design work here, especially for triggers.
- Kurtis - Please put ideas into existing drafts, not into new
drafts!
- Christian Huitema - transport protocols determine whether a path is
"good enough". Do we want to do this in IP, or expose information
to transports that do it? What if we don't have a translation layer
at all, and transports start doing this normally?
- Iljitsch - need to do this at some point, but don't do it now -
it's too early.
- Hesham - what about applications?
- Christian - two ways to solve this problem - API to push decision
mechanisms, or keep IP the way it is. Not the same thing at all.
- Hesham - in addition, there's also the factor of who makes the
decision.
- Pekka Nikander - yes, but most of this is implementation issue, not
protocol issue. Simulation would be good!
- Spencer - this is like the IAB Addressing workshop in Vienna -
every layer does everything, this is not what we really want. Need
to be really crisp here.
- John Loughney - NS2 is good. We're talking about policy here - need
to work through all of this from an application point of view.
4. Additional Items:
Interactions between Shim6 and MIPv6
document: draft-bagnulo-shim6-mip-00.txt
Marcelo Bagnulo
- This draft is informational for the working group at this point.
- Need to understand interactions (SHIM6 over MIP6).
- BT mode forces all traffic through home agent, if there is a
failure, so SHIM6 detects failure and uses alternative home address.
Or change care-of addresses?
- RO mode give you two sets of paths (optimized and un optimized
paths). One of the paths may fail, but not the other. SHIM6 uses
alternative locator, same issue.
- Should SHIM6 know about HoA/CoA?
Spencer - OK, I was hoping that when I said each layer was in
business for itself, I was hoping that was a bounded set of
problems...
- Charter says, "Don't break MIP6"...
John Loughney - which one is on top? there is no assumption at
this point. Mailing list to resolve this.
- Do an API before November IETF?
L3Shim state management using Vertical layered Communication
document: draft-you-shim6-L3Shim-state-meagement-00.txt
You Taewan
- TCP Slow start is needed after path switch?
- Will propose state management in more detail - if other protocol
layer MAY be modified, will propose specific method.
Spencer was going to say - TRIGTRAN answer was that new path
could be better or worse, simpler to let TCP figure it out rather
than try to listen to hints. Mark Allman and Joe Touch were good
sources on this. Answer may have changed, but that's what it was
18 months ago.