Subject: [RAM] Re: proxy shim with hash in upper address bits?

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 12 Jul 2007 23:04:37 +0200

[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?

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. 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.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Jul 2007 11:03:55 +0200

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

> 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.
>

stateless address auto configuration

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 11:20:06 +0200

> it depends what type of idetifiers are you using

Of course, I was assuming non-routable identifiers.

>> 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.

> 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)

Yes, this is an important limitation. With shim6 in hosts, you can  
determine if the other side supports shim6 before selecting an  
unroutable identifier, and fall back on legacy IPv6 if it doesn't,  
but then you're not multihomed for that session. With LISP et al this  
isn't possible, but the logic doesn't have to be in the hosts, so as  
long as there is a box somewhere in the path that supports the  
protocol, you're in business. The degenerative case would be where  
the encapsuating devices for site X which is reachable through ISPs A  
and B are located in the networks of A and B.

Making (proxy) shim6 and LISP interoperable helps shim6 because the  
deployment of LISP boxes means more people to talk shim6 with, and it  
helps LISP because you get to optimize paths to a much higher degree  
because this can happen at individual hosts, even ones that are not  
served by a *TR device.