I can think of two possible approaches at this point:
1) Whenever a host inside the soho network wants to establish a new
communication with a given server S, it establishes a shim6 context with
the proxy. For that shim6 context the ulid pair is: PrefC:1:hostC and
IPS and the locator set will be: for Ls(PrefC:1:hostC) = (PrefA:hostC,
PrefB:hostC) and Ls(IPS)= (PrefC:proxy). the drawback of this approach
is that we loose the deferred setup capability, which imposes a penalty
in terms of setup latency and by default shim6 would be used for all the
communications (we could think of some heuristics about for which
communication to use the shim6 and for which ones don't use it, but this
would impact on which ulid use...)
2) an alternative approach would be to create a shim6 protected tunnel
between the host in the soho network and the shim proxy. In its simplest
form, it would be a tunnel interface between the host in the soho
network and the proxy and this interface would be used as a default
route. The tunnel would then protected by the shim6 protocol and fault
tolerance features would be available for that path. This does not
impose additional latency because the tunnel/shim6 context would be
established at bootstrap and only one tunnel/shim6 context is needed to
support all the communications. The drawback is that we have the tunnel
header overhead, but maybe it would be possible to remove this using
some sort of nested shim (not sure if this last stuff would work...) The
features provided by the shim in this case would be an secure automatic
tunnel setup mechanism with fault tolerance protection, which may be
good enough justification.
I think this second approach is the one that is more attractive...