[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
Paul Jakma wrote:
Both of the above interfaces are (obviously) easily encapsulated in IP
(hey, in the latter case you'll already have a full IP packet buffered).
In which case there won't be any deep technical barrier to just spitting
the packet out to another host (eg your normal gateway) and letting it
to do the shimming.
Paul,
How does the host get an IPv6 address assigned that has the right
low-order bits so that the HBA stuff on the remote shim/proxy can prove
(using HBA) to the peer that it owns the IPv6 address hence is allowed
to redirect it?
There ought be no more impact on end-end connectivity than is implied by
end-host shimming (which AFAIK has "full two-way end-end connectivity"
as its goal.).
The difference is that when the shim is in the end host, we also have
the end host do IPv6 address assignment based on HBA (which effects the
bottom 64 bits of the address.)
If we have the hosts just do stateless address autoconfiguration (RFC
2462) or temporary addresses (RFC 3041), then the shim can *not* use HBA
or CGA to tell the peer to switch locators for the host. (But it can
presumably handle the remote end asking the destination locators to be
changed). Thus if the shim proxy wants to handle this, it needs to first
do a 1:1 IPv6 NAT where the proxy has created the HBA/CGA addresses for
the host.
One could envision having DHCPv6 be shim aware so that when the hosts
asks DHCP for an address, the DHCP server would interact with the shim
proxy so that the addresses are from a HBA or CGA set. In that case one
wouldn't need the 1:1 IPv6 NAT in the shim proxy.
Erik