RE: stable addressing

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Iljitsch,

I very much share your concern about stable addressing.
The fact is that currently in IPv4, multihomed sites usually get PI
addressing, so provider independence is one of the benefits of multihoming
they obtain.
If the IPv6 multihoming solution doesn't provide provider independence, it
will be less attractive.

OTOH, i think we still don't have a clear view of what implies renumbering
in IPv6, as Brian mentions.

there are different renumbering scenarios here:
- Renumbering in current IPv4 networks, The experience here says that it is
expensive and sites will try to avoid it.
- Renumbering in current IPv6 networks, considering stateless
autoconfigurations, a fixed /48 etc. Perhaps it is still expensive but it
will be cheaper. Perhaps it is still too expensive.
- Renumbering when there is a loc/id split solution available. I guess we
don't have much idea how this would be, but we guess that it will be even
cheaper.

As i understand this thread, perhaps it would be possible to design the
solution to provide some sort of stable internal addressing for multihomed
sites, sort of GSE or MHAP like.

IMHO, i think that since this is one of current benefits of multihoming, we
should try to provide it (perhaps we should include it in Elliot's "things
to think about", so it is another aspect considered in the solution space
analysis.
OTOH, IMHO, for now, it should be one of those "nice to have" items, since
we still don't know how really expensive would be the renumbering process in
a general loc/id split and we don't know how hard it will be to provide this
feature.

Bottom line, i really think this should be one of the things we should
consider when analyzing the solution space.


About the particular approach that you are considering below, imho a very
valuable feature of a solution would be that middle boxes are stateless, so
that packets belonging of a certain communication can flow through different
middle boxes. I don't really think that a solution with a per flow state is
a good approach.

Regards, marcelo

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Iljitsch van Beijnum
> Enviado el: domingo, 18 de abril de 2004 1:05
> Para: Multi6 List
> Asunto: Re: stable addressing
>
>
> A "talk first, negotiate later" approach to multiaddress multihoming
> has important advantages, as it allows seamless backward compatibility.
> A weak point of this type of approach is that it doesn't lend itself to
> easy implementation in a middlebox, as compatibility with existing
> transports requires all possible addresses to be available on the
> multihomed host, and it possibly even requires cooperation from
> applications.
>
> However, if we were to add a new "fool the transport" address, this
> problem would largely go away. The idea is that multihomed hosts would
> have stable addresses (presumably unique site locals). For incoming
> sessions, the stable address is advertised in the DNS as a new RR. The
> correspondent looks up both the stable address and the set of regular
> addresses, and proceeds to set up a transport session towards one of
> the regular addresses as per NOID et al. However, the transport
> protocol acts as if the session is towards the remote stable address.
> The middlebox at the receiving site terminates all multihoming
> negotitation. It also maps back and forth between any of the regular
> addresses and the stable address, with the result that the receiving
> host can just use its stable address without being aware of multihoming
> issues.
>
> For outgoing sessions, the multihoming middlebox intercepts DNS
> requests by internal hosts. Rather than just send the AAAA records to
> the requesting hosts, it replies with an AAAA record that contains the
> "fool the transport" address for the remote host, and keeps an
> FTT->AAAA mapping in memory. Then, when the internal host tries to set
> up a session towards the remote FTT address, the middlebox performs the
> necessary multihoming negotiation with the host sitting at the AAAA
> address(es) associated with the FTT address in question and then
> proceeds to rewrite addresses as per the combined FTT->AAAA and
> multihoming state.
>
> Since the FTT address only replaces the locator/identifier at the
> transport level, applications still get to see the addresses that are
> published as AAAA records, so security assumptions aren't broken. That
> is, unless a middlebox is used, but in that case presumably the
> middlebox will handle any address-based security as well as
> multihoming. Since FTT addresses aren't really visible anywhere, there
> is little to no need to authenticate them.
>
> Note that this approach also allows for easier source address rewriting
> by routers.
>
> Two problems remain: interaction between multihomed hosts behind a
> middlebox and legacy IPv6 hosts, and referrals. And one thing to think
> about: making the negotiation protocols such that two or more
> middleboxes can come to the same results independently, so they can
> provide failover for eachother without having to synchronize state
> between them.
>
>