< draft-yegin-pana-unspecified-addr-00.txt		draft-yegin-pana-unspecified-addr-01.txt >
	Network Working Group A. Yegin		Network Working Group A. Yegin
	Internet-Draft Samsung		Internet-Draft Samsung
	Intended status: Standards Track Y. Ohba		Intended status: Standards Track Y. Ohba
	Expires: September 2, 2010 Toshiba		Expires: September 9, 2010 Toshiba
	March 1, 2010		L. Morand
			Orange Labs
			J. Kaippallimalil
			Huawei USA
			March 8, 2010
	Protocol for Carrying Authentication for Network Access (PANA) with IPv4		Protocol for Carrying Authentication for Network Access (PANA) with IPv4
	Unspecified Address		Unspecified Address
	draft-yegin-pana-unspecified-addr-00		draft-yegin-pana-unspecified-addr-01
	Abstract		Abstract
	This document defines how PANA client (PaC) can perform PANA		This document defines how PANA client (PaC) can perform PANA
	authentication prior to configuring an IP address.		authentication prior to configuring an IP address.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 43 ¶
	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 September 2, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 23 ¶
	described in the BSD License.		described in the BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specification of Requirements . . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
	2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. PaC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. PaC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. PAA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. PAA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6		5. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. PAC-L2-ADDR AVP . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Token AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Message Size Considerations . . . . . . . . . . . . . . . . . . 6		6. Message Size Considerations . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	PANA (Protocol for carrying Authentication for Network Access)		PANA (Protocol for carrying Authentication for Network Access)
	[RFC5191] as a UDP-based protocol operates with the assumption that		[RFC5191] as a UDP-based protocol operates with the assumption that
	the PANA client (PaC) is already configured with an IP address.		the PANA client (PaC) is already configured with an IP address.
	Private IPv4, globally-routable IPv4 [RFC1918] or IPv6, IPv4 or IPv6		Private IPv4, globally-routable IPv4 [RFC1918] or IPv6, IPv4 or IPv6
	link-local are the types of addresses that can be configured by PaCs		link-local are the types of addresses that can be configured by PaCs
	prior to running PANA [RFC5193].		prior to running PANA [RFC5193].
	In case the PaC and the PANA Authentication Agent (PAA) are on the		In case the PaC and the PANA Authentication Agent (PAA) are on the
	same IP subnet, PaC can run PANA with the PAA prior to configuring an		same IP subnet where all hosts in the subnet can be reached in one
	IP address.		routing hop, the PaC can run PANA with the PAA prior to configuring
			an IP address.
	This document defines an extension of PANA to allow the PaC to use		This document defines an extension of PANA to allow the PaC to use
	IPv4 unspecified address (0.0.0.0) until it gets authenticated/		IPv4 unspecified address (0.0.0.0) until it gets authenticated/
	authorized; and configures an IP address afterwards (possibly using		authorized; and configures an IP address afterwards (possibly using
	DHCP). Such a feature is already available in Mobile IPv4 [RFC3344]		DHCP). Such a feature is already available in Mobile IPv4 [RFC3344]
	where MN can use unspecified IPv4 address with Mobile IP protocol		where MN can use unspecified IPv4 address with Mobile IP protocol
	until it is assigned a home address, and also DHCP [RFC2131].		until it is assigned a home address, and also DHCP [RFC2131].
	1.1. Specification of Requirements		1.1. Specification of Requirements
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	Figure 1 is an example call flow that illustrates use of unspecified		Figure 1 is an example call flow that illustrates use of unspecified
	IPv4 address with the PaC during PANA authentication. Note that		IPv4 address with the PaC during PANA authentication. Note that
	there can be other ways for combining DHCP and PANA call flows.		there can be other ways for combining DHCP and PANA call flows.
	PaC PAA AAA		PaC PAA AAA
	| | |		| | |
	| | |		| | |
	| | |		| | |
	|--1. PANA Client initiation-------->| |		|--1. PANA Client initiation(Token)->| |
	| | |		| | |
	|<-2. PANA Auth Req -----------------| |		|<-2. PANA Auth Req(Token)-----------| |
	| | |		| | |
	|--3. PANA Auth Ans ---------------->| |		|--3. PANA Auth Ans ---------------->| |
	| | |		| | |
	| |-4. RADIUS Access ->|		| |-4. RADIUS Access ->|
	| | Request (EAP) |		| | Request (EAP) |
	| | |		| | |
	| |<-5. RADIUS Access--|		| |<-5. RADIUS Access--|
	| | (EAP Success) |		| | (EAP Success) |
	|<-6. PANA Auth Req -----------------| |		|<-6. PANA Auth Req -----------------| |
	| | |		| | |
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	| | |		| | |
	|--10. DHCP Request----------------->| |		|--10. DHCP Request----------------->| |
	| | |		| | |
	|<-11. DHCP Ack----------------------| |		|<-11. DHCP Ack----------------------| |
	| | |		| | |
	|<-12. IP session data traffic----------------> |		|<-12. IP session data traffic----------------> |
	| | |		| | |
	Figure 1: Example Call Flow for PANA with IPv4 Unspecified Address		Figure 1: Example Call Flow for PANA with IPv4 Unspecified Address
	Step 1: The PaC initiates PANA by sending a broadcasted PCI.		Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying
			a Token AVP that contains a random value generated by the PaC.
	The source IPv4 address of the PCI is set to 0.0.0.0. The		The source IPv4 address of the PCI is set to 0.0.0.0. The
	destination IPv4 address is set to 255.255.255.255.		destination IPv4 address is set to 255.255.255.255.
	Step 2: The PAA responds with a PAR message which has its source IPv4		Step 2: The PAA responds with a PAR message that includes the token
	address set to the PAA's IP address, and the destination IPv4 address		generated by the PaC. The PAR message has its source IPv4 address
	is set to 255.255.255.255. If the PAA is capable of retrieving the		set to the PAA's IP address, and the destination IPv4 address is set
	PaC's L2 address from incoming PCI, then the PAR is L2-unicasted		to 255.255.255.255. If the PAA is capable of retrieving the PaC's L2
	using that L2 address. Otherwise, the PAR message will be L2-		address from incoming PCI, then the PAR is L2-unicast using that L2
	broadcasted.		address. Otherwise, the PAR message will be L2-broadcast.
	The PaC discovers the PAA's IPv4 address when it receives the PAR		The PaC discovers the PAA's IPv4 address when it receives the PAR
	message.		message.
	Step 3: The PaC sends the PAN message to the PAA's newly discovered		Step 3: The PaC sends the PAN message to the PAA's newly discovered
	IPv4 address.		IPv4 address.
	Steps 4-7: PANA and RADIUS carrying out the selected EAP method.		Steps 4-7: PANA and RADIUS carrying out the selected EAP method.
	Steps 8-11: Now that the PaC is authenticated, it proceeds to		Steps 8-11: Now that the PaC is authenticated, it proceeds to
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 24 ¶
	unspecified address.		unspecified address.
	Step 12: The PaC can transmit and receive IP data packets using its		Step 12: The PaC can transmit and receive IP data packets using its
	IP address.		IP address.
	A PAA implementation may not be capable of retrieving the PaC's L2		A PAA implementation may not be capable of retrieving the PaC's L2
	address from L2 header of the incoming PANA messages, or be able to		address from L2 header of the incoming PANA messages, or be able to
	send a L2-unicast even if it could retrieve the address. In such a		send a L2-unicast even if it could retrieve the address. In such a
	case, the PAA sends PANA messages as L2-broadcast. In order to		case, the PAA sends PANA messages as L2-broadcast. In order to
	prevent other PaCs from processing the messages destined for a		prevent other PaCs from processing the messages destined for a
	specific PaC, each PaC is required to supply its own L2 address as a		specific PaC, each PaC is required to supply a randomly generated
	payload AVP to PCI and expect it to be echoed back by the PAA in the		token as a payload AVP to PCI and expect it to be echoed back by the
	initial PAR. PAC-L2-ADDR AVP is defined for this purpose.		PAA in the initial PAR. Token AVP is defined for this purpose.
	[TBD: Or, alternatively a randomly-generated token can be carried
	instead of the L2 address. It serves the same purpose.]
	Note that any message beyond Step 2 would include the PAA-assigned		Note that any message beyond Step 2 would include the PAA-assigned
	and PaC-acknowledged PANA Session Id, hence use of PAC-L2-ADDR AVP is		and PaC-acknowledged PANA Session Id, hence use of Token AVP is not
	not needed for those messages.		needed for those messages.
	3. PaC Behavior		3. PaC Behavior
	A PaC shall use unspecified address as its source IP address until it		A PaC SHALL use unspecified address as its source IP address until it
	configures another IP address. The PaC shall send a PCI that carries		configures another IP address. The PaC SHALL send a PCI carrying a
	its L2 address in the PAC-L2-ADDR AVP. The PaC shall not include		Token AVP. The PaC SHOULD NOT include a Token AVP in any other
	PAC-L2-ADDR AVP in any other message.		message.
	The PaC shall silently drop any PAR that carries a PAC-L2-ADDR AVP		The PaC SHALL silently drop any PAR that carries a Token AVP whose
	whose L2 address payload does not match the L2 address on the		token value does not match the one contained in the PCI sent by the
	receiving interface of the PaC.		PaC.
	Any legacy PaC that does not implement this specification would		The PaC, before it sends the first PAN to the PAA, SHALL silently
	automatically drop the incoming PAR that carries the PAC-L2-ADDR AVP		drop any PAR that is L2-broadcast and without carrying a Token AVP.
	as this is an unrecognized AVP. This is the standard behavior
	defined in [RFC5191].		Any legacy PaC that does not implement this specification will
			automatically drop the incoming PAR that carries the Token AVP as
			this is an unrecognized AVP. This is the standard behavior defined
			in [RFC5191].
	4. PAA Behavior		4. PAA Behavior
	If a PAA receives a PCI whose source IP address is unspecified but		If a PAA receives a PCI whose source IP address is unspecified but
	that does not carry a PAC-L2-ADDR AVP, then it shall drop the PCI.		that does not carry a Token AVP, then it SHALL drop the PCI. The PAA
	The PAA shall drop any message with PAC-L2-ADDR AVP if the message		SHALL ignore a Token AVP if it is contained in any message other than
	type is other than PCI. When the PAA is capable of retrieving the		PCI.
	source L2 address of the incoming packets, if the address retrieved
	does not match the address in the PAC-L2-ADDR AVP payload, then the
	PAA shall drop the packet.
	When the PAA needs to send a packet to a PaC that is using an		When the PAA needs to send a packet to a PaC that is using an
	unspecified IP address, then the PAA shall set the destination IP		unspecified IP address, then the PAA shall set the destination IP
	address to 255.255.255.255. The PAA should set the destination L2		address to 255.255.255.255. The PAA SHOULD set the destination L2
	address to the source L2 address retrieved from the incoming PaC		address to the source L2 address retrieved from the incoming PaC
	packet, when possible; otherwise set to L2 broadcast address. If		packet, when possible; otherwise set to L2 broadcast address. If
	this is the very first PAR message in PANA session, then the PAA		this is the very first PAR message sent to L2 broadcast address in
	shall include a PAC-L2-ADDR AVP with the payload set to the L2		response to a PCI message containing a Token AVP, then the PAA SHALL
	address of the PaC. The PAA shall not include PAC-L2-ADDR AVP in any		include a Token AVP copied from the PCI. The PAA SHOULD NOT include
	other PANA message, as an already-assigned PANA Session Id serves the		a Token AVP in any other PANA message, as an already-assigned PANA
	need.		Session Id serves the need.
	The PAA shall set the 'I' (IP Reconfiguration) bit of PAR messages in		The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages in
	authentication and authorization phase so that the PaC proceeds to IP		authentication and authorization phase so that the PaC proceeds to IP
	address configuration.		address configuration.
			Any legacy PAA that does not implement this specification would
			automatically drop the incoming PCI that carries the Token AVP as
			this is an unrecognized AVP. This is the standard behavior defined
			in [RFC5191].
	5. AVP Definition		5. AVP Definition
	This document defines one new AVP as described below.		This document defines one new AVP as described below.
	5.1. PAC-L2-ADDR AVP		5.1. Token AVP
	The PAC-L2-ADDR AVP (AVP Code TBD) contains a link-layer address of		The Token AVP (AVP Code TBD) is of type Unsigned64 containing a
	the PaC. The first two octets represents the AddressType, which		random value generated by the PaC.
	contains an Address Family defined in [IANAADFAM]. Address families
	other than that are defined for link-layer MUST NOT be used for this
	AVP. The remaining octets encode the address value. The length of
	the address value is determined by the AddressType. The AddressType
	is used to discriminate the content and format of the remaining
	octets for the address value.
	6. Message Size Considerations		6. Message Size Considerations
	Since IP fragmentation for IP packets using unspecified address is		Since IP fragmentation for IP packets using unspecified address is
	prohibited, link-layer MTU needs to be no less than the IP packet		prohibited, link-layer MTU needs to be no less than the IP packet
	size carrying the largest PANA message in the case where EAP message		size carrying the largest PANA message in the case where EAP message
	size is the same as the minimum EAP MTU size (i.e., 1020 octets		size is the same as the minimum EAP MTU size (i.e., 1020 octets
	[RFC3748]). Such a PANA message is the very first PANA-Auth-Request		[RFC3748]). Such a PANA message is the very first PANA-Auth-Request
	message in Authentication and Authorization phase carrying the		message in Authentication and Authorization phase carrying the
	following AVPs.		following AVPs.
	o An EAP-Payload AVP that carries an EAP-Request of size being equal		o An EAP-Payload AVP that carries an EAP-Request of size being equal
	to the minimum EAP MTU size. The size of such an AVP is 1020 + 8		to the minimum EAP MTU size. The size of such an AVP is 1020 + 8
	= 1028 octets.		= 1028 octets.
	o A Nonce AVP that carries the largest nonce of size 256 octets.		o A Nonce AVP that carries the largest nonce of size 256 octets.
	The size of such an AVP is 256 + 8 = 264 octets.		The size of such an AVP is 256 + 8 = 264 octets.
	o An Integrity-Algorithm AVP (12 octets)		o An Integrity-Algorithm AVP (12 octets)
	o A PRF-Algorithm AVP (12 octets)		o A PRF-Algorithm AVP (12 octets)
	o A PAC-L2-ADDR AVP (L2_ADDR_LEN + 10 octets) where L2_ADDR_LEN		o A Token AVP (16 octets)
	represents the length of the link-layer address in octets. For
	example, L2_ADDR_LEN = 6 for IEEE 802 MAC address.
	In this case, the PANA message size including PANA header (16		In this case, the PANA message size including PANA header (16
	octets), UDP header (8 octets) and IPv4 header (20 octets) is 1028 +		octets), UDP header (8 octets) and IPv4 header (20 octets) is 1028 +
	264 + 12 + 12 + L2_ADDR_LEN + 10 + 16 + 8 + 20 = (1370 + L2_ADDR_LEN)		264 + 12 + 12 + 16 + 16 + 8 + 20 = 1376 octets. Therefore, the link-
	octets. Therefore, the link-layer MTU size for IP packets MUST be no		layer MTU size for IP packets MUST be no less than 1376 octets when
	less than (1370 + L2_ADDR_LEN) octets when unspecified IPv4 address		unspecified IPv4 address is used for PANA. Note that Ethernet (MTU =
	is used for PANA. Note that Ethernet (MTU = 1500 octets) meets this		1500 octets) meets this requirement.
	requirement.
	PANA as an EAP lower-layer reports the EAP MTU to the EAP layer, so		PANA as an EAP lower-layer reports the EAP MTU to the EAP layer, so
	that EAP methods can perform appropriate fragmentation [RFC3748].		that EAP methods can perform appropriate fragmentation [RFC3748].
	The EAP MTU is calculated as follows:		The EAP MTU is calculated as follows:
	EAP_MTU = L2_MTU - (350 + L2_ADDR_LEN)		EAP_MTU = L2_MTU - 356
	In the above formula, the value of (350 + L2_ADDR_LEN) is the PANA		In the above formula, the value of 356 is the PANA overhead (IP, UDP
	overhead (IP and PANA headers, and PANA AVPs except for the EAP-		and PANA headers, and PANA AVPs except for the EAP-Payload AVP
	Payload AVP payload).		payload).
	7. Security Considerations		7. Security Considerations
	When the PAA is not capable of L2-unicasting PANA messages to the		When the PAA is not capable of L2-unicasting PANA messages to the
	target PaC, other nodes on the same subnet can receive those		target PaC, other nodes on the same subnet can receive those
	messages. This may pose a risk if there is any confidential data		messages. This may pose a risk if there is any confidential data
	exposed in the messages. Typically no such exposure exists as PANA,		exposed in the messages. Typically no such exposure exists as PANA,
	EAP, an EAP methods are defined in a way they can also be used in		EAP, an EAP methods are defined in a way they can also be used in
	wireless networks where snooping is always a possibility.		wireless networks where snooping is always a possibility.
	8. IANA Considerations		8. IANA Considerations
	As described in Section 5.1 and following the new IANA allocation		As described in Section 5.1 and following the new IANA allocation
	policy on PANA message [I-D.arkko-pana-iana], a new AVP Code for PAC-		policy on PANA message [I-D.arkko-pana-iana], a new AVP Code for
	L2-ADDR AVP needs to be assigned by IANA.		Token AVP needs to be assigned by IANA.
	9. Acknowledgments		9. Acknowledgments
	TBD.		TBD.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.		[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 31 ¶
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[I-D.arkko-pana-iana]		[I-D.arkko-pana-iana]
	Arkko, J. and A. Yegin, "IANA Rules for PANA (Protocol for		Arkko, J. and A. Yegin, "IANA Rules for PANA (Protocol for
	Carrying Authentication for Network Access)",		Carrying Authentication for Network Access)",
	draft-arkko-pana-iana-02 (work in progress),		draft-arkko-pana-iana-02 (work in progress),
	February 2010.		February 2010.
	[IANAADFAM]
	IANA, "Address Family Numbers",
	http://www.iana.org/assignments/address-family-numbers.
	10.2. Informative References		10.2. Informative References
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	skipping to change at line 364 ¶		skipping to change at page 9, line 22 ¶
	Email: alper.yegin@yegin.org		Email: alper.yegin@yegin.org
	Yoshihiro Ohba		Yoshihiro Ohba
	Toshiba Corporate Research and Development Center		Toshiba Corporate Research and Development Center
	1 Komukai-Toshiba-cho		1 Komukai-Toshiba-cho
	Saiwai-ku, Kawasaki, Kanagawa 212-8582		Saiwai-ku, Kawasaki, Kanagawa 212-8582
	Japan		Japan
	Phone: +81 44 549 2230		Phone: +81 44 549 2230
	Email: yoshihiro.ohba@toshiba.co.jp		Email: yoshihiro.ohba@toshiba.co.jp
			Lionel Morand
			Orange Labs
			Phone: +33 1 4529 62 57
			Email: Lionel.morand@orange-ftgroup.com
			John Kaippallimalil
			Huawei USA
			1700 Alma Dr., Suite 500
			Plano, TX 75082
			USA
			Phone: +1 214 606 2005
			Email: jkaippal@huawei.com
End of changes. 31 change blocks.
	78 lines changed or deleted		72 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/