El 09/05/2006, a las 2:35, Erik Nordmark escribió:
marcelo bagnulo braun wrote: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...Couldn't one do #2 today using IP-in-IP tunneling and some liveness test protocol (ICMP echo?) for the tunnels, without any shim6?As I understand it in #2 the ULID is really an IP address assigned to the host by the proxy provider, which gets tunneled to/from the IP addresses assigned to host by the "physical" providers.
right as i see it, the shim6 protocol in this case would be used to:- dynamicaly create the tunnels, so that the big ISP that is hosting the proxy does not need to make manual configuration. note that even if a mechanism like a tunnel broker is used, you still need to make some checks about the alternative addresses and so on that are configured. This would be like a fully automatic secure mechanism to establish such tunnel - failure detection and alternative path exploration. The mechanism for failure detection developed by shim have the possibility to eficiently explore alternative paths and deal with unidirectional connectivity. BEsides, since the context establishment and the failure detection paths use the same protocol number you are sure that if you can establish the context, then your failure detection path exploration packets won't get filtered (as oposed to the ICMP case)
BEsides, maybe it would be possible to define some form of nested shim, where we don't need to include both IP headers of the tunnel in this case. I mean, after all a tunnel is an address mapping as performed by the shim, so it may be possible to optimize the shim for this case, so we can provide some additional eficiency for this case.
In any case, i agree that this case is much more simpler than the general case for which the shim6 was designed for, and it wouldn't make sense to have the whole shim protocol just to provide this feature, however i think this may be a good deployment tool, allowing small end sites to benefit from the shim while the servers don't have support for the shim protocol...
regards, marcelo
Erik