< draft-thubert-nina-01.txt		draft-thubert-nina-02.txt >
	Internet Engineering Task Force P. Thubert		Internet Engineering Task Force P. Thubert
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track R. Wakikawa		Intended status: Standards Track R. Wakikawa
	Expires: January 5, 2008 Keio University		Expires: August 7, 2008 Keio University
	C. Bernardos		C. Bernardos
	UC3M		UC3M
	R. Baldessari		R. Baldessari
	NEC Europe		NEC Europe
	J. Lorchat		J. Lorchat
	Keio University		Keio University
	July 4, 2007		February 4, 2008
	Network In Node Advertisement		Network In Node Advertisement
	draft-thubert-nina-01.txt		draft-thubert-nina-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 5, 2008.		This Internet-Draft will expire on August 7, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Internet is evolving to become a more ubiquitous network, driven		The Internet is evolving to become a more ubiquitous network, driven
	by the low prices of wireless routers and access points and by the		by the low prices of wireless routers and access points and by the
	users' requirements of connectivity anytime and anywhere. For that		users' requirements of connectivity anytime and anywhere. For that
	reason, a cloud of nodes connected by wireless technology is being		reason, a cloud of nodes connected by wireless technology is being
	created at the edge of the Internet. This cloud is called a MANEMO		created at the edge of the Internet. This cloud is called a MANEMO
	Fringe Stub (MFS). It is expected that networking in the MFS will be		Fringe Stub (MFS). It is expected that networking in the MFS will be
	highly unmanaged and ad-hoc, but at the same time will need to offer		highly unmanaged and ad-hoc, but at the same time will need to offer
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Rationale for the proposed solution . . . . . . . . . . . . . 7		4. Rationale for the proposed solution . . . . . . . . . . . . . 7
	4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8		4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8
	4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8		4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12		6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 15		6.2. NINO IPv4 option . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Multicast TD RA messages from parent . . . . . . . . . . . 17		7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 16
	7.2. Unicast NINA messages from child to parent . . . . . . . . 18		7.1. Multicast TD RA messages from parent . . . . . . . . . . . 18
	7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 18		7.2. Unicast NINA messages from child to parent . . . . . . . . 19
	7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 19		7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 19
			7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 20
	7.5. Aggregation of prefixes by a parent acting as mobile		7.5. Aggregation of prefixes by a parent acting as mobile
	Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 20		7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 21
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 21		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23		10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 25		12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	12.2. Informative References . . . . . . . . . . . . . . . . . . 25		12.2. Informative References . . . . . . . . . . . . . . . . . . 26
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	Intellectual Property and Copyright Statements . . . . . . . . . . 31		Intellectual Property and Copyright Statements . . . . . . . . . . 32
	1. Introduction		1. Introduction
	Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile		Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile
	nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility		nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility
	for IPv6, and NEMO [5] enables it for mobile prefixes. In any case,		for IPv6, and NEMO [5] enables it for mobile prefixes. In any case,
	a mobile node is always identified by its Home Address (HoA),		a mobile node is always identified by its Home Address (HoA),
	regardless of its current point of attachment to the Internet. In		regardless of its current point of attachment to the Internet. In
	turn, MANET [12], [15] allows a set of unrelated nodes and routers to		turn, MANET [11], [14] allows a set of unrelated nodes and routers to
	discover their peers and establish communication.		discover their peers and establish communication.
	Mobile Routers (MRs) may attach to other MRs and form a Care-of		Mobile Routers (MRs) may attach to other MRs and form a Care-of
	Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs		Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs
	are really MARs, Mobile Access Routers, because they can accept		are really MARs, Mobile Access Routers, because they can accept
	connections from other MRs on their ingress interfaces. When Mobile		connections from other MRs on their ingress interfaces. When Mobile
	Routers attach to other Mobile Routers with a single Care-of Address		Routers attach to other Mobile Routers with a single Care-of Address
	in a loop-less manner, they end up building trees. This process is		in a loop-less manner, they end up building trees. This process is
	described in Tree Discovery (TD) [6].		described in Tree Discovery (TD) [6].
	This draft provides a minimum extension to IPv6 Neighbor Discovery		This draft provides a minimum extension to IPv6 Neighbor Discovery
	(ND) Neighbors Advertisements (NA) - called NINA (Network In Node		(ND) Neighbors Advertisements (NA) - called NINA (Network In Node
	Advertisement) - extending RFC 2461 [2] and RFC 4191 [7] to add the		Advertisement) - extending RFC 4861 [2] and RFC 4191 [7] to add the
	capability to include a prefix option - called NINO (Network In Node		capability to include a prefix option - called NINO (Network In Node
	Option) - in the NAs. This enables an MR to learn the prefixes of		Option) - in the NAs. This enables an MR to learn the prefixes of
	all other MRs down its sub-tree. Note that NINO is pronounced NEE-		all other MRs down its sub-tree. Note that NINO is pronounced NEE-
	GNO and NINA is pronounced NEE-GNA.		GNO and NINA is pronounced NEE-GNA.
	A NEMO Mobile Router has a double behavior. On its egress		A NEMO Mobile Router has a double behavior. On its egress
	interfaces, which are used to backhaul the traffic to the Home		interfaces, which are used to backhaul the traffic to the Home
	Network and the rest of the Internet, it is seen as a Mobile Node		Network and the rest of the Internet, it is seen as a Mobile Node
	(MN), performing the IPv6 and MIPv6 host-required features such as		(MN), performing the IPv6 and MIPv6 host-required features such as
	neighbor and router discovery [2]. On the (ingress) interfaces to		neighbor and router discovery [2]. On the (ingress) interfaces to
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	NINA extends ND NAs to advertise over the egress interface the		NINA extends ND NAs to advertise over the egress interface the
	prefixes that are reachable via the MR.		prefixes that are reachable via the MR.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	Readers are expected to be familiar with all the terms defined in the		Readers are expected to be familiar with all the terms defined in the
	RFC 3753 [11], the NEMO Terminology draft [20] and the MANEMO Problem		RFC 3753 [10], the NEMO Terminology draft [19] and the MANEMO Problem
	Statement draft [19].		Statement draft [18].
	NINO (Network In Node Option): a new Neighbor Discovery (ND)		NINO (Network In Node Option): a new Neighbor Discovery (ND)
	option that adds the capability to include a prefix option in		option that adds the capability to include a prefix option in
	Neighbor Advertisements (NAs).		Neighbor Advertisements (NAs).
	NINA (Network In Node Advertisement): a Neighbor Discovery (ND)		NINA (Network In Node Advertisement): a Neighbor Discovery (ND)
	Neighbor Advertisement (NA) carrying a NINO. NINA is also used to		Neighbor Advertisement (NA) carrying a NINO. NINA is also used to
	refer to the protocol itself (defined in this document).		refer to the protocol itself (defined in this document).
	3. Motivations		3. Motivations
	The Internet is evolving to become a more ubiquitous network, driven		The Internet is evolving to become a more ubiquitous network, driven
	by the low prices of wireless routers and access points and by the		by the low prices of wireless routers and access points and by the
	users' requirements of connectivity anytime and anywhere. For that		users' requirements of connectivity anytime and anywhere. For that
	reason, a cloud of nodes connected by wireless technology is being		reason, a cloud of nodes connected by wireless technology is being
	created at the edge of the Internet. This cloud is called a MANEMO		created at the edge of the Internet. This cloud is called a MANEMO
	Fringe Stub (MFS) in [19]. Examples of wireless technologies used		Fringe Stub (MFS) in [18]. Examples of wireless technologies used
	within a MFS are wireless metropolitan and local area network		within a MFS are wireless metropolitan and local area network
	protocols (WiMAX, WLAN, 802.20, etc), short distance wireless		protocols (WiMAX, WLAN, 802.20, etc), short distance wireless
	technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g.,		technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g.,
	802.11s). It is expected that networking in the MFS will be highly		802.11s). It is expected that networking in the MFS will be highly
	unmanaged and ad-hoc, but at the same time will need to offer		unmanaged and ad-hoc, but at the same time will need to offer
	excellent service availability.		excellent service availability.
	The NEMO Basic Support protocol [5] could be used to provide global		The NEMO Basic Support protocol [5] could be used to provide global
	reachability for a mobile access network within the MFS.		reachability for a mobile access network within the MFS.
	Analogously, the Tree-Discovery mechanism [6] could be used to avoid		Analogously, the Tree-Discovery mechanism [6] could be used to avoid
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	need to enable local routing between the Mobile Routers within a		need to enable local routing between the Mobile Routers within a
	portion of the MFS. NINA can provide this form of local routing; it		portion of the MFS. NINA can provide this form of local routing; it
	is an example of Route Optimization (RO) between Mobile Routers that		is an example of Route Optimization (RO) between Mobile Routers that
	are communicating directly in a portion of the MFS.		are communicating directly in a portion of the MFS.
	4. Rationale for the proposed solution		4. Rationale for the proposed solution
	4.1. Why ND based		4.1. Why ND based
	NINA extends the Neighbor Discovery protocol to address the MANEMO		NINA extends the Neighbor Discovery protocol to address the MANEMO
	requirements listed in [19], although MANET protocols [13], [16],		requirements listed in [18], although MANET protocols [12], [15],
	[17] provides similar features such as local routing and Internet		[16] provides similar features such as local routing and Internet
	access over multihop.		access over multihop.
	One of the drawbacks of MANET protocols is the question of which		One of the drawbacks of MANET protocols is the question of which
	protocol should be used. AODV, DSR, DYMO, OLSR, etc. are		protocol should be used. AODV, DSR, DYMO, OLSR, etc. are
	standardized in IETF and each has distinct features, like proactive		standardized in IETF and each has distinct features, like proactive
	and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and		and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and
	fixed access routers are involved, and therefore, it is highly		fixed access routers are involved, and therefore, it is highly
	important to deploy a consistent protocol in the network. On the		important to deploy a consistent protocol in the network. On the
	other hand, ND is a core component of IPv6 and is supported by all		other hand, ND is a core component of IPv6 and is supported by all
	IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if		IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 26 ¶
	This allows an extreme conciseness of the routing information, with		This allows an extreme conciseness of the routing information, with
	no topological knowledge past the first hop. That conciseness		no topological knowledge past the first hop. That conciseness
	enables a high degree of movement within the nested structure; in		enables a high degree of movement within the nested structure; in
	particular, a movement within a subtree is not seen outside of that		particular, a movement within a subtree is not seen outside of that
	subtree, so most of the connectivity is maintained at all times while		subtree, so most of the connectivity is maintained at all times while
	there might never be such a thing as a convergence.		there might never be such a thing as a convergence.
	4.4. Relationship with NEMO		4.4. Relationship with NEMO
	The Reverse Routing Header (RRH) described in [18] operates in the		The Reverse Routing Header (RRH) described in [17] operates in the
	nested NEMO as a layer 3 Source Route Bridging (SRB) technique for		nested NEMO as a layer 3 Source Route Bridging (SRB) technique for
	nested NEMO Route Optimization. It allows a quick reaction to inner		nested NEMO Route Optimization. It allows a quick reaction to inner
	movements with the resolution of the packet; but the cost, an IPv6		movements with the resolution of the packet; but the cost, an IPv6
	address per packet per hop, might be deemed excessive.		address per packet per hop, might be deemed excessive.
	Also, the Home Agent needs to cache the RRH in its binding cache, and		Also, the Home Agent needs to cache the RRH in its binding cache, and
	again, the overhead might be significant for a large deployment.		again, the overhead might be significant for a large deployment.
	On the other hand, NINA establishes states in the intermediate nodes,		On the other hand, NINA establishes states in the intermediate nodes,
	in a fashion similar to Transparent Bridging (TB), but at layer 3.		in a fashion similar to Transparent Bridging (TB), but at layer 3.
	The integration of these 2 approaches allows switching between SRB to		The integration of these 2 approaches allows switching between SRB to
	TB models dynamically as the NINA states are populated or become		TB models dynamically as the NINA states are populated or become
	obsolete. To obtain this capability, the operation of an		obsolete. To obtain this capability, the operation of an
	intermediate MR described in [18] is altered in the following manner:		intermediate MR described in [17] is altered in the following manner:
	o If the MR has a (NINA) route to the upper entry in the RRH via the		o If the MR has a (NINA) route to the upper entry in the RRH via the
	source of the packet, it still updates the source of the packet		source of the packet, it still updates the source of the packet
	with its own Care-of Address, but does not save the previous		with its own Care-of Address, but does not save the previous
	source as a new entry in the RRH.		source as a new entry in the RRH.
	o At best, if NINA has established states all along in a given		o At best, if NINA has established states all along in a given
	branch of the tree, the RRH for that branch has always 2 entries,		branch of the tree, the RRH for that branch has always 2 entries,
	the first MR's Home Address, and its Care-of Address, regardless		the first MR's Home Address, and its Care-of Address, regardless
	of the depth of the first MR in the nested NEMO.		of the depth of the first MR in the nested NEMO.
	o When some MRs in the tree support NINA and some do not, the		o When some MRs in the tree support NINA and some do not, the
	resulting RRH will be only partly compressed. Also, if the NINA		resulting RRH will be only partly compressed. Also, if the NINA
	route does not match the RRH, then the route is obsolete and the		route does not match the RRH, then the route is obsolete and the
	source address is added to the RRH as described in [18], in order		source address is added to the RRH as described in [17], in order
	to ensure a correct routing on the way back. When NINA catches		to ensure a correct routing on the way back. When NINA catches
	up, the entry will be saved again.		up, the entry will be saved again.
	The integration of NINA and RRH can offer the best of 2 worlds: a		The integration of NINA and RRH can offer the best of 2 worlds: a
	quick (per packet) resolution to the network changes, and the		quick (per packet) resolution to the network changes, and the
	transparent (stateful) operation when the NINA routing protocol		transparent (stateful) operation when the NINA routing protocol
	establishes the states in the nested NEMO.		establishes the states in the nested NEMO.
	5. Overview		5. Overview
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 15 ¶
	learned from NINO and the connected prefixes). A NINA is also sent		learned from NINO and the connected prefixes). A NINA is also sent
	to the AR once it has been selected as new AR after a movement, or		to the AR once it has been selected as new AR after a movement, or
	when the list of advertised prefixes has changed.		when the list of advertised prefixes has changed.
	NINA may advertise positive (prefix is present) or negative (removed)		NINA may advertise positive (prefix is present) or negative (removed)
	NINOs. A no-NINO is stimulated by the disappearance of a prefix		NINOs. A no-NINO is stimulated by the disappearance of a prefix
	below. This is discovered by timing out after a request (a RA-TIO)		below. This is discovered by timing out after a request (a RA-TIO)
	or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime		or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime
	of 0.		of 0.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Prefix Length | Reserved1 |L|4|		| Type | Length | Prefix Length |L| Reserved1 |4|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NINO Lifetime |		| NINO Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved2 |		| Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NINO Depth | Reserved3 | NINO Sequence |		| NINO Depth | Reserved3 | NINO Sequence |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Prefix (Variable Length) +		+ Prefix (Variable Length) +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		Type:
	NINO (number to be assigned by IANA).		NINO (number to be assigned by IANA).
	Length:		Length:
	8-bit unsigned integer. The length of the option (including the		8-bit unsigned integer. The length of the option (including the
	Type and Length fields) in units of 8 octets.		Type and Length fields) in units of 8 octets.
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	lollipop mechanism is used to wrap from 0xFFFF directly to 10.		lollipop mechanism is used to wrap from 0xFFFF directly to 10.
	Prefix:		Prefix:
	Variable-length field containing an IPv6 address or a prefix of an		Variable-length field containing an IPv6 address or a prefix of an
	IPv6 address. The Prefix Length field contains the number of		IPv6 address. The Prefix Length field contains the number of
	valid leading bits in the prefix. The bits in the prefix after		valid leading bits in the prefix. The bits in the prefix after
	the prefix length (if any) are reserved and MUST be initialized to		the prefix length (if any) are reserved and MUST be initialized to
	zero by the sender and ignored by the receiver.		zero by the sender and ignored by the receiver.
			6.2. NINO IPv4 option
			NINA is defined for both IPv4 and IPv6 address families.
			For IPv4, a new NINO IPv4 option is introduced to be included in RA
			and NA messages, for a node to advertise its IPv4 address on the
			interface where the ND message is issued.
			The NINO IPv4 option can be included in an RA by the sending router
			to expose its IPv4 address to the attached visitors, so they can
			install a default route via that address and use the sending router
			as default gateway.
			The option can also be included in a NA by a visiting node to expose
			its IPv4 address to the Attachment Router; this address is used as
			next hop by the AR as it installs routes via the visiting node
			towards the IPv4 prefixes contained in the NINOs and passed as mapped
			addresses in the NA message.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 address on sending interface |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type:
			NINO IPv4 (number to be assigned by IANA).
			Length:
			8-bit unsigned integer. The length of the option (including the
			Type and Length fields) in units of 8 octets.
			Reserved:
			8-bit unused field. It MUST be initialized to zero by the sender
			and MUST be ignored by the receiver.
			IPv4 address on sending interface:
			32-bit field containing the IPv4 address of the sending interface.
	7. Mobile Router Operation		7. Mobile Router Operation
	The Mobile Router operation is autonomous, based on the information		The Mobile Router operation is autonomous, based on the information
	provided by the potential Access Routers in sight. Each MR selects		provided by the potential Access Routers in sight. Each MR selects
	an AR (a MAR) in a loop-less and case-optimized fashion, and installs		an AR (a MAR) in a loop-less and case-optimized fashion, and installs
	a default route up the tree via the selected AR. The resulting tree		a default route up the tree via the selected AR. The resulting tree
	(the cluster) may never be globally stable enough to be mapped in a		(the cluster) may never be globally stable enough to be mapped in a
	global graph. So the adaptation to local movements must be rapid and		global graph. So the adaptation to local movements must be rapid and
	localized.		localized.
	skipping to change at page 20, line 9 ¶		skipping to change at page 21, line 9 ¶
	3. A toon member is somewhere else in the Internet.		3. A toon member is somewhere else in the Internet.
	In all those cases, a node situated above the commander in the TD		In all those cases, a node situated above the commander in the TD
	tree but not above the toon member will see the advertisements for		tree but not above the toon member will see the advertisements for
	the aggregation owned by the commander but not that of the individual		the aggregation owned by the commander but not that of the individual
	toon member prefix. So it will route all the packets for the toon		toon member prefix. So it will route all the packets for the toon
	member towards the commander, but the commander will have no route to		member towards the commander, but the commander will have no route to
	the toon and will fail to forward.		the toon and will fail to forward.
	Section 8 'Mobile Home' of RFC 4887 [21] proposes a deployment model		Section 8 'Mobile Home' of RFC 4887 [20] proposes a deployment model
	where a Mobile Router would also act as Home Agent for a mobile		where a Mobile Router would also act as Home Agent for a mobile
	aggregation. This method can be used in the general case 3 to ensure		aggregation. This method can be used in the general case 3 to ensure
	routability to the toon member. With that method, the Home Link for		routability to the toon member. With that method, the Home Link for
	a toon member should be one of the commander links. The Tree		a toon member should be one of the commander links. The Tree
	Discovery plug-in should favor that link so that many toon members		Discovery plug-in should favor that link so that many toon members
	actually attach at Home.		actually attach at Home.
	If a toon member is not at Home, then it will register to its Home		If a toon member is not at Home, then it will register to its Home
	Agent using NEMO basic support (RFC 3963 [5]). Depending of the		Agent using NEMO basic support (RFC 3963 [5]). Depending of the
	location of a source, a packet to the toon member will either go		location of a source, a packet to the toon member will either go
	directly to it, or go to its commander. If the toon member as a		directly to it, or go to its commander. If the toon member as a
	Mobile Router is registered to its commander as its Home Agent, the		Mobile Router is registered to its commander as its Home Agent, the
	commander can always encapsulate the packet to the CoA of the toon		commander can always encapsulate the packet to the CoA of the toon
	member using NEMO, and ensure reachability to the MR.		member using NEMO, and ensure reachability to the MR.
	Section 2.7 of RFC 4888 [22] explains that in the specific case of		Section 2.7 of RFC 4888 [21] explains that in the specific case of
	case 1), the commander will not be able to reach Home using plain		case 1), the commander will not be able to reach Home using plain
	NEMO basic support, and an additional mechanism such as RRH ([18]) is		NEMO basic support, and an additional mechanism such as RRH ([17]) is
	required to fix that issue.		required to fix that issue.
	Also specifically in case 1), the toon member will refrain from		Also specifically in case 1), the toon member will refrain from
	adding the NINO options for its own prefixes that are aggregated in		adding the NINO options for its own prefixes that are aggregated in
	the NINO option of its commander that it propagates up the TD tree.		the NINO option of its commander that it propagates up the TD tree.
	7.6. Default value		7.6. Default value
	DEF_NA_LATENCY = 150 ms		DEF_NA_LATENCY = 150 ms
	MAX_DESTROY_INTERVAL = 200ms		MAX_DESTROY_INTERVAL = 200ms
	8. Privacy Considerations		8. Privacy Considerations
	It is already possible for a visiting Mobile Node (Mobile Router) to		It is already possible for a visiting Mobile Node (Mobile Router) to
	autoconfigure an address that will not identify the visitor [8],		autoconfigure an address that will not identify the visitor [22],
	[23], [14]. It is also possible for a visitor to roll its CoA		[13]. It is also possible for a visitor to roll its CoA periodically
	periodically even when it stays attached to a same point, and		even when it stays attached to a same point, and register the new
	register the new addresses as it forms them.		addresses as it forms them.
	CIA (Capability, Innocuousness and Anonymity) properties demand also		CIA (Capability, Innocuousness and Anonymity) properties demand also
	that the visited party might not be identified by the visitor. To		that the visited party might not be identified by the visitor. To
	achieve that, a Mobile Router should not advertise its MNPs on its		achieve that, a Mobile Router should not advertise its MNPs on its
	links open to untrusted visitors.		links open to untrusted visitors.
	This draft recommends that the interface that is open for untrusted		This draft recommends that the interface that is open for untrusted
	visitors uses unique local addresses (RFC 4193 [9]) and rolls the		visitors uses unique local addresses (RFC 4193 [8]) and rolls the
	advertised prefixes with a short lifetime. This can be achieved for		advertised prefixes with a short lifetime. This can be achieved for
	instance by obtaining short lived leases from the Home Agent using		instance by obtaining short lived leases from the Home Agent using
	DHCP-PD [24].		DHCP-PD [23].
	Another possibility is to use strict RRH routing [18]; in that case,		Another possibility is to use strict RRH routing [17]; in that case,
	the prefix that is presented on the link can be taken from anywhere		the prefix that is presented on the link can be taken from anywhere
	in the ULA range since it is not used for routing outside the link.		in the ULA range since it is not used for routing outside the link.
	Alternatively, a global unique prefix obtained from an autoconf		Alternatively, a global unique prefix obtained from an autoconf
	solution [25], [26] or DHCPv6 prefix delegation [10] can be used as		solution [24], [25] or DHCPv6 prefix delegation [9] can be used as
	well.		well.
	9. IANA Considerations		9. IANA Considerations
	This document requires IANA to assign a number for a new ND option		This document requires IANA to assign a number for a new ND option
	type (NINO NA).		type (NINO NA).
	10. Security Considerations		10. Security Considerations
	Exposing the MRs' MNPs within the MFS introduces several security		Exposing the MRs' MNPs within the MFS introduces several security
	threats that should be carefully tackled, mainly derived from the		threats that should be carefully tackled, mainly derived from the
	fact that MRs are distributing prefixes (i.e., their MNPs) that are		fact that MRs are distributing prefixes (i.e., their MNPs) that are
	not topologically correct within the MFS.		not topologically correct within the MFS.
	To avoid these security issues -- that might enable malicious nodes		To avoid these security issues -- that might enable malicious nodes
	to steal traffic addressed to other nodes (by spoofing their		to steal traffic addressed to other nodes (by spoofing their
	prefixes) -- Mobile Routers should be provided with some security		prefixes) -- Mobile Routers should be provided with some security
	mechanisms, ensuring that an MR that is advertising a certain MNP is		mechanisms, ensuring that an MR that is advertising a certain MNP is
	actually authorised to do that.		actually authorized to do that.
	The use of L2 trusts and policies, SeND or preconfigured security		The use of L2 trusts and policies, SeND or preconfigured security
	relationships might help in securing the mechanism described in this		relationships might help in securing the mechanism described in this
	draft. Additionally, if MRs have connectivity with their Home		draft. Additionally, if MRs have connectivity with their Home
	Agents, a modified Return Routability mechanism -- extended to		Agents, a modified Return Routability mechanism -- extended to
	support prefix checks (such as [27] or [28]) -- may be used to		support prefix checks (such as [26] or [27]) -- may be used to
	provide the required authorisation, before starting to use the RO		provide the required authorization, before starting to use the RO
	shortcut within the MFS.		shortcut within the MFS.
	11. Acknowledgments		11. Acknowledgments
	We would like to thank all the people who have provided comments on		We would like to thank all the people who have provided comments on
	this draft, specially to Ben McCarthy for his very helpful review of		this draft, specially to Ben McCarthy for his very helpful review of
	this document.		this document.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
			September 2007.
	[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,		[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	August 2002.		August 2002.
	[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,		[5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[6] Thubert, P., "Nested Nemo Tree Discovery",		[6] Thubert, P., "Nested Nemo Tree Discovery",
	draft-thubert-tree-discovery-05 (work in progress), April 2007.		draft-thubert-tree-discovery-06 (work in progress), July 2007.
	[7] Draves, R. and D. Thaler, "Default Router Preferences and More-		[7] Draves, R. and D. Thaler, "Default Router Preferences and More-
	Specific Routes", RFC 4191, November 2005.		Specific Routes", RFC 4191, November 2005.
	[8] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[8] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Address Autoconfiguration in IPv6", RFC 3041, January 2001.
	[9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.		Addresses", RFC 4193, October 2005.
	[10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host		[9] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
	Configuration Protocol (DHCP) version 6", RFC 3633,		Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	12.2. Informative References		12.2. Informative References
	[11] Manner, J. and M. Kojo, "Mobility Related Terminology",		[10] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.		RFC 3753, June 2004.
	[12] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET):		[11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET):
	Routing Protocol Performance Issues and Evaluation		Routing Protocol Performance Issues and Evaluation
	Considerations", RFC 2501, January 1999.		Considerations", RFC 2501, January 1999.
	[13] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing		[12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing
	Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728,		Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728,
	February 2007.		February 2007.
	[14] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[15] Chakeres, I., "Mobile Ad hoc Network Architecture",		[14] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc
	draft-ietf-autoconf-manetarch-03 (work in progress), June 2007.		Network Architecture", draft-ietf-autoconf-manetarch-07 (work
			in progress), November 2007.
	[16] Clausen, T., "The Optimized Link State Routing Protocol version		[15] Clausen, T., "The Optimized Link State Routing Protocol version
	2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007.		2", draft-ietf-manet-olsrv2-04 (work in progress), July 2007.
	[17] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",		[16] Clausen, T., Dearlove, C., and J. Dean, "MANET Neighborhood
	draft-ietf-manet-nhdp-04 (work in progress), June 2007.		Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-05 (work in
			progress), December 2007.
	[18] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and		[17] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
	its application to Mobile Networks",		its application to Mobile Networks",
	draft-thubert-nemo-reverse-routing-header-07 (work in		draft-thubert-nemo-reverse-routing-header-07 (work in
	progress), February 2007.		progress), February 2007.
	[19] Wakikawa, R., "MANEMO Problem Statement",		[18] Wakikawa, R., "Problem Statement and Requirements for MANEMO",
	draft-wakikawa-manemo-problem-statement-00 (work in progress),		draft-wakikawa-manemo-problem-statement-01 (work in progress),
	February 2007.		July 2007.
	[20] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[19] Ernst, T. and H-Y. Lach, "Network Mobility Support
	draft-ietf-nemo-terminology-06 (work in progress),		Terminology", RFC 4885, July 2007.
	November 2006.
	[21] Thubert, P., "NEMO Home Network models",		[20] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
	draft-ietf-nemo-home-network-models-06 (work in progress),		Mobility Home Network Models", RFC 4887, July 2007.
	February 2006.
	[22] Ng, C., "Network Mobility Route Optimization Problem		[21] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
	Statement", draft-ietf-nemo-ro-problem-statement-03 (work in		Route Optimization Problem Statement", RFC 4888, July 2007.
	progress), September 2006.
	[23] Narten, T., "Privacy Extensions for Stateless Address		[22] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
	Autoconfiguration in IPv6", draft-ietf-ipv6-privacy-addrs-v2-05		for Stateless Address Autoconfiguration in IPv6", RFC 4941,
	(work in progress), October 2006.		September 2007.
	[24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",		[23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
	draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.		draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
	[25] Baccelli, E., "Address Autoconfiguration for MANET: Terminology		[24] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address
	and Problem Statement", draft-ietf-autoconf-statement-00 (work		Autoconfiguration for MANET: Terminology and Problem
	in progress), June 2007.		Statement", draft-ietf-autoconf-statement-03 (work in
			progress), January 2008.
	[26] Bernardos, C. and M. Calderon, "Survey of IP address		[25] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP
	autoconfiguration mechanisms for MANETs",		address autoconfiguration mechanisms for MANETs",
	draft-bernardos-manet-autoconf-survey-00 (work in progress),		draft-bernardos-manet-autoconf-survey-02 (work in progress),
	July 2005.		October 2007.
	[27] Ng, C., "Extending Return Routability Procedure for Network		[26] Ng, C., "Extending Return Routability Procedure for Network
	Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress),		Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress),
	October 2004.		October 2004.
	[28] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A.		[27] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A.
	Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO",		Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO",
	Computer Communications, vol. 30, pp. 1765-1784 , 2007.		Computer Communications, vol. 30, pp. 1765-1784 , 2007.
	Appendix A. Change Log		Appendix A. Change Log
			Changes from -01 to -02:
			o NINA IPv4 support: added IPv4 NINO ND option.
			o References updated.
			o Updated the location of the 'L' bit in the NINO NA option, to
			match format of RFC 4861.
	Changes from -00 to -01:		Changes from -00 to -01:
	o Basic kiss (MR to MR over egress) sections removed.		o Basic kiss (MR to MR over egress) sections removed.
	o Added sections about aggregation of prefixes.		o Added sections about aggregation of prefixes.
	o Added Privacy consideration section.		o Added Privacy consideration section.
	o NINO NA message format changed.		o NINO NA message format changed.
	skipping to change at page 31, line 7 ¶		skipping to change at page 32, line 7 ¶
	Jean Lorchat		Jean Lorchat
	Keio University and WIDE		Keio University and WIDE
	5322 Endo Fujisawa Kanagawa		5322 Endo Fujisawa Kanagawa
	252-8520		252-8520
	JAPAN		JAPAN
	Email: lorchat@sfc.wide.ad.jp		Email: lorchat@sfc.wide.ad.jp
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 51 change blocks.
	110 lines changed or deleted		163 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/