I-D ACTION:draft-ietf-mobike-design-04.txt

Tero Kivinen <[email protected]> Sat, 22 Oct 2005 09:59:15 +0300
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
[email protected] writes:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF.
> 
> 	Title		: Design of the MOBIKE Protocol
> 	Author(s)	: T. Kivinen, H. Tschofenig
> 	Filename	: draft-ietf-mobike-design-04.txt
> 	Pages		: 35
> 	Date		: 2005-10-21
> 	
> The MOBIKE (IKEv2 Mobility and Multihoming) working group is
>    developing extensions for the Internet Key Exchange Protocol version
>    2 (IKEv2).  These extensions should enable an efficient management of
>    IKE and IPsec Security Associations when a host possesses multiple IP
>    addresses and/or where IP addresses of an IPsec host change over time
>    (for example, due to mobility).
> 
>    This document discusses the involved network entities, and the
>    relationship between IKEv2 signaling and information provided by
>    other protocols.  Design decisions for the MOBIKE protocol,
>    background information and discussions within the working group are
>    recorded.

In this new version of the design draft, there is some mostly
rewritten sections about the choosing addresses and about NAT
traversal, some of the other parts are reorganized, and quite a lot of
text was also removed. So when reading this through, better keep that
in mind, i.e. even when you remember that the old version had
something about issue X later, do not assume so, but check it if you
think the issue X needs to be in the draft.

One change that I didn't yet do for this version was to check out the
terminology, and the need for that. There was a suggestion that we do
not need that section at all, but removing that would have required
rewriting the scenarios and scope sections also, so I decided not to
do it on this version.

This document is trying to give some background and design information
why we ended up using certaing method in the actual protocol document.
I.e. the protocol document should say we do X, and this document is
trying to tell why we ended up doing X, and what were the other
options, and why they were not selected.
-- 
[email protected]