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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/