[Mobike] intermediate mobike design draft update
Pasi.Eronen at nokia.com
Pasi.Eronen at nokia.com
Wed Jan 26 12:02:40 EST 2005
Hi,
I have some comments and suggestions about the terminology about
addresses/pairs/paths in mobike-design-02.
1)
Currently the definition of "preferred address pair" is quite
imprecise, since it unnecessarily mixes what is preferred with
what is actually happening. Also, it's not quite clear what's
the difference between "preferred address pair" and "primary
path".
I'd suggest we replace both of them with a new term, say
"current path" (or "current address pair"), that means the
addresses that are currently used by the peer as the tunnel
header addresses of IPsec packets (of IPsec SAs associated
with this IKE SA).
I think we had rough consensus on issue 8 (scope of SA changes);
thus, each peer has only a single "current path", and in stable
situations (when nothing MOBIKE-related has been happening
recently), the "current path" is equal to the path used for
sending IKEv2 requests (for e.g. rekeying).
Both peers A and B have their own current path, and they're not
always equal (they are never equal if NATs are involved, and
even if no NATs are involved, they are different for at least
short periods of time when something MOBIKE-related is
happening).
It's a separate question whether the current paths should be
equal in stable situations (where NATs are not present). In
MOPO-IKE, they are (the responder uses the path selected by the
initiator). In SCTP, they're not (each peer makes its selection
independently). I'm not sure which is the case for
draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?)
2)
Most of the time, RFC2960 uses the word "path" to mean a
combination of source and destination address (and mostly
avoids the term "address pair"). I much prefer the word "path",
and I'd suggest we use that one (but whichever we use, it
should be consistent throughout the whole document).
3)
The definition of "Available address" says that "Where IPv4 is
considered, it is not an RFC 1918 [RFC1918] address." Why? For
instance, if the peers are connected to some private network
that happens to use RFC 1918 addresses, and there are no NATs
involved, why they're not allowed to use MOBIKE? (I'd suggest
removing this bullet.)
Best regards,
Pasi
More information about the Mobike
mailing list