Minutes - SHIM6 Interim Working Group Meeting
SHIM6 Interim Working Group Meeting
Hotel Krasnapolsky, Amsterdam, The Netherlands
8th - 9th October 2005
The meeting logistics were generously supported by the RIPE NCC, and the
SHIM6 co-chairs thank the RIPE NCC for their support.
In accordance with an announcement to the SHIM6 Working Group Mailing List,
an interim meeting of the SHIM6 Working Group was held at the Hotel
Krasnapolsky on the 8th and 9th October, 2005.
Agenda
The agenda for the meeting was as follows:
- Review of current status
- Presentation by lead authors on working documents:
Protocol
Crypto Locators
Triggers
Applicability
- Issue identification
Potential areas:
locator pairing discovery
locator pairing state maintenance / cache management
upper level protocol API / signalling
mobility implications
packet header format / content
shim equivalence state behaviour
- Functional decomposition
- Next steps (deliverables for Vancouver)
- AOB
Participants
Jari Akko
Marcelo Bagnulo
Pierre Baume
Iljitsch van Beijnum
Spencer Dawkins
Geoff Huston
Kurtis Lindqvist
Pekka Nikander
Ronald van der Pol
Minute Takers
Illitsch van Beijnum, Spencer Dawkins and Geoff Huston took notes of the
meeting. The minutes were assembled by Geoff Huston
1. Review of Current Status
This is intended to be the core specification document for SHIM6. draft-ietf-
shim6-l3shim-00.txt will not be further revised, and the introductory text
will be moved to the shim6 architecture document. Section 18 ("Design
Alternatives") of the -00 protocol draft will be placed into an appendix to
the document. It is undecided at this point whether to keep this appendix in
final version of the WG protocol specification document, or whether to
publish the appendix as a separate informational document at the same time as
the protocol specification document. The l3shim-00 document is effectively
replaced by this document.
The lead author of this document, Erik Nordmark, has requested some
assistance with the message diagrams and associated protocol interaction
descriptions.
The questions relating to this document were relating to the specific purpose
of maintaining this as a standalone document, and whether parts of this
should be folded into the protocol specification and architecture document.
The current version of the document concentrates of consideration of various
design alternatives. At this stage it is proposed that the documentation of
design alternatives and specific design decisions taken within the SHIM6
specification shall be included in the design alternatives appendix of the
protocol specification document, and material related to the architectural
description be folded into the architecture draft.
This document is ready to WG Last Call, and is used by the protocol
specification (which is based on HBA). The HBA draft describes how the hash
algorithm works, and it is noted that we can WG Last Call the current draft
and then bundle it with the rest of SHIM6 output for the IESG review and IETF
Last Call. It was proposed to consult the Ads regarding cross-area review of
this document needs, specifically including security community review.
Action: Chairs to perform a Working Group Last
Call on the HBA Draft
Action: Chairs to refer the document to the ADs
for cross-area review, with specific request for security review.
It was commented that ingress filtering is operational practice (BCP), not a
particular protocol standard.
RFC2827 "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Address Spoofing"
There are many ways that the issue of potential ingress filter-based packet
drop based on a source address filter match at the site boundary interface
could be addressed. It is also noted that the issue here is not entirely
limited to packet discard through ingress filter, but that selection of a
specific source address by the host may be used as a mechanism for a host to
select a specific site egress path where there are multiple egress paths
offering equivalent or overlapping destination reachability. The question of
whether source address selection can be used for egress path selection is an
open one, and the mechanisms proposed in the draft are not in common use at
present.
The question considered was whether the draft contained material that was
considered critical for the protocol draft. It was noted that the decision to
use source address selection as the signalling mechanism between the host and
the site's packet forwarding framework is not one that the WG has made. If
it's a precondition for SHIM6 that source addresses matter, the WG needs to
sanity-check this decision really soon, because the impact on routing and
forwarding systems within sites is very significant. It is also noted that
the sites' internal source-address forwarding mechanism is not required in
all cases (if you have full BGP at a single site edge router, for example).
Multihoming may not be comprehensive in terms of traffic "surviveability",
and, for example active SHIM6 traffic may failover but default-routed non-
SHIM6 traffic would not. If detection and repair aren't unidirectional, the
"other end" gets hints that things need to change, but the new source
address doesn't "steer" the other end traffic to take a particular incoming
path. While it was considered that these concerns are relevant to SHIM6, they
can be considered to be orthogonal to the protocol specification.
The question of adoption of this draft as a WG document was considered, It
was noted that there are a lot of good ideas discussed in this draft, but its
unsure that this document needs to be part of the SHIM6 document collection.
The central SHIM6 concern is that of hosts selecting among site exit paths,
rather than the general ingress filtering problem. One conventional approach
would be to consider and possibly document the requirements first, and then
solicit proposals that meet the requirements. It was also noted that the
SHIM6 approach is to propose a minimal set of changes here. It was felt that
more information would assist the WG in considering whether to adopt this
document as a WG document.
Action: Marcelo Bagnulo to draft a matrix of
scenarios and solutions relating to this ingress filtering and site exit path
selection, intended for presentation at Vancouver.
This draft notes shortcomings in RFC3484 in terms of trying all
source/destination combinations, not just all destinations, in a multi-
addressed local context, irrespective of local SHIM6 capability. The context
in SHIM6 is the proposed operation of initial contact, where the current
specification refers to RFC3484. It was considered that if the major
difference between the current version of RFC3484 and this draft is the
consideration of source address ordering, as distinct from just source
address selection, then this would be a relatively small textual amendment to
RFC3484. Implementing this change may be challenging, however. It was noted
that this proposed change to RFC3484 would address the SHIM6 charter item
that refers to "Solutions to establish new communications after an outage has
occurred that do not require shim support from the non-multihomed end of the
communication." The discussion in this draft will be used to support the case
for proposing changes to RFC3484, but it was considered that as this was the
output of the IPv6 WG, further changes to this specification should be
considered by the IPv6 WG. Determination of this question was considered to
be a decision for the ADs.
Design Note: The specification for initial
contact will use RFC3484, as modified by this draft in terms of source
address ordering.
Action: Marcelo Bagnulo to draft a note
outlining a set of specific text changes to RFC 3484 to support the approach
proposed in the address selection draft
Action: Chairs to pass this note and the
address selection draft to the ADs, with the recommendation that changes to
RFC3484 be considered by a WG in the Internet Area.
It was noted that this draft is not on the critical part in terms of
completing the initial core protocol specification. It was noted that there a
large number of issues with application referrals with Site-Local addresses,
and this has the potential for similar characteristics. The draft notes that
if a FQDN is not being used as the referral object, the options include the
passing of a ULID as the referral object or passing the entire locator set as
the referral object. The locator set object could be useful to assist in
terms of initial contact, but this has some API implications for upper level
protocols. The intent with the locator set was to use an object that it is
not intended that applications understand the semantics of these locator
sets.
Applicability document is currently a placeholder document, which will be
revised once the core protocol specification has been stabilised.
As the topics of failure and reachability are very closely related the
immediate steps are proposed to be merging these two drafts into a single
document that describes the state conditions where a failure condition will
be triggered, and also describes the exploration procedure that attempts to
recover connectivity though a structured search of the locator pair space to
discover locator pairs that offer host-to-host reachability. The decision
whether to further fold this combined failure detection and reachability
exploration specification into the core SHIM6 protocol document will be
considered at the SHIM6 WG meeting at IETF-64 (November 2005).
It was noted that there is reference to IPv4 and RFC1918/NAT conditions in
the current document, and it was proposed that this text be removed from the
SHIM6 documents on the basis that the WG has no charter beyond specification
of IPv6 mechanisms. However it was noted that the HIP WG and HIP RG may find
the extensions of this approach in IPv4 and RFC1918/NAT contexts a useful
approach useful in terms of avoiding reinvention in this area.
As this document is effectively replaced by the shim6-proto document, it will
not be further revised by the WG.
As discussed in the previous WG meeting in August 2005, this document will be
revised once the core specification is stabilized.
Upper level Protocol API
A document describing the forms of interaction with upper layer protocols has
yet to be drafted. Pekka Nikander has sent some thoughts to the mailing list
on this topic, but these have not been submitted as a draft as yet. A January
/ February 2006 submission time is anticipated. The perspective proposed is
to consider this from a SHIM6-centric perspective ("what signalling from the
upper protocol layers would SHIM6 consider a helpful indication?"). The
larger topic of locator pair selection as an indirect method of forms of
host-based traffic engineering and performance / service quality selection
would be held over for now and the initial API effort would concentrate on an
API that supports signalling to a core SHIM6 specification. The WG considered
that when a richer API was being considered by SHIM6 WG, then some assistance
from TSV would be of a significant benefit to the consideration of this
topic.
2. Presentations by Lead Authors on Working Documents
3. Issue Identification
4. Functional Decomposition
Design Note: Use an 8 byte IP SHIM6 header in
the base protocol specification for packets that require specific SHIM6
processing by the receiver, and allow optimizations on this, including that
of a zero-length header, to be an experimental protocol extension.
- Do we need a checksum in the control packets? Certainly not in every
SHIM6 packet, but checksums are more valuable in the control packets.
Design Note: Use a header checksum on the
SHIM6 control packets but no in the SHIM6 packet header.
- How "unique" are context tags? We are thinking about context tags as
a way of resisting injection attacks, so longer is more attractive. We will
end up with a 32-bit context field and about 15 bits as "reserved".
Design Note: Use a 32 bit context field with
no checksum, and 15 reserved bits and a 1 bit flag to indicate control /
payload. Note potential DOS risks
- Failure in initial contact? The direction here is to refer to an
updated 3484 (source address set), and may ask that a bidirectional ULP (such
as TCP) retry multiple initial SYNs with various source/destination locators.
Is this sufficient? One other possibility - "is this locator already part of
another locator set that has been previously established?" And how do we
cache this? Is this an API construct (ULP sends down the locator set and gets
back a ULID from SHIM6 if a SHIM6 context already exists for this locator
set)? Building on existing SHIM6 context state is similar to TCP sharing
congestion information across TCP connections, so we can anticipate that
SHIM6 API support at initial contact time would get used by upper layers.
- What about exchanging SHIM6 information that allows SHIM6 peers to
exchange ULIDs before initial SHIM6 context is established?
Design Note: For initial contact use RFC3484
(bis)
Design Note: Possible experimental ULP API
extensions to initial contact:
- Enhanced Contact would result in searching existing SHIM state
based on initial locator set. (This may return a ULID pair that was not in
the ULP's locator set - is this a problem?)
- SHIM6 Contact would perform the contact step above, and where
there was no SHIM6 context, then trigger SHIM6 state initialization and
returned to the ULP the ULID pair with SHIM6 state set up
- Ordered Locator Set ("getaddr_pair_set_info()") returns an RFC3484
ordering of locators based on local SHIM6 state information. This could be
used to construct a connect_by_name() approach
- We're not using ICMP messaging to indicate loss of state because of
our concerns about ICMP filtering in today's Internet. If we use the same
protocol for messaging and error notification, that protocol either makes it
through firewalls or it doesn't, instead of failing during error
notification, for instance.
- Can a SHIM6 peer decline SOME of the locators offered by another
SHIM6 peer? HIP experience was that a general update/ack protocol was useful
to update locators, SPIs, etc. MOBIKE also has a similar underlying protocol
as well. May include locators and preferences between locators.
- How many offers/counteroffers do we need to support?
Design Note: For SHIM6 control messages use a
unidirectional acknowledged information transfer UPDATE and ACK message
transaction as the base protocol, and then specify control messages in terms
of control message types and attributes.
Open Issue: Do we need a simply NOTIFY (un
ACK'ed UPDATE) message type as well?
Design Note: Locator pairs are
considered as unidirectional locator pairs, and there is no assumption that
these must map into a bi-directional pair.
- Locator list option has all locators, but HBA parameter set has
prefixes that reflect all locators, too. Is this needed in both places?
- Do we need a generation/version number for the locator list? This
isn't the same as transport sequence numbers that are used for reliability.
Could we recover more rapidly if we know what version number we are current
with? But we're sending entire sets now, not sending deltas. Don't want to
list entire IPv6 address locators in order to change preferences? But it is
simpler to send the addresses than to send the addresses and then send
preferences by index.
Design Note: Do not use
locator ordering and index references in SHIM6 control messages in the
initial base spec
- Detecting loss of context doesn't work while the ULID pair works as
the locator pair, so the peer may have garbage-collected the context and you
didn't notice until there is a failure.
- What do you do if you receive contexts that you don't understand?
Send an error, if it's a control packet, or silently discard it, if it's a
data packet? Eventually you notice because of reachability detection anyway -
do we need to notice more quickly than that?
Design Note: We need to
indicate which LLU locators should be verified with HBA, CGA, or some future
mechanism.
- 32-bit contexts could be DOSed - do we need more bits?
- Which SHIM6 control messages need sequence numbers?
- Remaining Design Alternatives...
- Need to make a decision on state cleanup, choosing uncoordinated
cleanup.
Sharing base packet format with HIP for SHIM6 Control messages
Pekka Nikander
- One perspective on HIP and SHIM6 is that SHIM6 is a semantic subset
of the HIP approach (Assertion - SHIM6 is a subset of the problems HIP is
trying to solve)
- This is not thinking about "same state machine and same semantics".
- But a common packet format would help with areas of potential
experimental protocol extension
- Current HIP packet layout is pretty different from SHIM6 packet
layout, but (ignoring HITs) the contents are pretty similar.
- Option format - is 256 bytes enough for CGA signatures? If not, we
have 16-bit length, so having 16-bit type makes more sense, and we may end up
with something that is a close approximation of the HIP parameter format in
any case
- Not proposing a single shared parameter space until we know a lot
more about HIP than we know today.
- Why did we use 8-bit options, and would 16-bit options be a problem?
- Our biggest expressed concern was a perception problem that SHIM6 is
- ntending to generate a proposed standard, while HIP is experimental. That
would imply a position that any resemblance to the current HIP packet format
is entirely coincidental, but useful in various experimental contexts.
Design Note: The SHIM6 packet
formats have been updated to
- have a 32 bit context tag
- checksum in same place as in the hip header
- a 1/0 bit to distinguish the payload vs. control messages
- have a 16 bit option type and length
For the most control messages this results in 7+16 reserved bits. Most of
the fields are 32 bit so they can't fit in here.
- Adopted HIP parameter format for options; HIP parameter format defines
length in bytes but guarantees 64-bit alignment.
[Meeting adjourned for dinner, restarted on Sunday morning.]
Protocol Specification
Placeholders (review)
- Locator pair test and response
Design Note: Proposed to drop
specific mechanism for locator test and response
- Reachability exploration: what locator pairs are working after a
failure? (actually "find me the first locator pair that works") - refer to
the failure and reachability work.
- Locator list option has all locators, but HBA parameter set has
prefixes that reflect all locators, too. Is this needed in both places?: We
think it's OK to duplicate locators and prefixes in our messages.
Design Note: Allow both
locator set enumeration and HBA parameter set in an UPDATE message
- What are privacy requirements for locator lists? Also integrity -
this protocol is currently "in the clear".
Design Note: Place this topic
into the larger item of possible areas of protocol extension, and note in the
Security Considerations of the protocol specification that "we have
considered this and are advising that this falls into an area of potential
protocol extension activity.
Action: Pekka Nikander and Marcelo Bagnulo to
work in a draft of "Guidelines for potential protocol extensions for SHIM6,
including (but not limited to)
- flow label use / header compression,
- privacy,
- hash chains and security,
- initial contactless SHIM6 context establishment ,
- API interaction for initial contactless SHIM6 context establishment
- Locator pair selection based on signalled preferences
- Return path locator preference signalling
- Forking of context state - is this unidirectional or bidirectional?
Strong preference voiced for a unidirectional forked state. Two goals here -
traffic engineering for a site, and different traffic types between the same
two hosts. Traffic engineering seems closer to what we know about at IP level
- "different traffic" may be a lot more open-ended. Mobile IP and HIP have
similar issues. One proposal advanced was to schedule a joint working session
in IETF-65with TSV and RTG? We won't know enough to meet on this subject in
IETF-64 in November 2005. Can we require that this be done at ULID selection
time? SCTP has similar problems (but SCTP is closer to the application than
SHIM6). SHIM6 is providing a hook for something finer than host-to-host
granularity, without trying to solve all conceivable problems. Bidirectional
context state forking is seen as a ULP signalled outcome.
Design Note: View forking as a
unidirectional context state fork (based on a ULP signal) that assumes that
the forked context state may then use a different outgoing locator pair.
- Run with a version number for a locator set?
- Detecting context problems while the original ULID pair works as a
locator pair? Need to detect the problem before a failure happens. Ping
periodically? If we send R1 as a context error message, we're already
starting to re-establish the context state. Why would any host that was
SHIMming decide to stop doing so? We need to make sure that we don't require
continuing packet exchanges without advancing to context established state.
The R1 values are slightly different (we don't have an initiator context tag
from a request, we are using the context tag that we believe the peer thinks
we have). We think that trying to return to non-SHIMmed operation when a host
garbage-collects context is probably a mistake - we'll just "die".
- What happens if the A end garbage-collect its state and later reuses
the same context number with the same B end host? Should the B end have the
new context replace old B end context state and just go on? There is a race
condition if the remote end is trying to reestablish the context that has
already been locally garbage-collected, and the remote end is trying to send
using the old context. There's a concern with forged packets that try to
reestablish the context resulting in a DOS. Can we include in the context tag
generation algorithm some bits from the sender of the packet, as well as the
receiver of the packet who chooses (most of) the context tag value, so the
context tag has bits from both ends and we can tell context 3.1 from context
3.2? Context numbers that are pseudo-random would help, but we can't prevent
collisions completely. If applications can provide hints to SHIM6 that the
application is still alive ("so don't garbage-collect"), that would help. A
usage counter can tell you if garbage collection of the context state at this
point in time would be a bad idea (as its still active), but not if it's a
good idea. If we can get unwedged, that's the important thing - being wedged
less often is an optimization.
- What do you do if you receive contexts that you don't understand?
Send an error, if it's a control packet, or silently discard it, if it's a
data packet? Eventually you notice because of reachability detection anyway -
do we need to notice more quickly than that?
Design Note: On receipt of a
SHIM6 payload packet where there is no current SHIM6 context at the receiver,
the receiver is to respond with an R1* packet in order to re-establish SHIM6
context. The R1* packet differs from the R1 packet in that an R1 packet
echoes the I1 fields, while this R1* offers state back to the sender. Either
way the next control packet is an I2 in response. The sender's previous
context state is to be flushed in receipt of the R2 packet following the R1*,
I2 exchange
Action Item: Marcelo Bagnulo to review this
and consider possible issues with this form of SHIM6 protocol response.
Action Item: Erik Nordmark to document the
alternative SHIM6 context setup where each side offers one half of the
constext value, so that unnecessary context destruction is avoided for WG
consideration.
- Are four packets really necessary in the SHIM6 context establishment?
IKEv2 doesn't require cookie to be present in all packets, only when we
suspect we're under attack. But this could be an experimental extension. SYN
flooding is still incredibly difficult to deal with operationally (because
each packet is just a normal packet). We are in better shape than IKEv2
because packets are still flowing "normally" while we are setting up SHIM6
context. This could be a potential experimental protocol extension.
Action Item: Marcelo Bagnulo
to document a shorter context establishment protocol exchange based on the
IKEv2 approach (as a potential experimental protocol extension).
- Which SHIM6 control messages need sequence numbers?
Design Note: SHIM6 control
message sequence numbers are not needed here. Design Note: Use FBD as the
reachability algorithm.
- Sender chooses outgoing address pair (independently of the choices
made by the remote host)
- Failure Detection:
- If you receive anything when you are sending packets, assume that all
is well.
- If you aren't sending or receiving packets, assume that all is well.
- If you are receiving packets and don't need to send payload packets,
send some form of keepalive.
- If you are sending payload packets and aren't receiving anything
(payload or keepalives), assume that something is broken after time interval
T.
- We need a time base in order to send keepalives, and an associated
timebase for non reception of in-coming packets within the SHIM6 context.
- Peers need to have a shared understanding of how long this timeslot
is. We need to understand the relationship between timeslots and RTTs (and
need to keep from reinventing TCP within SHIM6 with focus on RTTs). Would
prefer not to initiate an exhaustive locator exploration just because SHIM6
is confused about the peer's timeslot choice. We need to think about how
aggressive we want to be about failure detection. Exploring this futher, it
was observed that 10 seconds is fast as compared to BGP4 current practice
(1.5-3 minutes). There is a startup transient that is also critical here.
Should the initial specification used a statically defined time interval, or
does SHIM6 adaptively learn? Is there a difference between symmetric idle and
assymetric idle? We have some concerns about interaction with higher-level
protocols that may also be trying to do recovery asynchronously (and
applications that may differ in the goal for failover). Should this detection
and recovery mechanism be faster than a TCP ULP? Should the routing state
timers in OSPF and BGP be a factor here. TCP timeout is an upper limit.
Within that constraint, we have three choices for the timeout: slower than
BGP (so we give BGP the chance to repair the failure: > 90 (RFC) or 180
(Cisco) seconds), between BGP and OSPF (give OSPF the chance to repair: > 40
< 90 or 180 seconds) or faster than OSPF: < 40 seconds.
Design Note: Use a statically
specified in the initial protocol specification of (10) seconds.
The idle keepalive trigger is statically specified to be 3 seconds.
This value may be negotiated at SHIM6 context startup as an experimental
protocol extension
This value may be dynamically altered during the SHIM6 context as an
experimental extension
- The meeting noted other candidate timers, including setting the value
between 24 and 36 seconds.
Reachability Exploration
- Exploration may be a uni-directional discovery, but a bi-directional
shared computation
- Exploration uses an attempt to synchronize on a state, using a format
where each sent probe carries information relating to all received probes so
far.
- Exploration also makes use of timers in terms of assumptions of
failed probes
- In exploration for a viable locator pair it is noted that only one
end may know there's a problem, and knowing when to STOP exploring is really
hard.
- Note FBD only detects failures in the incoming path.
- Consideration of the use of a "quick check" as the initial response
before launching into a full exploration.
- Must SHIM6 recognize a keepalive as a keepalive? This is not strictly
required in FBD, as its SHIM6 packets rather than specific packet content or
type that count here, but we have to be able to recognize keepalives as
keepalives to avoid sending keepalives in response to keepalives.
- Also note that it's an issue to determine when to STOP sending
keepalives when neither peer has traffic to send.
- It is also a relevant consideration of how firewalls react to
keepalives (probably react badly to IP packets with no payload whatsoever
(header only), probably use SHIM header with keepalive option.
- The concept of a "host-id" was considered as a way of identifying a
"host" across multiple ULIDs. Need an algorithm to make sure all hosts choose
a unique host ID (same theory as router IDs). How do we change host IDs if
the chosen locator was deprecated? Alternative is to work with sets of
locators (instead of host IDs) - "this is the set of locators I think you
have".
- How dynamic are locators sets (with CGA, etc.)? ULIDs don't change as
long as there is any session active.
- A common probe data structure is proposed to be reused in several
packet layouts.
- Quick check request/reply mechanism (we think this path will work,
we're just making sure), plus full exploration with context reference. Some
concerns about DOSability of including context information as part of
reachability (reflection attacks, etc.). Including "last few" probes in each
direction (allows you to detect relatively slow locator paths). Does this
extend into sending complete metrics for all locators on each probe? Could
send last 3 successful probes, last 3 failed probes, etc. Balancing amount of
hints on path selection with amount of information sent. Unsuccessful probe
information could be really useful ("move these locators to the end of the
list"). 30-40 second-old information is ancient history.
- Start full exploration when you timeout on quick check. "Exponential
backoff" - sending probes to more locators over greater intervals. Some
discussion about choosing "best" or "first as good as previous" paths based
on RTT vs simply choosing a working path - concerns about minimizing RTT
versus other QoS values (jitter, etc.). Moving beyond "works" as a
discriminator should be an experimental protocol extension. Moving "back" to
the original locator pair should be an experimental protocol extension. The
subtext is "getting off my GPRS backup ASAP", and that's really hard to
generalize.
- Propose to use this probe structure in all SHIM6 packets (would give
us better RTT measurements)?
- When should exploration stop? When you have any candidate locator
pair? Or continue to see if there is a 'better' candidate pair?
Design Note: Continued
exploration to see if a 'better' locator pair is available following
identification of a viable locator is considered to be an experimental
protocol extension. The exploration in the base protocol specification will
terminate once a viable 9reachability confirmed) locator pair has been
discovered.
Reachability (v2)
- Reachability, version 2 (REAP) - using the same messages for four
complimentary functions (direct reachability, reverse-path reachability,
checking different return paths, return routability checking). Including a
mechanism for not having to probe in both directions simultaneously.
- How long do we continue to probe? Keep context state around and wait
for upper layer apps to "try again". We may wish to remember paths that
previously failed so we try them LAST during the next failure.
- Some discussion of how close REAP comes to being STUN protocol when
we have unidirectional path failures... is this ALSO an experimental
extension?
- Some discussion of how long we have to deliver SHIM6 baseline
functionality (time and energy), and how our charter maps to "providing IPv4-
equivalent multihoming in IPv6".
- Some discussion of unidirectional path failures - isn't this usually
due to ingress filtering? Can we assume that we don't have to recover from
unidirectional path failures in SHIM6? But we have to detect this condition,
even if we don't recover from it. We think we can assemble two unidirectional
paths into a single bidirectional path, but don't know all the implications.
We need to be able to steer traffic based on source addresses to accomplish
this. Should continue exploration until we identify a working bidirectional
value. RFC 3484bis and SHIM6 setup and recovery will all require
bidirectional paths - don't SHIM6 setup over unidirectional paths (because
RFC 3484bis has a working path already, no reason to try to improve it in the
face of failures). Should we allow setting up a SHIM before there is a
context? Need I1bis that says "send this back using a different locator" to
make this work. Concern about creating state? but maybe allowing state on the
INITIATOR is OK, as long as we don't require state on the RESPONDER. May have
to do M x N scan to find something that works. May need "API on steroids" to
initiate this process.
- REAP - Four functions:
- Direct reachability - the message can get to the receiver
- Indirect reachability - earlier messages got to the sender
- Redirected response - request the receiver to use a different
(specified) locator pair for the response
- Perform a return routeability test
- Another way to look at exploration is that of an exploration of a
matrix of locator pairs, with sender using locator Pair (a,b) and the
receiver using the locator pair (a',b'), and each cell of the matrix is
itself a 3x3 set of possible information states, whether traffic has been
sent on the sending locator pair, whether traffic has been received on this
pair and what the local (sender) end thinks it knows about the other
(receiver) end.
- Related issues: how many probes before the algorithm can consider the
locator pair unuseable? How many passes across the full exploration space
before the algorithm terminates with complete failure?
Design Note: Where we are:
- Initial contact: 3484 (bis) is bidirectional
- Shim setup is bidirectional based on initial locator set
- Recovery from failure is potentially unidirectional
Design Note: Questions:
- Should shim setup allow unidirectional? No point per se unless you
have shim6 setup WITHOUT context
- Should 3484 be extended to allow unidirectional? No
- Should shim6 be allowed to setup without initial established context?
If yes, should it include unidirectional discovery?
- Should failure recovery continue to see if there is a bidirectional
locator pair even though there was already a unidirectional path
- Note that the modified I1 in this case would include a STUN-like
request to pass a packet back with a different locator pair than the received
I1 packet
Action: Document the simple cases
Action: Document this concept of shim6
context without initial bidirectional initial contact (i.e. shim6 initial
context passes into an initial walkthrough) and API considerations
Action: Initial reachability detection - aim
to get a unidirectional support version drafted by November. Pekka Nikander
and Iljitsch van Beijnum to do an individual submission for working group
review.
5. Next Steps
- Produce -01 of the protocol draft immediately following this interim
WG meeting
- Perform a WG Last call of the HBA draft
- Reachability detection - aim to get a unidirectional support version
drafted by Vancouver
- 3484bis - pass documented requirement to ADs to see where it's
actually reviewed.
- There may be impacts on the HBA draft if there is an option structure
added to CGA. We think Marcelo can handle this, before IETF-64.
- Want to make sure everyone agrees that the base protocol extension
represents a conservative, but workable approach and at this stage consider
further refinements to be experimental extensions. Check with the working
group to see if unidirectional support goes in the base protocol? (Does the
WG agree that STUN-like response redirection is a good thing to include in
the base protocol? We're saying that the API must allow applications to
specify ULIDs, we're saying that I and R packets must support response
redirection - maybe this is a reply redirection AND a reply that says what
the original addresses were.
|
