Re: proxy shim with hash in upper address bits?

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 12/07/2007, a las 23:04, Iljitsch van Beijnum escribió:

> [crossposted, please prune as required. RAM people, please look at  
> the bottom of the message]
>
> On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:
>
> > > After reading Marcelo's draft about a proxy implementation of  
> > > shim6 a while ago I was somewhat disheartened: this is extremely  
> > > hard to do, mostly because an unsuspecting host would need to  
> > > receive an HBA-compatible address.
>
> > why do you think so?... you can deal with this doing dhcp  
> > delegation of the HBAs/CGAs? (you would be breaking stateless  
> > address autoconf, but i guess the same would happen if you need a  
> > reasonable amount of bits in the prefix to carry crypto  
> > information...)
>
> You're right, if you can get the hosts to create only HBA addresses  
> by use of DHCPv6 or some other mechanism, that would work. Note  
> thought that most of today's IPv6 hosts don't support DHCPv6  
> address assignment so this may not be a suitable solution for true  
> legacy IPv6 support.
>
> Obviously stateless autoconf would have to work with the bits in  
> the upper part of the address or this would be an exercise in  
> futility.
>
> > Yes, creating a crypto prefix for the identifier namespace would  
> > bean option for dealing with this, but i guess it would break SAA
>
> SAA?

stateless address auto configuration

> Another, possibly even harder to solve, problem with proxy shim is  
> what happens when a host behind the proxy want to talk to a non- 
> shim host.

it depends what type of idetifiers are you using

if you are using routable identifiers, then you don't have problem

if you are not using routble ids, then you are in trouble and  
backward compatibility woudl require either configuring routable  
address to hosts (in addition of the non routable ids) or some form  
of nat

> But quite possibly, we can solve this if we can make proxy shim  
> interoperable with a LISP-like approach. So the user of the  
> portable space would implement a shim proxy cq ETR/ITR which would  
> obviously be able to talk to other shim proxy/ETR/ITR devices as  
> well as to any host that supports shim6. Hosts that don't implement  
> shim6 would have to reach hosts behind a proxy through ETRs that  
> are deployed by their ISPs or possibly by the sellers of the  
> portable address space.


how does this solve the backward compatibility problem? I mean you  
still need to deploy ETR/ITR in the remote site, so if you do that,  
you may well deploy any other box i.e a pproxy shim

Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
support from both ends involved in the communication (either host or  
a box next to the host (proxy, TR)) (and the multihoming benefits  
only apply to the path between the two multihoming aware boxes)

Regards, marcelo