< draft-sugimoto-mip6-pfkey-migrate-00.txt		draft-sugimoto-mip6-pfkey-migrate-01.txt >
	Network Working Group S. Sugimoto		Network Working Group S. Sugimoto
	Internet-Draft Ericsson/USAGI Project		Internet-Draft Ericsson
	Expires: August 18, 2005 F. Dupont		Expires: February 2, 2006 F. Dupont
	Point6		Point6
	February 14, 2005		M. Nakamura
			Hitachi
			August 2005
	PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE		PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE
	draft-sugimoto-mip6-pfkey-migrate-00		draft-sugimoto-mip6-pfkey-migrate-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 18, 2005.		This Internet-Draft will expire on February 2, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes need for interface between Mobile IPv6 and		This document describes the need for an interface between Mobile IPv6
	IPsec/IKE and show how two protocols can interwork each other. We		and IPsec/IKE and show how the two protocols can interwork. We
	propose a mechanism to realize this interaction by extending PF_KEY		propose a set of extensions to the PF_KEY framework which allows
	framework. Proposed mechanism makes it possible for Mobile IPv6 to		smooth and solid operation of IKE in a Mobile IPv6 environment. The
	inform IPsec/IKE about the movement. Receiving the message, IPsec		first extension is called PF_KEY MIGRATE and is for migrating the
	components can take necessary actions to update corresponding entry		endpoint addresses of a IPsec Security Association pair in tunnel
	in SPD and SADB. In addition, IKE can use the notification for		mode. The second extension is named SADB_X_EXT_PACKET and allows IKE
	keeping its IKE connection alive.		to make the right choice for address selection in bootstrapping
			process. Both extensions are helpful for assuring smooth
			interworking between Mobile IPv6 and IPsec/IKE and achieving
			performance optimization.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 3
	3. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 5		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. PF_KEY Extensions for Mobile IPv6 . . . . . . . . . . . . . . 4
	5. PF_KEY Extension for Mobile IPv6 . . . . . . . . . . . . . . . 8		4.1. PF_KEY MIGRATE Message . . . . . . . . . . . . . . . . . . 4
	5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
	5.2 Message Sequence . . . . . . . . . . . . . . . . . . . . . 9		4.1.2. Message Sequence . . . . . . . . . . . . . . . . . . . 6
	5.3 Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . . . 10		4.1.3. Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . 7
	5.4 Processing PF_KEY MIGRATE Message . . . . . . . . . . . . 11		4.1.4. Processing PF_KEY MIGRATE Message . . . . . . . . . . 8
	5.5 Applicability of PF_KEY MIGRATE to Other Systems . . . . . 12		4.1.5. Applicability of PF_KEY MIGRATE to Other Systems . . . 9
	5.6 Limitation of PF_KEY MIGRATE . . . . . . . . . . . . . . . 12		4.1.6. Limitation of PF_KEY MIGRATE . . . . . . . . . . . . . 9
	6. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 13		4.2. PF_KEY Packet Extension . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message . . 10
	8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15		4.2.2. Processing SADB_ACQUIRE Message with Packet
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		Extension . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16		4.2.3. Relation of Packet Extension to IKEv2 . . . . . . . . 11
	A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . . . . . 17		5. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 11
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . 21		7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			Appendix A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . 14
			Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	In Mobile IPv6 [RFC3775], the MN and HA may use IPsec tunnel to		In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent
	protect mobility signals and payload traffic. From security point of		(HA) use some IPsec Security Associations (SAs) in tunnel mode to
	view, it is preferable to protect mobility signals that are		protect some mobility signaling messages, mobile prefix discovery and
	transmitted on the path between MN and HA. In addition, mobile user		optionally payload traffic. Since the MN may change its attachment
	may want to have payload traffic protected by IPsec tunnel. Hence,		point to the Internet, it is necessary to update its endpoint address
	leveraging IPsec tunnel is essential in Mobile IPv6 operation. Since		of the IPsec SAs. This indicates that corresponding entry in IPsec
	the MN may change its attachment point to the Internet, it is		databases (Security Policy (SPD) and SA (SADB) databases) should be
	necessary to update endpoint address of the IPsec tunnel. This		updated when MN performs movements. In addition, IKE requires
	indicates that corresponding entry in IPsec database (SPD and SADB)		treatment to keep its IKE session alive in a Mobile IPv6 environment.
	should be updated when MN performs movement. In addition, IKE
	requires treatment to keep its IKE connection alive in Mobile IPv6
	environment.
	This document describes need for interface between Mobile IPv6 and
	IPsec/IKE and show how two protocols can interwork each other. We
	propose a mechanism to realize this interaction by extending PF_KEY
	framework [RFC2367]. Proposed mechanism makes it possible for Mobile
	IPv6 to inform IPsec/IKE about the movement. Receiving the message,
	IPsec components can take necessary actions to update corresponding
	entry in SPD and SADB. In addition, IKE can use the notification for
	keeping its IKE connection alive. Proposed mechanism has been
	implemented on both Linux and BSD platform and confirmed to work well
	with existing Mobile IPv6 and IPsec/IKE stack.
	2. Terminology
	There is no term newly introduced in this document. Definitions of
	the terms relevant to Mobile IPv6 can be found in [RFC3775] and
	[RFC3776]. Definitions of the terms relevant to IPsec can be found
	in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]. Some clarifications
	are provided below for the terms that are frequently used in this
	document.
	Care-of address (CoA) - Topologically correct IPv6 address assigned
	for MN. MN registers its primary CoA to the HA, which is called home
	registration. CoA should be an endpoint address of the tunnel
	established between the MN and HA. The tunnel could be either
	IP-in-IP tunnel or IPsec tunnel.
	Movement - An event in which MN moves from one subnet to another
	changing its primary CoA. In Mobile IPv6, movement can be
	categorized into following three types: Home-to-Foreign,
	Foreign-to-Foreign, and Foreign-to-Home. In terms of necessary
	actions taken upon movement, each case should be differentiated.
	Return Routability procedure - A mechanism for authorizing Binding
	Update (BU) message sent by the MN to CN. There are four Mobility
	Header (MH) messages involved in the procedure: Home Test Init
	(HoTI), Home Test (HoT), Care-of Test Init (CoTI), and Care-of Test
	(CoT). In order to minimize a chance for malicious node to eavesdrop
	contents of the Home Test, it is strongly recommended to protect HoTI
	and HoT with IPsec tunnel.
	3. Needs for Interactions between Mobile IPv6 and IPsec/IKE		This document describes the need for an interface between Mobile IPv6
			and IPsec/IKE and shows how the two protocols can interwork. We
			propose a set of extensions to the PF_KEY framework [RFC2367] which
			allows smooth and solid operation of IKE in an Mobile IPv6
			environment. The first extension is called PF_KEY MIGRATE and is for
			migrating the endpoint addresses of the IPsec SAs in tunnel mode.
			The second extension is named SADB_X_EXT_PACKET and allows IKE to
			make the right choice in address selection in the bootstrapping
			process. Both extensions are helpful for assuring smooth
			interworking between Mobile IPv6 and IPsec/IKE and achieving
			performance optimization.
	First of all we try to figure out needs for interactions between		2. Needs for Interactions between Mobile IPv6 and IPsec/IKE
	Mobile IPv6 and IPsec/IKE. Ideally, there should be no interactions
	needed. However, throughout prototyping activity and operation of
	Mobile IPv6, we have identified following needs.
	MN may change its attachment point to the Internet whenever it		The section 4.4 of RFC 3776 [RFC3776] specifies the rules which
	performs movement. Consequently, its local address of tunnel		applies to IKEv1 for MNs and HAs. The first requirement is to run
	established between its HA should be updated. Since CoA is used as		IKE over the Care-of Address (CoA) because the Home Address (HoA) is
	an endpoint for the tunnel, both MN and HA should take necessary		usable only after the home registration so not yet in the
	update. On MN, local address of the tunnel should be updated with		bootstrapping phase.
	newly assigned CoA. On HA, remote address of the tunnel should be
	updated with newly registered CoA. As for normal IP-in-IP tunnel,
	Mobile IPv6 should be able to update the endpoint address easily.
	However, Mobile IPv6 may not have full control on updating endpoint
	of IPsec tunnel since it requires direct access to the IPsec
	database. This indicates that Mobile IPv6 should request IPsec for
	updating specific entry in SADB.
	In practical scenario, key management protocol such as IKE would be		A tunnel IPsec SA pair protects some signaling messages and
	used to establish security association between the MN and HA. IKE		optionally all the traffic between the MN and HA. The initial SPD
	daemon should always be aware of up-to-date SPD in order to perform		entry uses the HoA for the MN endpoint address and updates this
	key negotiations and subsequent rekeying. Since IKE runs according		address to the new CoA at each movement. A tunnel SA pair is created
	to the SPD, tunnel information (endpoint addresses) should be somehow		on demand and is updated too. The RFC 3775 [RFC3775] assumes there
	included in security policy entry. Although specific data structure		is an API which performs the update in the SPD and SADB on both the
	of a security policy is implementation specific, most of the existing		MN and HA. This document is mainly about this API.
	IPsec implementations conceptually have such information in security
	policy. Considering the fact that tunnel endpoint address could be
	dynamically updated, corresponding entry in SPD should also be
	updated.
	Mobile IPv6 specifies a flag named Key Management Mobility Capability		Mobile IPv6 specifies a flag named Key Management Mobility Capability
	bit (K-bit) in Binding Update and Binding Acknowledgement message		bit (K-bit) in Binding Update (BU) and Binding Acknowledgement (BA)
	(see section 10.3.1 of [RFC3775]), which indicates an ability of IKE		messages (section 10.3.1 of [RFC3775]), which indicates the ability
	to survive movement. When both MN and HA agree to use this		of IKE sessions to survive movement. When both the MN and HA agree
	functionality, the IKE daemons dynamically update its IKE connection		to use this functionality, the IKE daemons dynamically update the IKE
	when the MN performs movement. In order to realize this, IKE daemon		session when the MN moves. In order to realize this, IKE daemons
	should be notified by Mobile IPv6 and necessary information to		should be notified by Mobile IPv6, and necessary information to
	migrate the IKE connection should be provided.		migrate the IKE session should be provided.
	Mobile IPv6 may need to make an access to SPD not only for updating		Mobile IPv6 may need to make an access to the SPD not only for
	endpoint address but also for deletion/insertion of specific security		updating an endpoint address but also for the deletion/insertion of a
	policy entry. When the MN performs Foreign-to-Home movement, IPsec		specific SPD entry. When the MN performs Foreign-to-Home movement,
	tunnel established between the MN and HA should be destroyed, which		IPsec SAs established between the MN and HA should be deleted, which
	means that the SPD entry should have no effect any more. On the		means that the SPD entry should have no effect any more. On the
	other hand, when the MN performs Home-to-Foreign movement, the IPsec		other hand, when the MN performs Home-to-Foreign movement, the IPsec
	tunnel should newly be created. Hence security policy entries that		SAs should be restored. Hence security policy entries that are
	are associated with tunnel mode security association may dynamically		associated with tunnel mode SAs may dynamically be added/removed
	be added/removed in along with MN's movement.		(enabled/disabled) in along with MN's movements.
	It should be noted that NEMO Basic Support [RFC3963] may have similar		It should be noted that NEMO Basic Support [RFC3963] has similar
	requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO,		requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO,
	MR works just as same as MN registering its location information to		the MR works just as same as a MN registering its location
	the MRHA and establishes tunnel (IP-in-IP or IPsec tunnel). If IPsec		information to the MRHA and establishes a tunnel (IP-in-IP or IPsec
	tunnel is established between MR and MRHA, the MR serves as a		tunnel). When an IPsec tunnel is established between MR and MRHA,
	Security Gateway (SGW) for the nodes inside the mobile network. MR		the MR serves as a Security Gateway for the nodes connected to the
	is responsible for handling its tunnel endpoint properly.		mobile network. The MR is responsible for handling its tunnel
			endpoint properly.
	4. Requirements		3. Requirements
	Given the needs for interface between Mobile IPv6 and IPsec/IKE,		Given the need for an interface between Mobile IPv6 and IPsec/IKE,
	there should be minimum interface between the two protocols.		there should be a minimum interface between the two protocols.
	Followings are the requirements for the interface from software		Followings are the requirements for the interface from a software
	engineering point of view.		engineering point of view.
	o Necessary modifications to the existing software, namely Mobile		o Necessary modifications to the existing software, namely Mobile
	IPv6 and IPsec/IKE should be kept minimum in order to realize		IPv6 and IPsec/IKE, in order to realize proposed mechanisms,
	proposed mechanism.		should be kept minimum.
	o Proposed mechanism should not be platform dependent. The		o Proposed mechanism should not be platform dependent. The
	mechanism should be based on technology which is commonly		mechanism should be based on technology which is commonly
	available on various platform. This seems to be essential for		available on various platform. This seems to be essential for
	achieving high portability of the implementation which supports		achieving high portability of the implementation which supports
	proposed mechanism.		proposed mechanisms.
	5. PF_KEY Extension for Mobile IPv6		4. PF_KEY Extensions for Mobile IPv6
	In order to fulfil the needs and requirements described in Section 3		In order to fulfil the needs and requirements described in Section 2
	and Section 4 we propose to extend PF_KEY framework so that Mobile		and Section 3 we propose to extend the PF_KEY framework so that
	IPv6 and IPsec/IKE could interact each other. The extension is		Mobile IPv6 and IPsec/IKE could interact with each other.
	primarily for migrating endpoint address of IPsec tunnel from one to
	another, which results in updating IPsec database. A new PF_KEY
	message named MIGRATE was introduced for the mechanism.
	5.1 Overview		4.1. PF_KEY MIGRATE Message
			The first extension is primarily for migrating an endpoint address of
			an IPsec SA pair in tunnel mode from one to another, which results in
			updating IPsec databases. A new PF_KEY message named MIGRATE is
			introduced for the mechanism.
			4.1.1. Overview
	The figure below illustrates how Mobile IPv6 and IPsec/IKE components		The figure below illustrates how Mobile IPv6 and IPsec/IKE components
	interact each other with PF_KEY MIGRATE message in dynamic keying		interact with each other using PF_KEY MIGRATE messages in a dynamic
	scenario. On left top, there is a Mobile IPv6 entity. It may be		keying scenario. On left top, there is a Mobile IPv6 entity. It may
	possible that Mobile IPv6 component is completely implemented inside		be possible that Mobile IPv6 component is completely implemented
	the kernel. In any case, Mobile IPv6 should be the one who issues		inside the kernel (this is the case for our implementations because
	the MIGRATE message. On right top, there is an IKE daemon who is		it makes some facilities and extensions far easier at the cost of
	responsible for establishing security associations required for		maintaining a SPD image in daemons). In any case, Mobile IPv6 should
	Mobile IPv6 operation. In manual keying scenario, the difference is		be the one which issues the MIGRATE messages. On right top, there is
	only that there is no IKE daemon running on the system.		an IKE daemon which is responsible for establishing SAs required for
			Mobile IPv6 operation. In a manual keying scenario, the difference
			is only that there is no IKE daemon running on the system.
	+-------------+ +------------+		+-------------+ +------------+
	| | | |		| | | |
	| Mobile IPv6 | | IKE Daemon |		| Mobile IPv6 | | IKE Daemon |
	| | | |		| | | |
	+-------------+ +------------+		+-------------+ +------------+
	| 1. PF_KEY A 4. Update		| 1. PF_KEY A 4. Update
	| MIGRATE | SPD & SADB		| MIGRATE | SPD & SADB
	+-----------+ +-----------+		+-----------+ +-----------+
	| |		| |
	skipping to change at page 8, line 47 ¶		skipping to change at page 5, line 43 ¶
	Kernel | |		Kernel | |
	+----------+ +----------+		+----------+ +----------+
	| 2. Update | 3. Update		| 2. Update | 3. Update
	V SPD V SADB		V SPD V SADB
	+-----------+ +------------+		+-----------+ +------------+
	| | | |		| | | |
	| SPD | | SADB |		| SPD | | SADB |
	| | | |		| | | |
	+-----------+ +------------+		+-----------+ +------------+
	The primary role of PF_KEY MIGRATE message is to migrate endpoint		The primary role of PF_KEY MIGRATE messages is to migrate endpoint
	address of tunnel mode SA requesting IPsec to update its database		addresses of tunnel mode SA pairs requesting IPsec to update its
	(SPD and SADB). In addition, the message can be used by IKE to		databases (SPD and SADB). In addition, the new message can be used
	enhance its mobility capability. If the PF_KEY MIGRATE message is		by IKE to enhance its mobility capability. When a PF_KEY MIGRATE
	properly processed by the kernel, it will be sent to all open socket		message is properly processed by the kernel, it is sent to all open
	as normal PF_KEY messages. A sequence of processing MIGRATE message		sockets as normal PF_KEY messages. The processing of a sequence of
	is done in following steps:		MIGRATE messages is done in following steps:
	o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket.		o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket.
	o Operating system (kernel) validates the message and checks if		o The operating system (kernel) validates the message and checks if
	corresponding security policy entry exists in SPD.		corresponding security policy entry exists in SPD.
	o If the message is confirmed to be valid, the target security		o When the message is confirmed to be valid, the target SPD entry is
	policy entry is updated according to the MIGRATE message. If		updated according to the MIGRATE message. If there is any target
	there is any target security association found that are also		SA found that are also target of the update, those should also be
	target of the update, those should also be updated.		updated.
	o After the MIGRATE message is successfully processed inside the		o After the MIGRATE message is successfully processed inside the
	kernel, it will be sent to all open PF_KEY socket.		kernel, it will be sent to all open PF_KEY sockets.
	o IKE daemon receives the MIGRATE message from PF_KEY socket and		o The IKE daemon receives the MIGRATE message from its PF_KEY socket
	updates its SPD and SADB. IKE daemon may also update its IKE		and updates its SPD and SADB images. The IKE daemon may also
	connection to keep it alive.		update its state to keep the IKE session alive.
	Note that the way IKE maintains its local copy of SPD is		Note that the way IKE maintains its local copy of SPD (the SPD image)
	implementation specific issue since there is no standard interface to		is implementation specific issue since there is no standard interface
	access SPD. Some IKE implementation may continuously monitor SPD		to access SPD. Some IKE implementation may continuously monitor the
	inside the kernel. Some IKE implementation may expect notification		SPD inside the kernel. Some IKE implementation may expect
	from the kernel when SPD is updated. In either way, the proposed		notification from the kernel when the SPD is modified. In either
	mechanism gives a chance for IKE to keep its SPD up-to-date which is		way, the proposed mechanism gives a chance for IKE to keep its SPD
	significant in Mobile IPv6 operation.		image up-to-date which is significant in Mobile IPv6 operation.
	5.2 Message Sequence		4.1.2. Message Sequence
	Next, we will see how migration takes place in along with home		Next, we will see how migration takes place in along with home
	registration. The figure below shows sequence of mobility signals		registration. The figure below shows sequence of mobility signaling
	and PF_KEY MIGRATE messages while the MN roams around subnets. It is		and PF_KEY MIGRATE messages while the MN roams around links. It is
	assumed that in initial state the tunnel endpoint address for given		assumed that in the initial state the tunnel endpoint address for a
	MN is set as its home address. In initial home registration, the MN		given MN is set as its home address. In the initial home
	and HA migrate the tunnel endpoint address from HoA to CoA1. It		registration, the MN and HA migrate the tunnel endpoint address from
	should be noted that no migration takes place when the MN performs		the HoA to CoA1. It should be noted that no migration takes place
	re-registration since the care-of address remains same. Accordingly,		when the MN performs re-registration since the care-of address
	the MN performs movement and changes its primary care-of address from		remains the same. Accordingly, the MN performs movement and changes
	CoA1 to CoA2. PF_KEY MIGRATE message is issued on both MN and HA.		its primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE
	When the MN returns home, migration takes place updating the endpoint		message is issued on both MN and HA for each direction. When the MN
	address with MN's home address.		returns to home, migration takes place updating the endpoint address
			with the MN's home address.
	MN HA		MN HA
	| |		| |
	~ ~		~ ~
	Movement->| BU (Initial home registration) |		Movement->| BU (Initial home registration) |
	|----------------------------------------->|		|----------------------------------------->|
	MIGRATE ->| BA |<- MIGRATE		MIGRATE ->| BA |<- MIGRATE
	(HoA->CoA1) |<-----------------------------------------| (HoA->CoA1)		(HoA->CoA1) |<-----------------------------------------| (HoA->CoA1)
	| |		| |
	~ BU (Home re-registration) ~		~ BU (Home re-registration) ~
	skipping to change at page 10, line 32 ¶		skipping to change at page 7, line 32 ¶
	MIGRATE ->| BA |<- MIGRATE		MIGRATE ->| BA |<- MIGRATE
	(CoA1->CoA2)|<-----------------------------------------| (CoA1->CoA2)		(CoA1->CoA2)|<-----------------------------------------| (CoA1->CoA2)
	| |		| |
	~ ~		~ ~
	Movement->| BU (Home de-registration) |		Movement->| BU (Home de-registration) |
	|----------------------------------------->|		|----------------------------------------->|
	MIGRATE ->| BA |<- MIGRATE		MIGRATE ->| BA |<- MIGRATE
	(CoA2->HoA) |<-----------------------------------------| (CoA2->HoA)		(CoA2->HoA) |<-----------------------------------------| (CoA2->HoA)
	| |		| |
	5.3 Issuing PF_KEY MIGRATE Message		4.1.3. Issuing PF_KEY MIGRATE Message
	Mobile IPv6 entity (MN or HA) triggers the migration by sending		The Mobile IPv6 entity (MN or HA code) triggers the migration by
	PF_KEY MIGRATE message to the PF_KEY socket. Conceptually, the		sending a PF_KEY MIGRATE message to its PF_KEY socket. Conceptually,
	PF_KEY MIGRATE message should contain following information:		the PF_KEY MIGRATE message should contain following information:
	o Selector information		o Selector information:
	* source address/port		* source address/port
	* destination address/port		* destination address/port
	* upper layer protocol (i.e. Mobility Header)		* upper layer protocol (i.e., Mobility Header)
	* direction (inbound/outbound)		* direction (inbound/outbound)
	o Old SA information		o Old SA information:
	* old source address of IPsec tunnel		* old source endpoint address
	* old destination address of IPsec tunnel		* old destination endpoint address
	* IPsec protocol (ESP/AH)		* IPsec protocol (ESP/AH)
	* mode (Tunnel)		* mode (Tunnel)
	o New SA information		o New SA information:
	* new source address of IPsec tunnel		* new source endpoint address
	* new destination address of IPsec tunnel		* new destination endpoint address
	* IPsec protocol (ESP/AH)		* IPsec protocol (ESP/AH)
	* mode (Tunnel)		* mode (Tunnel)
	Selector information is required for specifying target security		Selector information is required for specifying the target SPD entry
	policy entry to be updated. It should contain information required		to be updated. Basically the information should contain necessary
	for selector as specified in [RFC2401]. Plus, direction of the		elements which characterize traffic selector as specified in
	security policy (inbound/outbound) should be provided. Old SA		[RFC2401]. With regard to the upper layer protocol, when the Mobile
	information is used to specify target security association to be		IPv6 stack is not fully aware of IPsec configuration, an wild-card
	updated. Source and destination address of the target entry should		value could be given. In such case, an upper layer protocol
	be overwritten with the ones included in new SA information. Note		information should not be taken into account for searching SPD entry.
	that IPsec protocol and mode are not updated by the PF_KEY MIGRATE		Plus, the direction of the security policy (inbound/outbound) should
	message.		be provided. The old SA information is used to specify target
			security association to be updated. The source and destination
			addresses of the target entry should be overwritten with the ones
			included in the new SA information. Note that the IPsec protocol and
			mode fields should not be updated by a PF_KEY MIGRATE message.
	The PF_KEY MIGRATE message should be formed based on security policy		A PF_KEY MIGRATE message should be formed based on security policy
	configuration and binding record. Selector information and some		configuration and binding record. The selector information and some
	parts of the SA information (IPsec protocol and mode) should be taken		parts of the SA information (IPsec protocol and mode) should be taken
	from policy configuration. The rest of the information should be		from the policy configuration. The rest of the information should be
	taken from sequential binding information. For example, in the case		taken from the sequential binding information. For example, in the
	where the MN updates its inbound security policy and corresponding		case where the MN updates its inbound security policy and
	tunnel mode security association, the old source address of the IPsec		corresponding tunnel mode SA pair, the old source address should be
	tunnel should be set as its previous CoA, and the new source address		set as its previous CoA, and the new source address should be set as
	of the IPsec tunnel should be set as its current CoA. Hence, MN		its current CoA. Hence, the MN should sequentially keep track of its
	should sequentially keep track of its CoA record. Such information		CoA record. Such information shall be stored in binding update list
	shall be stored in binding update list entry. For the same reason,		entry. For the same reason, the HA should keep track of previous
	HA should keep track of previous CoA of MN. Such information shall		CoAs of MNs. Such information shall be stored in binding cache
	be stored in binding cache entry.		entry.
	Additionally, a piece of information which indicates mobility		Additionally, a piece of information which indicates a mobility
	capability of IKE (K-bit) should be provided by any means. This		capability of IKE (K-bit) should be provided by any means. This
	makes it possible for IKE to see if there is a need to update its IKE		makes it possible for IKE to see if there is a need to update its
	endpoint in accordance with PF_KEY MIGRATE message.		state (IKE endpoint addresses) in accordance with PF_KEY MIGRATE
			messages.
	Detailed message format of PF_KEY MIGRATE is provided in Appendix A.		A detailed message format of PF_KEY MIGRATE is provided in
			Appendix A.
	5.4 Processing PF_KEY MIGRATE Message		4.1.4. Processing PF_KEY MIGRATE Message
	Since a PF_KEY MIGRATE message is applied to single security policy		Since a PF_KEY MIGRATE message is applied to a single SPD entry, the
	entry, kernel should first check validity of the message. If the		kernel should first check validity of the message. If the message is
	message is invalid, EINVAL error MUST be returned as a return value		invalid, an EINVAL error MUST be returned as a return value for the
	for the write() operation made to the PF_KEY socket. After the		write() operation made to the PF_KEY socket. After the validation,
	validation, kernel checks if target security policy entry really		the kernel checks if the target SPD entry really exists. If no entry
	exists in SPD. If there is no entry found, ESRCH error MUST be		is found, an ENOENT error MUST be returned. If a SPD entry is found
	returned. In any error case, the message must not have any effect on		and successfully updated, a success (0) MUST be returned regardless
	SPD and SADB and migration becomes incomplete.		of subsequent result of SADB lookup/update. Note that there may be a
			case where a corresponding SADB entry does not exist even if a SPD
			entry is successfully updated. In any error case, a PF_KEY MIGRATE
			message MUST NOT have any effect on the SPD and SADB.
	With respect to the behavior of normal process (including IKE daemon)		With respect to the behavior of a normal process (including the IKE
	who receives PF_KEY MIGRATE message from PF_KEY socket, it SHOULD		daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket,
	first check if the message does not include error information. If		it SHOULD first check if the message does not include erroneous
	there is any error indicated, the process MUST silently discard the		information. When there is any error indicated, the process MUST
	PF_KEY MIGRATE message. Otherwise, processing of the message may		silently discard the PF_KEY MIGRATE message. Otherwise, the
	continue.		processing of the message may continue.
	5.5 Applicability of PF_KEY MIGRATE to Other Systems		4.1.5. Applicability of PF_KEY MIGRATE to Other Systems
	It should be noted that PF_KEY MIGRATE is also applicable to other		It should be noted that the PF_KEY MIGRATE extension is also
	systems than Mobile IPv6. For example, it can be used in a scenario		applicable to other systems than Mobile IPv6 and/or IKEv1. For
	where IPsec/IKE enabled node establishes tunnel mode security		example, it can be used in a scenario where an IPsec/IKE enabled node
	association with its Security Gateway while it roams around the		establishes tunnel mode SAs association with its Security Gateway
	network (aka "road warrior"). Security policy is set as such that		while it roams around the network (aka "road warrior"). The security
	all traffic should bi-directionally go through the IPsec tunnel. In		policy is set as such that all traffic should bi-directionally go
	such case, migration of the tunnel endpoint address can be handled by		through the tunnel IPsec SAs. In such case, the migration of a
	PF_KEY MIGRATE message. Each time the node changes its attachment		tunnel endpoint address can be handled by PF_KEY MIGRATE messages.
	point to the Internet, PF_KEY MIGRATE should be issued to the system.		Each time the node changes its attachment point to the Internet,
	Consequently, the IPsec database (SPD and SADB) shall be properly		PF_KEY MIGRATE messages should be issued to the system.
			Consequently, the IPsec databases (SPD and SADB) shall be properly
	updated.		updated.
	It is also essential to keep design of the mechanism protocol		It is also essential to keep design of the mechanism protocol
	independent. More specifically, PF_KEY MIGRATE should be able to		independent. More specifically, the PF_KEY MIGRATE extension should
	work on both IPv4 and IPv6. In order to achieve this, IP addresses		be able to work on both IPv4 and IPv6. In order to achieve this, the
	to be stored in selector and security association information should		IP addresses to be stored in selector and SA information should be
	be handled in a protocol-independent manner.		handled in a protocol-independent manner.
	5.6 Limitation of PF_KEY MIGRATE		4.1.6. Limitation of PF_KEY MIGRATE
	Currently, Security Parameter Index (SPI) is not included in the old		Currently, a Security Parameter Index (SPI) is not included in the
	SA information to specify target security association entry. This		old SA information to specify target SADB entry. This helps to
	helps to lessen operational burden of Mobile IPv6. However, this		lessen operational burden of Mobile IPv6. However, this
	simplification can produce ambiguity in searching for the target		simplification can produce ambiguity in searching for the target
	security association entry. Further considerations and improvements		security association entry. When the unique SPD level is available,
	needed.		it should be use because it avoids this problem both by marking the
			SAs to update and by limiting SA sharing.
	It should be noted that delivery of PF_KEY MIGRATE message cannot be		It should be noted that delivery of PF_KEY MIGRATE messages cannot be
	guaranteed, which is common to other PF_KEY messages. It may be		guaranteed, which is common to other PF_KEY messages. It may be
	possible that the MIGRATE message is lost. In such case, there will		possible that a MIGRATE message is lost. In such case, there will be
	be inconsistency between the binding record managed by Mobile IPv6		inconsistency between the binding record managed by Mobile IPv6 and
	and IPsec database inside the kernel. Once a PF_KEY MIGRATE message		IPsec database inside the kernel. Once a PF_KEY MIGRATE message is
	is lost, it would not be possible for the receiver to process		lost, it would not be possible for the receiver to process some
	subsequent MIGRATE message properly. Initialization of Mobile IPv6		subsequent MIGRATE messages properly. Reinitialization of the Mobile
	stack and IPsec database may be needed for recovery. Further		IPv6 stack and IPsec databases may be needed for recovery.
	improvements should be made.
	6. Necessary Modifications to Mobile IPv6 and IPsec/IKE		4.2. PF_KEY Packet Extension
			In the initial stage of MIPv6 operation known as the bootstrapping
			process, the MN and HA probably need to establish SAs from scratch in
			order to start the MIPv6 operation. If IKE is used to maintain the
			SAs, the MN and HA are required to establish a transport mode SA pair
			so that the MN could make the initial protected home registration to
			the HA. As mentioned in RFC 3776 [RFC3776], the IKE negotiation
			should be done carefully in terms of handling the identity of the MN.
			More specifically, IKE must be run over the MN's primary CoA while
			the SA pair should be based on the MN's HoA. Note that the HoA
			cannot be used prior to the initial home registration. This is an
			exceptional case of IKE negotiation in a sense that the peer address
			(the address on which IKE runs) and the IP address to be used as
			selector for the SAs are different. Since IKE should not be required
			to maintain mobility state, there is a need to guide IKE to make the
			right choice for address/identity.
			A simple solution for this explicit notification can be provided by
			extending PF_KEY framework by including information of the triggering
			packet into SADB_ACQUIRE messages. This extension allows receiver of
			a SADB_ACQUIRE message to determine which address to use for what
			purpose, i.e., to recognize the exceptional case as all the needed
			informations are already in the home registration binding update. As
			shown below, a SADB_ACQUIRE message MAY contain an extension which
			contains the triggering packet (the whole packet, information
			extracted from it by the kernel or as we recommend enough of the
			beginning of it).
			<base, address(SD), address(P)*, identity(SD)*,
			sensitivity*, proposal, packet*>
			4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message
			The IPsec subsystem MAY include a Packet Extension to a SADB_ACQUIRE
			message when it is triggered by an output of data packet. The Packet
			Extension simply contains the information of the triggering packet.
			Like any other extension headers specified in RFC 2367 [RFC2367], a
			Packet Extension (SADB_X_EXT_PACKET) MUST follow the basic rules and
			be formulated in the type-length-value format. A redundant part of
			the original IP packet (i.e., payload/tralier) MAY be eliminated.
			More than one Packet Extension header MUST NOT be appended to the
			message. A sadb_x_packet extension header is followed by an IP
			packet which has triggered the SADB_ACQUIRE message. Note that the
			Packet Extension is protocol independent, which means that the
			triggering packet included in the extension header could be either
			IPv4 or IPv6. The address family of the triggering packet can be
			recognized by the first 4 bits of the IP packet.
			struct sadb_x_packet {
			uint16_t sadb_packet_len;
			uint16_t sadb_packet_exttype;
			};
			/* sizeof(struct sadb_x_packet) == 4 */
			/* followed by an IP packet header which triggered
			the SADB_ACQUIRE message */
			4.2.2. Processing SADB_ACQUIRE Message with Packet Extension
			A receiver of a SADB_ACQUIRE message with a Packet Extension MAY
			extract and process the extension header. A MIPv6-aware IKE daemon
			should be able to process a Packet Extension which includes the IPv6
			packet which carries an initial home registration BU message. Such
			packet includes a home address destination option which contains the
			primary CoA of the MN and the source address field of the IPv6 header
			contains the HoA of the MN (note the exact layout depends on the
			place of the IPsec acquiring code, we assume here its place follows
			the section 11.3.2 of [RFC3775]). The destination address field of
			the IPv6 header contains the address of the HA, the mobility header a
			BU (type 5) for home registration (H flag set to one).
			Receipt of SADB_ACQUIRE Message with Packet Extension containing BU
			message implies that IKE is required to establish SAs for the MIPv6
			home registration. Accordingly, the IKE should be able to make a
			right choice of address selection. The CoA must be used as a peer
			address in the IKE negotiation and the HoA should be used as selector
			of transport mode SAs and as endpoint address of tunnel mode SAs.
			4.2.3. Relation of Packet Extension to IKEv2
			In IKEv2 [I-D.ietf-ipsec-ikev2], when the initiator has requested to
			establish SAs triggered by a data packet, the first traffic selector
			of TSi and TSr should reflect the triggering packet. Therefore,
			IKEv2 could take advantage of Packet Extensions when some information
			from triggering packets are needed for a traffic selector
			negotiation.
			5. Necessary Modifications to Mobile IPv6 and IPsec/IKE
	In order to realize the proposed mechanism, there are some necessary		In order to realize the proposed mechanism, there are some necessary
	modifications to Mobile IPv6 and IPsec/IKE. Following are the		modifications to Mobile IPv6 and IPsec/IKE. Following are the
	summary of necessary modifications, which could be of interest to		summary of necessary modifications, which could be of interest to
	implementators of Mobile IPv6/IPsec/IKE.		implementors of Mobile IPv6 and/or IPsec/IKE.
	o Modifications to Mobile IPv6:		o Modifications to Mobile IPv6:
	* Mobile IPv6 makes an access to PF_KEY socket. In particular,		* The Mobile IPv6 code can make an access to PF_KEY socket. In
	Mobile IPv6 should have privilege to write data to PF_KEY		particular, the Mobile IPv6 code should have privilege to write
	socket.		messages into a PF_KEY socket.
	* Issue PF_KEY MIGRATE message. In order to form the MIGRATE		* Issuing PF_KEY MIGRATE messages: in order to form MIGRATE
	message, it is required that Mobile IPv6 should be aware of its		messages, it is required that the Mobile IPv6 code has some
	IPsec (security policy) configuration and precise binding		knowledge of its IPsec configuration and precise binding
	record.		record. The Mobile IPv6 code may be aware of exact IPsec
			configuration in form or security policy. It would also be
			possible that the Mobile IPv6 code is only aware of minimum
			IPsec configuration whether if IPsec is utilized or not.
	o Modifications to IPsec:		o Modifications to IPsec:
	* Processing of PF_KEY MIGRATE message. Kernel should be able to		* Processing PF_KEY MIGRATE messages: the kernel should be able
	process the PF_KEY MIGRATE sent by Mobile IPv6. Unless the		to process PF_KEY MIGRATE messages sent by the Mobile IPv6
	message is invalid, it should be sent to all open PF_KEY		code. Unless the message is invalid, it should be sent to all
	socket.		open PF_KEY sockets.
			* Enabling Packet Extensions (SADB_X_EXT_PACKET): the kernel
			should be able to append a SADB_X_EXT_PACKET extension to
			SADB_MIGRATE messages when they are triggered by an output of a
			data packet.
	o Modifications to IKE:		o Modifications to IKE:
	* Processing of PF_KEY MIGRATE message. IKE may update its local		* Processing PF_KEY MIGRATE messages: the IKE code may update its
	copy of IPsec database (SPD and SADB) in accordance with		local copy of IPsec databases (SPD and SADB) in accordance with
	received PF_KEY MIGRATE message. In addition, it may update		received PF_KEY MIGRATE messages. In addition, it may update
	its IKE connection with new endpoint address indicated by the		its state / IKE session with new endpoint addresses indicated
	PF_KEY MIGRATE message.		by PF_KEY MIGRATE messages.
			* Processing of Packet Extensions (SADB_X_EXT_PACKET): the IKE
			code may process SADB_X_EXT_PACKET extensions and extract
			necessary information from triggering packets. In order for
			the IKE code to be MIPv6-aware, it should properly extract the
			home address, care-of address, and HA address from IP packets
			which carry home registration BU messages.
	7. Security Considerations		6. Security Considerations
	There is no security considerations newly raised by the mechanism		There is no specific security considerations for the mechanisms
	proposed in this document.		introduced by the document but as it should make deployment of
			dynamic keying in Mobile IPv6 environments easier it should improve
			the security of such environments. Note that dynamic keying is known
			to be more secure (it provides anti-replay for instance) and far more
			scalable.
	8. Conclusion		7. Conclusion
	o There are needs for Mobile IPv6 and IPsec/IKE to interact each		o There is a need for Mobile IPv6 and IPsec/IKE to interact with
	other to provide full support of IPsec security functions.		each other to provide full support of IPsec security functions.
	o An extension to PF_KEY framework (PF_KEY MIGRATE message) was		o An extension to the PF_KEY framework (PF_KEY MIGRATE message) is
	proposed, which makes it possible for the IPsec/IKE to migrate		proposed, which makes it possible for the IPsec/IKE to migrate an
	endpoint address of the IPsec tunnel from one to another.		endpoint address of tunnel IPsec SAs from one to another.
	o PF_KEY MIGRATE message also makes it possible for IKE to survive		o PF_KEY MIGRATE messages also make it possible for IKE to survive
	movements by updating its IKE connection.		movements by updating its IKE session.
	o In order for the IKE to perform key negotiations and rekeying,		o In order for the IKE to perform key negotiations and rekeying,
	effort should be made to keep its SPD up-to-date.		effort should be made to keep its SPD image up-to-date.
	o The proposed mechanism was implemented on both Linux and BSD		o The proposed mechanism was implemented on both Linux and BSD
	platform and confirmed to be working well.		platforms and confirmed to be working well.
	o Currently, large portion of the proposed mechanism is		o Currently, large portion of the proposed mechanism is
	implementation dependent due to lack of standard interface to		implementation dependent due to lack of standard interface to
	access SPD (PF_POLICY?).		access the SPD (PF_POLICY?).
	9. References		8. References
			[I-D.ietf-ipsec-ikev2]
			Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
			draft-ietf-ipsec-ikev2-17 (work in progress),
			October 2004.
	[I-D.ietf-ipsec-rfc2401bis]		[I-D.ietf-ipsec-rfc2401bis]
	Kent, S. and K. Seo, "Security Architecture for the		Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol",		Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
	Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December		in progress), April 2005.
	2004.
	[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management		[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
	API, Version 2", RFC 2367, July 1998.		Management API, Version 2", RFC 2367, July 1998.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to		[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
	Protect Mobile IPv6 Signaling Between Mobile Nodes and		Protect Mobile IPv6 Signaling Between Mobile Nodes and
	Home Agents", RFC 3776, June 2004.		Home Agents", RFC 3776, June 2004.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, January 2005.		RFC 3963, January 2005.
	Authors' Addresses
	Shinta Sugimoto
	Ericsson Research Japan
	Koraku Mori Building
	1-4-14, Koraku, Bunkyo-ku
	Tokyo 112-0004
	Japan
	Phone: +81 3 3830 2241
	Email: shinta.sugimoto@ericsson.com
	Francis Dupont
	Point6
	c/o GET/ENST Bretagne
	2 rue de la Chataigneraie
	CS 17607
	35576 Cesson-Sevigne Cedex
	France
	Fax: +33 2 99 12 70 30
	Email: Francis.Dupont@enst-bretagne.fr
	Appendix A. PF_KEY MIGRATE Message Format		Appendix A. PF_KEY MIGRATE Message Format
	The figure below shows the message format of PF_KEY MIGRATION. The		The figure below shows the message format of PF_KEY MIGRATE. The
	message consists of 6 parts (boundary of each part is marked with		message consists of 6 parts (boundary of each part is marked with
	">"). The message starts with PF_KEY base message header followed by		">"). The message starts with PF_KEY base message header followed by
	two address extensions. A pair of address extensions hold source and		two address extensions. A pair of address extensions hold source and
	destination address of the selector. Rest of the message are		destination address of the selector. Rest of the message are
	specific to IPsec implementation of BSD. sadb_x_policy{} structure		specific to IPsec implementation on BSD. sadb_x_policy{} structure
	holds additional information of security policy. The last part of		holds additional information of security policy. The last part of
	the message is a pair of sadb_x_ipsecrequest{} structures that hold		the message is a pair of sadb_x_ipsecrequest{} structures that hold
	old and new SA information.		old and new SA information.
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype |		| ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| sadb_msg_len | sadb_msg_reserved |		| sadb_msg_len | sadb_msg_reserved |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	skipping to change at page 18, line 24 ¶		skipping to change at page 15, line 24 ¶
	| sadb_x_ipsecrequest_reqid |		| sadb_x_ipsecrequest_reqid |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| sadb_x_ipsecrequest_reserved2 |		| sadb_x_ipsecrequest_reserved2 |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	~ new tunnel source address (64-bit aligned sockaddr) ~		~ new tunnel source address (64-bit aligned sockaddr) ~
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	~ new tunnel destination address (64-bit aligned sockaddr) ~		~ new tunnel destination address (64-bit aligned sockaddr) ~
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Following is a structure of PF_KEY base message header specified in		Following is a structure of PF_KEY base message header specified in
	[RFC2367]. A new message type for PF_KEY MIGRATE (i.e.		[RFC2367]. A new message type for PF_KEY MIGRATE (i.e.,
	SADB_X_MIGRATE) should be specified in member sadb_msg_type.		SADB_X_MIGRATE) should be specified in member sadb_msg_type.
	struct sadb_msg {		struct sadb_msg {
	uint8_t sadb_msg_version;		uint8_t sadb_msg_version;
	uint8_t sadb_msg_type;		uint8_t sadb_msg_type;
	uint8_t sadb_msg_errno;		uint8_t sadb_msg_errno;
	uint8_t sadb_msg_satype;		uint8_t sadb_msg_satype;
	uint16_t sadb_msg_len;		uint16_t sadb_msg_len;
	uint16_t sadb_msg_reserved;		uint16_t sadb_msg_reserved;
	uint32_t sadb_msg_seq;		uint32_t sadb_msg_seq;
	skipping to change at page 20, line 7 ¶		skipping to change at page 16, line 36 ¶
	uint16_t sadb_x_ipsecrequest_proto;		uint16_t sadb_x_ipsecrequest_proto;
	uint8_t sadb_x_ipsecrequest_mode;		uint8_t sadb_x_ipsecrequest_mode;
	uint8_t sadb_x_ipsecrequest_level;		uint8_t sadb_x_ipsecrequest_level;
	uint16_t sadb_x_ipsecrequest_reserved1;		uint16_t sadb_x_ipsecrequest_reserved1;
	uint32_t sadb_x_ipsecrequest_reqid;		uint32_t sadb_x_ipsecrequest_reqid;
	uint32_t sadb_x_ipsecrequest_reserved2;		uint32_t sadb_x_ipsecrequest_reserved2;
	};		};
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	The authors gratefully acknowledges the contribution of: Masahide		The authors gratefully acknowledge the contribution of: Kazunori
	Nakamura, Kazunori Miyazawa, Noriaki Takamiya.		Miyazawa, Noriaki Takamiya, Shoichi Sakane, Mitsuru Kanda, Keiichi
			Shima, Tsuyoshi Momose and other members from USAGI Project and KAME
			Project.
			Authors' Addresses
			Shinta Sugimoto
			Nippon Ericsson K.K.
			Koraku Mori Building
			1-4-14, Koraku, Bunkyo-ku
			Tokyo 112-0004
			Japan
			Phone: +81 3 3830 2241
			Email: shinta.sugimoto@ericsson.com
			Francis Dupont
			Point6
			c/o GET/ENST Bretagne
			2 rue de la Chataigneraie
			CS 17607
			35576 Cesson-Sevigne Cedex
			France
			Fax: +33 2 99 12 70 30
			Email: Francis.Dupont@enst-bretagne.fr
			Masahide Nakamura
			Hitachi Communication Technologies, Ltd.
			216 Totsuka-cho, Totsuka-ku
			Yokohama 244-8567
			Japan
			Phone: +81 45 865 7003
			Email: masahide_nakamura@hitachi-com.co.jp
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 79 change blocks.
	347 lines changed or deleted		445 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/