< draft-ietf-homenet-arch-15.txt		draft-ietf-homenet-arch-16.txt >
	Network Working Group T. Chown, Ed.		Network Working Group T. Chown, Ed.
	Internet-Draft University of Southampton		Internet-Draft University of Southampton
	Intended status: Informational J. Arkko		Intended status: Informational J. Arkko
	Expires: December 11, 2014 Ericsson		Expires: December 12, 2014 Ericsson
	A. Brandt		A. Brandt
	Sigma Designs		Sigma Designs
	O. Troan		O. Troan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	J. Weil		J. Weil
	Time Warner Cable		Time Warner Cable
	June 9, 2014		June 10, 2014
	IPv6 Home Networking Architecture Principles		IPv6 Home Networking Architecture Principles
	draft-ietf-homenet-arch-15		draft-ietf-homenet-arch-16
	Abstract		Abstract
	This text describes evolving networking technology within residential		This text describes evolving networking technology within residential
	home networks with increasing numbers of devices and a trend towards		home networks with increasing numbers of devices and a trend towards
	increased internal routing. The goal of this document is to define a		increased internal routing. The goal of this document is to define a
	general architecture for IPv6-based home networking, describing the		general architecture for IPv6-based home networking, describing the
	associated principles, considerations and requirements. The text		associated principles, considerations and requirements. The text
	briefly highlights specific implications of the introduction of IPv6		briefly highlights specific implications of the introduction of IPv6
	for home networking, discusses the elements of the architecture, and		for home networking, discusses the elements of the architecture, and
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on December 11, 2014.		This Internet-Draft will expire on December 12, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28		3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
	3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28		3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
	3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 30		3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 30
	3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31		3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31
	3.6.1. Addressability vs reachability . . . . . . . . . . . . 31		3.6.1. Addressability vs reachability . . . . . . . . . . . . 31
	3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 32		3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 32
	3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32		3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32
	3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 33		3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 33
	3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 33		3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 33
	3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33		3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33
	3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 33		3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 34
	3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34		3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34
	3.7.2. Assigning names to devices . . . . . . . . . . . . . . 35		3.7.2. Assigning names to devices . . . . . . . . . . . . . . 35
	3.7.3. The homenet name service . . . . . . . . . . . . . . . 35		3.7.3. The homenet name service . . . . . . . . . . . . . . . 35
	3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36		3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36
	3.7.5. Independent operation . . . . . . . . . . . . . . . . 38		3.7.5. Independent operation . . . . . . . . . . . . . . . . 39
	3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 39		3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 39
	3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 39		3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 39
	3.7.8. Devices roaming to/from the homenet . . . . . . . . . 39		3.7.8. Devices roaming to/from the homenet . . . . . . . . . 40
	3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40		3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40
	3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 40		3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 40
	3.8.2. Operations and Management . . . . . . . . . . . . . . 40		3.8.2. Operations and Management . . . . . . . . . . . . . . 40
	3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 41		3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 42
	4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42		4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 42		5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 42		7.1. Normative References . . . . . . . . . . . . . . . . . . . 43
	7.2. Informative References . . . . . . . . . . . . . . . . . . 43		7.2. Informative References . . . . . . . . . . . . . . . . . . 43
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 45		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 46
	Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46		Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46
	B.1. Version 15 . . . . . . . . . . . . . . . . . . . . . . . . 46		B.1. Version 14 . . . . . . . . . . . . . . . . . . . . . . . . 46
	B.2. Version 14 . . . . . . . . . . . . . . . . . . . . . . . . 46		B.2. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 47
	B.3. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 46		B.3. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 47
	B.4. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 47		B.4. Version 11 (after IESG review) . . . . . . . . . . . . . . 47
	B.5. Version 11 (after IESG review) . . . . . . . . . . . . . . 47		B.5. Version 10 (after AD review) . . . . . . . . . . . . . . . 47
	B.6. Version 10 (after AD review) . . . . . . . . . . . . . . . 47		B.6. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47
	B.7. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47		B.7. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48
	B.8. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48		B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48
	B.9. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48		B.9. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49
	B.10. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49		B.10. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49
	B.11. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49		B.11. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 50
	B.12. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 50		B.12. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50
	B.13. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50		B.13. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51
	B.14. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document focuses on evolving networking technology within		This document focuses on evolving networking technology within
	residential home networks with increasing numbers of devices and a		residential home networks with increasing numbers of devices and a
	trend towards increased internal routing, and the associated		trend towards increased internal routing, and the associated
	challenges with their deployment and operation. There is a growing		challenges with their deployment and operation. There is a growing
	trend in home networking for the proliferation of networking		trend in home networking for the proliferation of networking
	technology through an increasingly broad range of devices and media.		technology through an increasingly broad range of devices and media.
	skipping to change at page 28, line 51 ¶		skipping to change at page 28, line 51 ¶
	discussed below should be met.		discussed below should be met.
	The homenet unicast routing protocol should be based on a previously		The homenet unicast routing protocol should be based on a previously
	deployed protocol that has been shown to be reliable and robust, and		deployed protocol that has been shown to be reliable and robust, and
	that allows lightweight implementations, but that does not preclude		that allows lightweight implementations, but that does not preclude
	the selection of a newer protocol for which a high quality open		the selection of a newer protocol for which a high quality open
	source implementation becomes available. Using information		source implementation becomes available. Using information
	distributed through the routing protocol, each node in the homenet		distributed through the routing protocol, each node in the homenet
	should be able to build a graph of the topology of the whole homenet		should be able to build a graph of the topology of the whole homenet
	including attributes such as links, nodes, connectivity, and (if		including attributes such as links, nodes, connectivity, and (if
	supported by the protocol in use) link metrics. In the latter case,		supported by the protocol in use) link metrics.
	link metrics may be configured or automatically derived per-link
	based on consideration of factors such as worst-case queue depth and
	router processing capabilities.
	The routing protocol should support the generic use of multiple		The routing protocol should support the generic use of multiple
	customer Internet connections, and the concurrent use of multiple		customer Internet connections, and the concurrent use of multiple
	delegated prefixes. A routing protocol that can make routing		delegated prefixes. A routing protocol that can make routing
	decisions based on source and destination addresses is thus		decisions based on source and destination addresses is thus
	desirable, to avoid upstream ISP BCP 38 ingress filtering problems.		desirable, to avoid upstream ISP BCP 38 ingress filtering problems.
	Multihoming support should also include load-balancing to multiple		Multihoming support should also include load-balancing to multiple
	providers, and failover from a primary to a backup link when		providers, and failover from a primary to a backup link when
	available. The protocol however should not require upstream ISP		available. The protocol however should not require upstream ISP
	connectivity to be established to continue routing within the		connectivity to be established to continue routing within the
	homenet.		homenet.
			Routing within the homenet will determine the least cost path across
			the homenet towards the destination address given the source address.
			The path cost will be computed as a linear sum of the metric assigned
			to each link. The metric may be configured or automatically derived
			per link based on consideration of factors such as worst-case queue
			depth and router processing capabilities.
	Multiple types of physical interfaces must be accounted for in the		Multiple types of physical interfaces must be accounted for in the
	homenet routed topology. Technologies such as Ethernet, WiFi,		homenet routed topology. Technologies such as Ethernet, WiFi,
	Multimedia over Coax Alliance (MoCA), etc. must be capable of		Multimedia over Coax Alliance (MoCA), etc. must be capable of
	coexisting in the same environment and should be treated as part of		coexisting in the same environment and should be treated as part of
	any routed deployment. The inclusion of physical layer		any routed deployment. The inclusion of physical layer
	characteristics including bandwidth, loss, and latency in path		characteristics including bandwidth, loss, and latency in path
	computation should be considered for optimising communication in the		computation should be considered for optimising communication in the
	homenet.		homenet.
	The routing environment should be self-configuring, as discussed		The routing environment should be self-configuring, as discussed
	skipping to change at page 30, line 21 ¶		skipping to change at page 30, line 26 ¶
	exchange routes such that IP traffic may be forwarded among the		exchange routes such that IP traffic may be forwarded among the
	networks via gateway routers which interoperate with both the homenet		networks via gateway routers which interoperate with both the homenet
	and the LLN. Current home deployments use largely different		and the LLN. Current home deployments use largely different
	mechanisms in sensor and basic Internet connectivity networks. IPv6		mechanisms in sensor and basic Internet connectivity networks. IPv6
	virtual machine (VM) solutions may also add additional routing		virtual machine (VM) solutions may also add additional routing
	requirements.		requirements.
	3.5.1. Multicast support		3.5.1. Multicast support
	It is desirable that, subject to the capacities of devices on certain		It is desirable that, subject to the capacities of devices on certain
	media types, multicast routing is supported across the homenet.		media types, multicast routing is supported across the homenet,
			including source-specific multicast (SSM) [RFC4607].
	[RFC4291] requires that any boundary of scope 4 or higher (i.e.,		[RFC4291] requires that any boundary of scope 4 or higher (i.e.,
	admin-local or higher) be administratively configured. Thus the		admin-local or higher) be administratively configured. Thus the
	boundary at the homenet-ISP border must be administratively		boundary at the homenet-ISP border must be administratively
	configured, though that may be triggered by an administrative		configured, though that may be triggered by an administrative
	function such as DHCP-PD. Other multicast forwarding policy borders		function such as DHCP-PD. Other multicast forwarding policy borders
	may also exist within the homenet, e.g., to/from a guest subnet,		may also exist within the homenet, e.g., to/from a guest subnet,
	whilst the use of certain link media types may also affect where		whilst the use of certain link media types may also affect where
	specific multicast traffic is forwarded or routed.		specific multicast traffic is forwarded or routed.
	skipping to change at page 43, line 48 ¶		skipping to change at page 44, line 13 ¶
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, March 2005.		RFC 4033, March 2005.
	[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and		[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, November 2005.		More-Specific Routes", RFC 4191, November 2005.
	[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for		[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
	Renumbering an IPv6 Network without a Flag Day", RFC 4192,		Renumbering an IPv6 Network without a Flag Day", RFC 4192,
	September 2005.		September 2005.
			[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
			IP", RFC 4607, August 2006.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and		[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
	E. Klein, "Local Network Protection for IPv6", RFC 4864,		E. Klein, "Local Network Protection for IPv6", RFC 4864,
	May 2007.		May 2007.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, September 2007.
	skipping to change at page 46, line 21 ¶		skipping to change at page 46, line 36 ¶
	James Woodyatt for their comments and contributions within homenet WG		James Woodyatt for their comments and contributions within homenet WG
	meetings and on the WG mailing list. An acknowledgement generally		meetings and on the WG mailing list. An acknowledgement generally
	means that person's text made it in to the document, or was helpful		means that person's text made it in to the document, or was helpful
	in clarifying or reinforcing an aspect of the document. It does not		in clarifying or reinforcing an aspect of the document. It does not
	imply that each contributor agrees with every point in the document.		imply that each contributor agrees with every point in the document.
	Appendix B. Changes		Appendix B. Changes
	This section will be removed in the final version of the text.		This section will be removed in the final version of the text.
	B.1. Version 15		B.1. Version 14
	Changes made include:
	o Removed spurious paragraph, and spurious sentence.
	B.2. Version 14
	Changes made include:		Changes made include:
	o Changes for Adrian Farrell discuss/comment.		o Changes for Adrian Farrell discuss/comment.
	o Very minor wordsmithing requested by Benoit for OAM text.		o Very minor wordsmithing requested by Benoit for OAM text.
	o Very minor wordsmithing from IETF89 session.		o Very minor wordsmithing from IETF89 session.
	o Added note to support SSM.		o Added note to support SSM.
	o Emphasised at most one routing protocol in use, possibly none.		o Emphasised at most one routing protocol in use, possibly none.
	B.3. Version 13		B.2. Version 13
	Changes made include:		Changes made include:
	o Changes to address last outstanding IESG DISCUSSes/COMMENTs.		o Changes to address last outstanding IESG DISCUSSes/COMMENTs.
	B.4. Version 12		B.3. Version 12
	Changes made include:		Changes made include:
	o Fixed minor typo nits introduced in -11.		o Fixed minor typo nits introduced in -11.
	o Elwyn Davies' gen-art review comments addressed.		o Elwyn Davies' gen-art review comments addressed.
	o Some further IESG DISCUSSes/COMMENTs addressed.		o Some further IESG DISCUSSes/COMMENTs addressed.
	B.5. Version 11 (after IESG review)		B.4. Version 11 (after IESG review)
	Changes made include:		Changes made include:
	o Jouni Korhonen's OPSDIR review comments addressed.		o Jouni Korhonen's OPSDIR review comments addressed.
	o Elwyn Davies' gen-art review comments addressed.		o Elwyn Davies' gen-art review comments addressed.
	o Considered secdir review by Samiel Weiler; many points addressed.		o Considered secdir review by Samiel Weiler; many points addressed.
	o Considered APPSDIR review.		o Considered APPSDIR review.
	o Addressed a large number of IESG comments and discusses.		o Addressed a large number of IESG comments and discusses.
	B.6. Version 10 (after AD review)		B.5. Version 10 (after AD review)
	Changes made include:		Changes made include:
	o Minor changes/clarifications resulting from AD review		o Minor changes/clarifications resulting from AD review
	B.7. Version 09 (after WGLC)		B.6. Version 09 (after WGLC)
	Changes made include:		Changes made include:
	o Added note about multicast into or out of site		o Added note about multicast into or out of site
	o Removed further personal draft references, replaced with covering		o Removed further personal draft references, replaced with covering
	text		text
	o Routing functionality text updated to avoid ambiguity		o Routing functionality text updated to avoid ambiguity
	o Added note that devices away from homenet may tunnel home (via		o Added note that devices away from homenet may tunnel home (via
	VPN)		VPN)
	o Added note that homenets more exposed to provider renumbering than		o Added note that homenets more exposed to provider renumbering than
	with IPv4 and NAT		with IPv4 and NAT
	o Added note about devices that may be ULA-only until configured to		o Added note about devices that may be ULA-only until configured to
	be globally addressable		be globally addressable
	o Removed paragraph about broken CERs that do not work with prefixes		o Removed paragraph about broken CERs that do not work with prefixes
	skipping to change at page 48, line 24 ¶		skipping to change at page 48, line 29 ¶
	o Stated that this text does not recommend how to form largest		o Stated that this text does not recommend how to form largest
	possible subnets		possible subnets
	o Added text about homenet evolution and handling disparate media		o Added text about homenet evolution and handling disparate media
	types		types
	o Rephrased NAT/firewall text on marginal effectiveness		o Rephrased NAT/firewall text on marginal effectiveness
	o Emphasised that multihoming may be to any number of ISPs		o Emphasised that multihoming may be to any number of ISPs
	B.8. Version 08		B.7. Version 08
	Changes made include:		Changes made include:
	o Various clarifications made in response to list comments		o Various clarifications made in response to list comments
	o Added note on ULAs with IPv4, where no GUAs in use		o Added note on ULAs with IPv4, where no GUAs in use
	o Added note on naming and internationalisation (IDNA)		o Added note on naming and internationalisation (IDNA)
	o Added note on trust relationships when adding devices		o Added note on trust relationships when adding devices
	o Added note for MPTCP		o Added note for MPTCP
	o Added various naming and SD notes		o Added various naming and SD notes
	o Added various notes on delegated ISP prefixes		o Added various notes on delegated ISP prefixes
	B.9. Version 07		B.8. Version 07
	Changes made include:		Changes made include:
	o Removed reference to NPTv6 in section 3.2.4. Instead now say it		o Removed reference to NPTv6 in section 3.2.4. Instead now say it
	has an architectural cost to use in the earlier section, and thus		has an architectural cost to use in the earlier section, and thus
	it is not recommended for use in the homenet architecture.		it is not recommended for use in the homenet architecture.
	o Removed 'proxy or extend?' section. Included shorter text in main		o Removed 'proxy or extend?' section. Included shorter text in main
	body, without mandating either approach for service discovery.		body, without mandating either approach for service discovery.
	skipping to change at page 49, line 31 ¶		skipping to change at page 49, line 38 ¶
	o Reordered section 3.3 to improve flow.		o Reordered section 3.3 to improve flow.
	o Added recommendation that homenet is not allocated less than /60,		o Added recommendation that homenet is not allocated less than /60,
	and a /56 is preferable.		and a /56 is preferable.
	o Tidied up first few intro sections.		o Tidied up first few intro sections.
	o Other minor edits from list feedback.		o Other minor edits from list feedback.
	B.10. Version 06		B.9. Version 06
	Changes made include:		Changes made include:
	o Stated that unmanaged goal is 'as far as possible'.		o Stated that unmanaged goal is 'as far as possible'.
	o Added note about multiple /48 ULAs potentially being in use.		o Added note about multiple /48 ULAs potentially being in use.
	o Minor edits from list feedback.		o Minor edits from list feedback.
	B.11. Version 05		B.10. Version 05
	Changes made include:		Changes made include:
	o Some significant changes to naming and SD section.		o Some significant changes to naming and SD section.
	o Removed some expired drafts.		o Removed some expired drafts.
	o Added notes about issues caused by ISP only delegating a /64.		o Added notes about issues caused by ISP only delegating a /64.
	o Recommended against using prefixes longer than /64.		o Recommended against using prefixes longer than /64.
	o Suggested CER asks for /48 by DHCP PD, even if it only receives		o Suggested CER asks for /48 by DHCP PD, even if it only receives
	less.		less.
	o Added note about DS-Lite but emphasised transition is out of		o Added note about DS-Lite but emphasised transition is out of
	scope.		scope.
	o Added text about multicast routing.		o Added text about multicast routing.
	B.12. Version 04		B.11. Version 04
	Changes made include:		Changes made include:
	o Moved border section from IPv6 differences to principles section.		o Moved border section from IPv6 differences to principles section.
	o Restructured principles into areas.		o Restructured principles into areas.
	o Added summary of naming and service discovery discussion from WG		o Added summary of naming and service discovery discussion from WG
	list.		list.
	B.13. Version 03		B.12. Version 03
	Changes made include:		Changes made include:
	o Various improvements to the readability.		o Various improvements to the readability.
	o Removed bullet lists of requirements, as requested by chair.		o Removed bullet lists of requirements, as requested by chair.
	o Noted 6204bis has replaced advanced-cpe draft.		o Noted 6204bis has replaced advanced-cpe draft.
	o Clarified the topology examples are just that.		o Clarified the topology examples are just that.
	skipping to change at page 51, line 38 ¶		skipping to change at page 51, line 47 ¶
	the homenet.		the homenet.
	o Added some ISPs renumber due to privacy laws.		o Added some ISPs renumber due to privacy laws.
	o Removed extra repeated references to Simple Security.		o Removed extra repeated references to Simple Security.
	o Removed some solution creep on RIOs/RAs.		o Removed some solution creep on RIOs/RAs.
	o Load-balancing scenario added as to be supported.		o Load-balancing scenario added as to be supported.
	B.14. Version 02		B.13. Version 02
	Changes made include:		Changes made include:
	o Made the IPv6 implications section briefer.		o Made the IPv6 implications section briefer.
	o Changed Network Models section to describe properties of the		o Changed Network Models section to describe properties of the
	homenet with illustrative examples, rather than implying the		homenet with illustrative examples, rather than implying the
	number of models was fixed to the six shown in 01.		number of models was fixed to the six shown in 01.
	o Text to state multihoming support focused on single CER model.		o Text to state multihoming support focused on single CER model.
End of changes. 29 change blocks.
	51 lines changed or deleted		51 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/