< draft-rja-ilnp-intro-10.txt		draft-rja-ilnp-intro-11.txt >
	Internet Draft RJ Atkinson		Internet Draft RJ Atkinson
	draft-rja-ilnp-intro-10.txt Consultant		draft-rja-ilnp-intro-11.txt Consultant
	Expires: 7 AUG 2011 7 February 2011		Expires: 27 JAN 2012 27 July 2011
	Category: Experimental		Category: Experimental
	ILNP Concept of Operations		ILNP Concept of Operations
	draft-rja-ilnp-intro-10.txt		draft-rja-ilnp-intro-11.txt
	Status of this Memo		Status of this Memo
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided		Section 4.e of the Trust Legal Provisions and are provided
	without warranty as described in the Simplified BSD License.		without warranty as described in the Simplified BSD License.
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before		Contributions published or made publicly available before
	November 10, 2008. The person(s) controlling the copyright in		before November 10, 2008. The person(s) controlling the copyright
	some of this material may not have granted the IETF Trust the		in some of this material may not have granted the IETF Trust the
	right to allow modifications of such material outside the IETF		right to allow modifications of such material outside the IETF
	Standards Process. Without obtaining an adequate license from		Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this		the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process,		document may not be modified outside the IETF Standards Process,
	and derivative works of it may not be created outside the IETF		and derivative works of it may not be created outside the IETF
	Standards Process, except to format it for publication as an		Standards Process, except to format it for publication as an
	RFC or to translate it into languages other than English.		RFC or to translate it into languages other than English.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	4. Mobility....................................................9		4. Mobility....................................................9
	5. Multi-Homing...............................................12		5. Multi-Homing...............................................12
	6. Localised Addressing.......................................13		6. Localised Addressing.......................................13
	7. IP Security Enhancements...................................14		7. IP Security Enhancements...................................14
	8. DNS Enhancements...........................................15		8. DNS Enhancements...........................................15
	9. Referrals & Application Programming Interfaces.............17		9. Referrals & Application Programming Interfaces.............17
	10. Backwards Compatibility....................................18		10. Backwards Compatibility....................................18
	11. Incremental Deployment.....................................19		11. Incremental Deployment.....................................19
	12. Implementation Considerations..............................20		12. Implementation Considerations..............................20
	13. Security Considerations ...................................21		13. Security Considerations ...................................21
	14. IANA Considerations .......................................26		14. Privacy Considerations.....................................26
	15. References ................................................26		15. IANA Considerations .......................................28
			16. References ................................................28
	1. INTRODUCTION		1. INTRODUCTION
	At present, the Internet research and development community are		At present, the Internet research and development community are
	exploring various approaches to evolving the Internet		exploring various approaches to evolving the Internet
	Architecture to solve a variety of issues including, but not		Architecture to solve a variety of issues including, but not
	limited to, scalability inter-domain routing. A wide range of		limited to, scalability inter-domain routing. A wide range of
	other issues (e.g. site multi-homing, node multi-homing,		other issues (e.g. site multi-homing, node multi-homing,
	site/subnet mobility, node mobility) are also active concerns at		site/subnet mobility, node mobility) are also active concerns at
	present. Several different classes of evolution are being		present. Several different classes of evolution are being
	skipping to change at page 31, line 35 ¶		skipping to change at page 31, line 35 ¶
	transport-layer session state information that the communicating		transport-layer session state information that the communicating
	end systems are already keeping for transport-layer protocol		end systems are already keeping for transport-layer protocol
	reasons.		reasons.
	Last, it is important for the reader to understand that the		Last, it is important for the reader to understand that the
	mechanism described in [ILNP-ICMP] is a performance optimisation,		mechanism described in [ILNP-ICMP] is a performance optimisation,
	significantly shortening the layer-3 handoff time if/when a		significantly shortening the layer-3 handoff time if/when a
	correspondent changes location. Architecturally, using ICMP		correspondent changes location. Architecturally, using ICMP
	is no different from using UDP, of course.		is no different from using UDP, of course.
	14. IANA CONSIDERATIONS		14. PRIVACY CONSIDERATIONS
			Some users have concerns about the issue of "location privacy",
			whereby the user's location might be determined by others. The
			term "location privacy" does not have a crisp definition within
			the Internet community at present. Some mean the location of a
			node relative to the Internet's routing topology, while others
			mean the geographic coordinates of the node (i.e. latitude X,
			longitude Y). The concern seems to focus on Internet-enabled
			devices, most commonly handheld devices such as a "smart phone",
			that might have 1:1 mappings with individual users.
			There is a fundamental trade-off here. Quality of a node's
			Internet connectivity tends to be inversely proportional to the
			"location privacy" of that node. For example, if a node were
			to use a router with NAT as a privacy proxy, routing all traffic
			to and from the Internet via that proxy, then (a) latency will
			increase as the distance increases between the node seeking
			privacy and its proxy, and (b) communications with the node
			seeking privacy will be more vulnerable to communication faults
			-- both due to the proxy itself (which might fail) and due to
			the longer path (which has more points of potential failure
			than a more direct path would have).
			Any Internet node that wishes for other Internet nodes to be able
			to initiate communications sessions with it needs to include
			associated address (e.g. A, AAAA) or locator (e.g. L32, L64, LP)
			records in the publicly accessible Domain Name System (DNS).
			Information placed in the DNS is publicly accessible. Since the
			goal of DNS is to distribute information to other Internet nodes,
			it does not provide mechanisms for selective privacy. Of course,
			a node that does not wish to be contacted need not be present in
			the DNS.
			In some cases, various parties have attempted to create mappings
			between IP address blocks and geographic locations. The quality
			of such mappings appears to vary.[GUF07] Many such mapping
			efforts are driven themselves by efforts to comply with legal
			requirements in various legal jurisdictions. For example,
			some content providers reportedly have licenses authorising
			distribution of content in one set of locations, but not
			in a different set of locations.
			ILNP does not compromise user location privacy any more than base
			IPv6. In fact, by its nature ILNP provides additional choices to
			the user to protect their location privacy. Both ILNP and IPv6
			permit use of identifier values generated using the IPv6
			Privacy Address extension.[RFC-4941] ILNP and IPv6 also support
			a node having multiple unicast addresses/locators at the same
			time, which facilitates changing the node's addresses/locators
			over time. IPv4 does not have any non-topological identifiers,
			and many IPv4 nodes only support 1 IPv4 unicast address per
			interface, so IPv4 is not directly comparable with IPv6 or ILNP.
			In normal operation with IPv4, IPv6, or ILNP, a mobile node
			intends to be accessible for new connection attempts from the
			global Internet and also wishes to have both optimal routing and
			maximal Internet availability, both for sent and received
			packets. In that case, the node will want to have its addressing
			or location information kept in the DNS and made available to
			others.
			In some cases, a mobile node might only desire to initiate
			communications sessions with other Internet nodes, in which case
			the node need not be present in the DNS. Some potential
			correspondent nodes might, as a matter of local security policy,
			decline to communicate with nodes that are not present in the
			DNS. For example, some deployed IPv4-capable mail relays refuse
			to communicate with an initiating node that lacks an appropriate
			PTR record in the DNS.
			In some cases, for example intermittent electronic mail access or
			browsing specific web pages, support for long-lived network
			sessions (i.e. where session lifetime is longer than the time the
			node remains on the same subnetwork) is not required. In those
			cases, support for node mobility (i.e. session continuity even
			when the subnetwork point of attachment changes) is not required
			and need not be used.
			If a ILNP node that is mobile chooses not to use DNS for
			rendezvous, yet desires to permit any node on the global Internet
			to initiate communications with that node, then that node can
			fall back to using Mobile IPv4 or Mobile IPv6 instead.
			Many residential broadband Internet users are subject to
			involuntary renumbering, usually when their ISP's DHCP server(s)
			deny a DHCP RENEW request and instead issue different IP
			addressing information to the residential user's device(s). In
			many cases, such users want their home server(s) or client(s) to
			be externally reachable. Such users today often use Secure DNS
			Dynamic Update to update their addressing or location information
			in the DNS entries, for the devices they wish to make reachable
			from the global Internet.[RFC2136, RFC3007] This option exists
			for those users, whether they use IPv4, IPv6, or ILNP. Users also
			have the option not to use such mechanisms.
			15. IANA CONSIDERATIONS
	This document has no IANA considerations.		This document has no IANA considerations.
	15. REFERENCES		16. REFERENCES
	This section provides both normative and informative		This section provides both normative and informative
	references relating to this note.		references relating to this note.
	15.1. Normative References		16.1. Normative References
	[RFC 768] J. Postel, "User Datagram Protocol", RFC-768,		[RFC 768] J. Postel, "User Datagram Protocol", RFC-768,
	August 1980.		August 1980.
	[RFC 793] J. Postel, "Transmission Control Protocol",		[RFC 793] J. Postel, "Transmission Control Protocol",
	RFC-793, September 1981.		RFC-793, September 1981.
	[RFC 826] D. Plummer, "Ethernet Address Resolution Protocol:		[RFC 826] D. Plummer, "Ethernet Address Resolution Protocol:
	Or Converting Network Protocol Addresses to		Or Converting Network Protocol Addresses to
	48 bit Ethernet Address for Transmission on		48 bit Ethernet Address for Transmission on
	skipping to change at page 32, line 35 ¶		skipping to change at page 34, line 35 ¶
	and Requirements", RFC-4033, March 2005.		and Requirements", RFC-4033, March 2005.
	[RFC 4219] R. Hinden & S. Deering, "IP Version 6		[RFC 4219] R. Hinden & S. Deering, "IP Version 6
	Addressing Architecture", RFC-4219,		Addressing Architecture", RFC-4219,
	February 2006.		February 2006.
	[RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman,		[RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)",		"Neighbor Discovery for IP version 6 (IPv6)",
	RFC 4861, September 2007.		RFC 4861, September 2007.
	15.2. Informative References		16.2. Informative References
	[8+8] M. O'Dell, "8+8 - An Alternate Addressing		[8+8] M. O'Dell, "8+8 - An Alternate Addressing
	Architecture for IPv6", Internet-Draft,		Architecture for IPv6", Internet-Draft,
	October 1996.		October 1996.
	[Bhatti10] S. Bhatti, "Reducing DNS Caching (or 'How low		[Bhatti10] S. Bhatti, "Reducing DNS Caching (or 'How low
	can we go ?')", Presentation to 38th JANET		can we go ?')", Presentation to 38th JANET
	Networkshop, 31st March 2010, UK Joint		Networkshop, 31st March 2010, UK Joint
	Academic Network (JANET), University of Manchester,		Academic Network (JANET), University of Manchester,
	Manchester, England, UK.		Manchester, England, UK.
	skipping to change at page 36, line 24 ¶		skipping to change at page 38, line 24 ¶
	[RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and		[RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and
	Locator Pair Exploration Protocol for IPv6		Locator Pair Exploration Protocol for IPv6
	Multihoming", RFC-5534, June 2009.		Multihoming", RFC-5534, June 2009.
	[TeleSys] R. Atkinson, S. Bhatti, & S. Hailes,		[TeleSys] R. Atkinson, S. Bhatti, & S. Hailes,
	"ILNP: Mobility, Multi-Homing, Localised Addressing		"ILNP: Mobility, Multi-Homing, Localised Addressing
	and Security Through Naming", Telecommunications		and Security Through Naming", Telecommunications
	Systems, Volume 42, Number 3-4, pp 273-291,		Systems, Volume 42, Number 3-4, pp 273-291,
	Springer-Verlag, December 2009, ISSN 1018-4864.		Springer-Verlag, December 2009, ISSN 1018-4864.
			[GUF07] Bamba Gueye, Steve Uhlig, & Serge Fdida,
			"Investigating the Imprecision of IP Block-Based
			Geolocation", Lecture Notes in Computer Science,
			Volume 4427, pp. 237-240, Springer-Verlag,
			Heidelberg, Germany, 2007.
	ACKNOWLEDGEMENTS		ACKNOWLEDGEMENTS
	Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa,		Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa,
	Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,		Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
	Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter and		Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter and
	Robin Whittle (in alphabetical order) provided review and		Robin Whittle (in alphabetical order) provided review and
	feedback on earlier versions of this document. Steve Blake		feedback on earlier versions of this document. Steve Blake
	provided an especially thorough review of the entire ILNP		provided an especially thorough review of the entire ILNP
	document set, which was extremely helpful.		document set, which was extremely helpful.
	skipping to change at page 36, line 47 ¶		skipping to change at page 39, line 4 ¶
	messages herein.		messages herein.
	Author's Address		Author's Address
	RJ Atkinson		RJ Atkinson
	Consultant		Consultant
	McLean, VA		McLean, VA
	22103 USA		22103 USA
	Email: rja.lists@gmail.com		Email: rja.lists@gmail.com
			Expires: 27 JAN 2012
	Expires: 7 AUG 2011
End of changes. 10 change blocks.
	12 lines changed or deleted		115 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/