[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Design decisions made at the interim SHIM6 WG meeting
- To: firstname.lastname@example.org
- Subject: Design decisions made at the interim SHIM6 WG meeting
- From: Geoff Huston <email@example.com>
- Date: Wed, 19 Oct 2005 14:11:17 +1000
The following is a list of SHIM6 design decisions made at the interim
meeting of the SHIM6 WG, extracted from the meeting minutes. These
decisions are subject to confirmation by the WG. Your chairs invite you to
review these decisions and we'd like to understand the level of WG
consensus for these decisions by the end of next week (Friday 28th October).
Geoff & Kurtis
1. The specification for initial contact will use RFC3484, as modified by
this draft in terms of source address ordering.
2. 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.
3. Use a header checksum on the SHIM6 control packets but not in the SHIM6
4. 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
5. Possible experimental ULP API extensions to initial contact:
5.1. 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 ULPs locator set is this a problem?)
5.2. 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
5.3. 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
6. 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.
7. Locator pairs are considered as unidirectional locator pairs, and there
is no assumption that these must map into a bi-directional pair.
8. Do not use locator ordering and index references in SHIM6 control
messages in the initial base spec
9. We need to indicate which LLU locators should be verified with HBA,
CGA, or some future mechanism.
10. 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.
* Adopt HIP parameter format for options; HIP parameter format
defines length in bytes but guarantees 64-bit alignment.
11. Proposed to drop specific mechanism for locator test and response
12. Allow both locator set enumeration and HBA parameter set in an UPDATE
13. [What are privacy requirements for locator lists? Also integrity - this
protocol is currently "in the clear".]
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.
14. 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.
15. 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 senders previous context state is to be flushed
in receipt of the R2 packet following the R1*, I2 exchange
16. SHIM6 control message sequence numbers are not needed here. [control
17. Use FBD as the reachability algorithm.
18. Use a statically specified in the initial protocol specification of
19. 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.