[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy shim with hash in upper address bits?



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