Thanks Marshall and Scott. I think it is clear now. I think there is a case for such proxy service indeed.Moreover, as i understand it, this special case is probably more simpler than the general proxy case that we were discussing previously, in particularly security wise.
Let's flesh out the scenario a bit more.We have a host C located in a soho networks, that is multihomed to two small local DSL providers, ISPA and ISPB, that assign PrefA and PrefB respectively.
Suppose that the soho client is buying shim6 proxy services from the big provider. So the big provider has assigned PrefC:1:: to the soho network
The address of the shim6 proxy is PrefC:proxynow, in order for this work, i guess that the ULID used by the soho host C must be PrefC:1:hostC, and the locator used for any target node must be PrefC:proxy
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... comments? regards, marcelo El 30/04/2006, a las 7:03, Marshall Eubanks escribió:
Hello; OK, I'll expound a little. I work at home and I really needs my Internet connection. I can become "multi-homed," (and, in fact, am considering it) but let's say I would rather not run BGP from home. So I could get shim6, but what if I find that I don't get to use it much, because the content providers I usedon't support it ? If you come come along and sell me a service / software / hardware tofix this, I might buy it.I use my multihoming and shim6 to get to your equipment in a well provisioned colo or exchange point somewhere; from there to the providers is standard IP, v6 or maybe even v4, but that's OK because that's all on high capacity"backbone" links. On Apr 29, 2006, at 5:19 PM, marcelo bagnulo braun wrote:El 29/04/2006, a las 23:21, Marshall Eubanks escribió:i am sorry but i am not sure i understand... are you considering the case where the proxy is located in the soho or in the content server network?Neither - where the proxy is located on my network.I am sorry but i am completely lost here...and who's network is this? i mean, is this a provider's network?, i guess so, but who's provider? the dentist's? and what is the point of locating a shim proxy in a provider, when you are looking for is resiliency against provider failures...I don't know about you, but I am multi-homing my house to protect against MY ISP's failures, not Google's or the IETF's or ... . If I have two connections, I can tunnel through both of them to some well connected place which is much less likely to fail (and, through the magic of capitalism, can afford to be much more redundantly connected than I can at home). If the people at the other end don't support shim6 (and I frankly think that content providers are likely to resist supporting shim6), then, if I can use shim6 to this well connected place and a suitable proxy to get the home redundancy I want, I may well pay for it, and, if enough people feel the same way, you might have a business.thanks, marceloYou're welcome. Hope this helps, or at least was interesting. Regards Marshall