Design decisions made at the interim SHIM6 WG meeting

[Geoff Huston <gih@apnic.net>]

Hi,

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).

thanks,

  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
    packet header.

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
    message

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
    messages]

17. Use FBD as the reachability algorithm.

18. Use a statically specified in the initial protocol specification of
    (10) seconds.

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.