[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: source address rewriting and shim6 proxies
El 29/09/2005, a las 20:28, Erik Nordmark escribió:
marcelo bagnulo braun wrote:
what difficulties am i missing?
The first one is that we don't know what problem we are trying to
solve with shim proxies.
:-)
as you stated it in the previous message, there are at least two
flavors of proxies:
one would not require shim support form the the host (support legacy
hosts) and the other one would require some support from the hosts
(i.e. it would require hosts to support part of the shim)
one reason for the first type of proxies would be to enable shim
functionalities in legacy hosts
The reasons that i can see for the second type of proxies would be that:
- it would offload the exit path selection to the routing system, which
is more similar to the current paradigm. In this case, the exit path
selection process would benefit from routing information available in
the routing system of the multihomed site. In particular, exit path
failures would be directly detected by the routing system. Moreover, it
would enable the performance of some type of traffic engineering based
in the the configuration of the route selection in the routing system,
again more similar to current paradigm.
- it would provide ingress filtering compatibility, leaving source
address dependent routing just as a mechanism to support legacy hosts
(internal and external). so even if there is still a need for something
like source address dependent routing, the upgraded nodes won't need
it.
It could be enabling legacy IPv6 hosts behind a proxy (this is what
Paul is suggesting as far as I understand), or it could be having shim
aware hosts offload some functionality to a shim proxy.
The issues with the two are quite different. So which one are we
trying to solve?
Your comments were related to the second problem:
I am not sure i can see any difficulty with this... I mean in current
multihomed site scenario, where the prefixes are quite stable and
they change because of renumbering events associated to changes in
the ISPs, the coordination of the prefix set perceived by the host
and the prefix used by the routers seems feasible to me... In more
dynamic scenarios, this may be require further analysis.
But this might be problematic if you have shim6 hosts with different
capabilities. For instance, a smallish host is today allowed to not
configure IPv6 addresses for all the prefixes announced on its links,
which it might do to save on memory (think small battery operated
devices).
Having the routers be configured to rewrite to any of the site's
prefixes would then mean that the peer would see packets with a source
locator which was not setup as part of the context.
right
as i see it, this capability should be optional. I mean, hosts should
be able to prevent rewriting (this probably needs a don't rewrite bit
as well :-(
So, small devices as you mention may just prefer to do all their shim
processing themselves.
Even if you want to ignore small (battery operated) IPv6 devices, you
have similar issues when the set of prefixes change; the border
routers notion of the prefixes to use will be out of synch with what
any particular host in the site knows as the prefixes.
ok, as is see it the problem occurs when there is a new prefix
available in the exit router that the hosts is not aware of, right?
In this case, the router would stuff a prefix that is not in the
locator set for the shim session and packets would be discarded.
I think that this may be an issue depending on the considered scenario.
For instance, if you are considering a traditional site i.e. a SOHO or
big organization network, i guess this would be acceptable. I mean, in
this case, the prefix changes when there is a renumbering event
(because of changes in the ISP prefixes) This is a managed event and
the addition and removal of prefixes is a managed event. So i guess
that easily we could assume that the new prefix will be first notified
to the hosts and then configured in the exit routers.
However, in more unstable scenarios, like those related to mobility,
this may be an issue. I mean, if we are considering a mobile network
that changes the prefixes very dinamically, then maybe it is not
possible to assume that the hosts will be aware of the prefix before
that the router use it (in particular, because in a mobility scenario,
the new prefix may be the only available prefix) However, i am not sure
if this would be much of an issue because in this case, we have other
tools to deal with this (such as the nemo protocol)
One way to handle this is to have the receiver, instead of looking up
the context based on <source locator, destination locator, context
tag>,
only use <destination locator, context tag> for the lookup. That way
if the border routers put in a source locator that the source host
isn't aware of, the packets still get accepted by the destination.
but this would mean that you would be accepting packets with any source
address? wouldn't be some serious security issues there?
regards, marcelo
But as I said, I don't think this is the problem that folks are trying
to solve with the external shim.
Erik