[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
marcelo bagnulo braun wrote:
But you need to given all the addresses to the host so that there are
redundant addresses available for it during initial communication,
don't you?
>
yes, unless you are sure that you are communicating with a shim enabled
peer (the peer or a middlebox in front of it) in which case you could
use shim capabilities even for dealing with outages in the locator used
for initial contact
How would the DHCP server, when handing out address, know whether or not
the local host will communicate with a shim capable peer?
The local host might communicate both with shim incapable peers and with
shim capable peers. In the first case it makes sense for the host to
know all its addresses with the hope that default address selection and
application retries finds a working address pair. In the second case the
middlebox can help so it makes more sense (does it?) to only give the
host one address, which is part of a HBA/CGA set maintained by the
middlebox.
If the DHCP server only hands back one address to the host, what would
happen when a shim6 capable host is used? It would want all the
addresses/prefixes so it could do shim6 on its own.
i guess that the DHCP server should know if the requesting host is shim
capable or not
This is at least solvable, with a new DHCPv6 option saying "I'm shim6
capable - disable any shim6 middlebox stuff".
imho middleboxes don't really fit nicely in the shim arch. I mean shim
arch is e2e by design, not suited for middle boxes i guess.
Well, TCP is e2e yet there are plenty of transparent TCP proxies which
work most of the time. (They are a single point of failure for a
connection etc, but they don't seem to run into the same type of issues
we see for a shim6 middlebox.) Perhaps the added complexity of both
overloading the IP addresses to function as ULIDs and locators, combined
with handling failures during initial communication in the
application/ULP, and failure of existing communication in the shim, is
what makes this so hard.
any middlebox support will be some form of hack imho
Agreed. Question is it would be a useful hack, or just asking for trouble.
Erik