Francis Dupont wrote:
> > - motivation 2nd paragraph: the "another example" is a very
> > limited view of what multihoming support needs. I'd like to
> > see the mobike protocol supporting simultaneous multiple peer
> > addresses. (I use the term "peer address" from pki4ipsec
> > documents because it could not confused with addresses in
> > traffic selectors).
>
> Since the first version of MOBIKE only deals with the outer
> (tunnel header) addresses, using multiple addresses for an IPsec
> SA simultaneously would probably mean either load balancing
> (explicitly ruled out in the WG charter) or sending copies of a
> single ESP packet over several paths (nobody has expressed any
> interest in this so far).
>
> But this is probably not what you meant... ?
>
> => no, I mean simultaneous multiple peer addresses for different
> IPsec SAs, something I've called the SCTP model for multihoming
> (note it is not only for SCTP, it was just accurately described
> in SCTP documents).
The current protocol already supports this functionality. There
are several different ways how this functionality could be
implemented in the protocol, and in issue 8 there was rough
consensus to choose one of them (if you want different addresses
for different IPsec SAs, you can do so by creating IKE_SAs).
<snip>
> > - the link between 2.2 and 2.3 is not explained because the
> > new addresses are taken from the IP header. BTW I am afraid
> > the main scenario is the only supported scenario as a
> > consequence...
>
> Could you give a concrete example of a scenario that can't be
> done currently?
>
> => multihoming.
I do not agree. We just chose to implement multihoming support
in a slightly different way than SCTP did.
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.