[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The state of IPv6 multihoming development
| > | No. The open concern then becomes that of
| applications that carry
| > | addresses in the payload -- would border routers require a
| > | knowledge base
| > | of applications to translate a la IPv4 NAT?
| > So we're going to institutionalize support for layering
| > This doesn't seem right.
| Unless I'm mistaken nobody here has proposed a solution
| that has this
Unless I'm the one that's mistaken, the original complaint was that
changing bits (and specifically -- the locator) at the border router
would break applications that carry full addresses around in them.
| If/when addresses are changed somewhere, they are either
| changed back later, or the destination is aware of the relationship
| between the old and new address. In other words: any address that an
| application communicates to the other end remains valid.
| Reachable is
| another question... Apps should consider using more than
| one address.
Ok, if apps (or the underlying transport) can use more than one address,
then that implies that the host has to make a decision about WHICH address
to use, which is what Craig was objecting to in the first place. If the
host has to decide, then it's making a routing decision and it certainly
shouldn't have enough information to make that decision.
Thus, the suggestion is to push the decision to the border router and
move the policy information there. The host still specifies the end
system identifier, but the border router then determines the locator.