Re: Design decisions made at the interim SHIM6 WG meeting

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 19-okt-2005, at 6:11, Geoff Huston wrote:

> The following is a list of SHIM6 design decisions
I don't think "decisions" is the right word here... These are more  
like suggestions by the chairs.
> 1.  The specification for initial contact will use RFC3484, as  
> modified by
>     this draft in terms of source address ordering.
Well, all IPv6 hosts are expected to use RFC 3484 address selection,  
nothing new there. In fact, we have to break RFC 3484 from time to  
time because otherwise we'd be selecting non-working addresses.
The real point is what happens when the address pair selected by  
either the application or RFC 3484 doesn't work. How do we handle  
this case?
> 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.
I have no problem with a shim header for demultiplexing in cases  
where demultiplexing would otherwise be very hard or impossible. For  
instance, in the case of several extension headers, an explicit shim  
header makes it possible to indicate which headers see modified  
addresses and which headers see unmodified addresses unambiguously.
However, I think it's a very bad idea to have a shim header in EVERY  
packet with rewritten addresses, because there are cases where the  
shim context can be determined from information that's already in the  
packet unambiguously so an extra header is unnecessary.
Mandating a shim header first and then optionally allow it to be  
suppressed is useless in practice: we need have the capability to  
have the shim header suppressed as a mandatory part of the inital  
base spec.
> 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
If we know there are risks today, maybe it makes more sense to make  
the tag variable size (to be negotiated between the peers) rather  
than fixed?
Remember, there are no second chances: if we botch the initial packet  
layouts we'll have to live with them for a long time.
>      * Adopt HIP parameter format for options; HIP parameter format
>        defines length in bytes but guarantees 64-bit alignment.
I don't want this alignment. It wastes space, it's an implementation  
headache and it buys us nothing.
> 11. Proposed to drop specific mechanism for locator test and response
???

> 13. [What are privacy requirements for locator lists? Also  
> integrity - this
>      protocol is currently "in the clear".]
One person's privacy is the next person's debugging nightmare.

There is no privacy in today's multihoming either.

> 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.
Forking is a bad idea, it increases the complexity of the shim  
manifold while pretty much the same functionality can also be  
provided in a different way.
> 16. SHIM6 control message sequence numbers are not needed here.  
> [control
>     messages]
My reachability/failure detection draft has sequence numbers of its  
own in the reachability probes.
> 18. Use a statically specified in the initial protocol  
> specification of
>     (10) seconds.
This means that senders must transmit something (data, keepalive)  
every 10 seconds, right? So the receiver needs to wait a bit LONGER  
than 10 seconds to time out.
Note that the tradeoff is:

< 240 seconds: we MUST repair the problem before TCP times out
> 180 seconds: wait for BGP (90 - 180 second timeout) to fix the  
problem
< 90 & > 40 seconds: don't wait for BGP, but do wait for OSPF (40  
second timeout) to fix the problem
< 40 seconds: don't wait for OSPF

> 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.
In my draft I continue to search for "better" address pairs as  
defined by traffic engineering parameters. So if all locators have  
equal preference, there is no further exploration. If the current  
address pair is worse (= at least one of the two addresses has a  
lower preference than another potential source/dest address) the  
exploration continues for "better" pairs.