Re: [homenet] fwd: draft-ietf-homenet-arch-04

[Ray Hunter <[e-mail]>]

Why not just add RFC 6177 BCP 157 
http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in 
draft-ietf-homenet-arch?

That's a lot shorter than re-hashing the whole discussion within Homenet.

Curtis Villamizar wrote:
> Now that we beat summary item #12 to death, can we please turn our
> attention to the remaining 18 summary items listed below and the diffs
> to the draft?
>
> btw- I think the concensus on summary item #12 is that maybe we can
> add the following points to the framework.  Subnets longer than /64
> are bad.  Some devices don't support DHCPv6, therefore SLAAC is
> essential.  Consumer oriented service providers of must allow
> customers to easily request and get prefixes shorter than /64 and
> preferably at no additional cost if we are to avoid having to
> subdivide /64s.
>
> Curtis
>
> ------- Forwarded Message
>
> Message-Id:<[e-mail]>
> To: [e-mail]
> cc: [e-mail]
> Reply-To: [e-mail]
> Subject: draft-ietf-homenet-arch-04
> From: Curtis Villamizar<[e-mail]>
> Date: Sat, 22 Sep 2012 23:30:44 -0400
>
>
> Tim, Jari, Anders, Ole, Jason,
>
> I hope this is an OK time for comments on this draft.
>
> I just spent some time going through draft-ietf-homenet-arch-04 and I
> also took the time to look through all the RFCs and drafts that it
> references, even most of the expired ones.
>
> I edited in some diffs to the xml2rfc source.  Most of the diffs
> should be self explanitory, though I'm sure some will not be without
> controversy on the WG list.  I left in some XML comments where either
> I wanted to explain a change, or I would like to see some discussion
> on list.
>
> The xml file is at
> http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml
>
> The diffs are below.  Hopefully we can all read unified diffs of an
> xml file.  I'll also summarize some major points here.
>
>    1.  Must be capable of self configuring but should allow manual
>        config.
>
>    2.  A few citations could stand to be removed.  Some drafts are
>        expired and don't look like they were entirely completed.  Some
>        of the expired drafts look good but just managed to expire.
>
>    3.  I am proposing that we drop the "well known name" as a means to
>        discover the border(s).  This seems to me like a real bad idea.
>
>    4.  In "Global addressability and elimination of NAT"
>        (false-)security concerns about losing NAT are cited but no
>        advantage to global addressability is cited.  I think that is an
>        oversight but didn't add text here.  (yet)
>
>    5.  In a few places I've pointed out that firewalls (and NAT and
>        anti-virus) provide very ineffective security and we should be
>        very up front about saying so, though we can acknowledge that in
>        the absense of reasonably secure home products, we can't get rid
>        of them just yet.
>
>    6.  Proposals for IPv6-only MUST provide some accommodations for
>        legacy IPv4 only hosts or plain vanilla DS hosts.  I called this
>        IPv4 fallback on an otherwise IPv6 only network.  I split the
>        bullet on NAT64/DNS64 into two.
>
>        a.  As I had pointed out on the list, doing DNS64 at the CE (or
>            a router) will break any IPv4 only host.  The DNS64
>            translation should be done at the host.  The NAT64 can be
>            done at the CE (or any willing router).
>
>        b.  The DS-Lite B4 can be done on the host as long as DHCPv6
>            tells the host that an AFTR is availalbe.  If the CE gets
>            the FQDN of an AFTR as a DHCPv6 client on the WAN side it
>            can pass that along to hosts as a server on the DHCPv6
>            homenet side.  The DS-Lite B4 capable host can tunnel to the
>            AFTR and not make a DHCPv4 request (operate v6only).  The
>            plain DS and IPv4-only hosts can make DHCPv4 requests.  If
>            V4 packets arrive at the CE, the CE can act as a B4 if the
>            provider gave a AFTR FQDN in the WAN side DHCPv6.
>
>    7.  If some topology can casue things to be broken, then what the
>        homenet WG specified is broken.  Added some text on pathelogical
>        cases.  The only true pathological case is a loop in a set of
>        repeaters if a routing protocol is used and switches either
>        detect cycles or use IEEE spanning tree or link state protocols.
>
>    8.  Cascading NATs are common.  Added text as to why.
>
>    9.  Questioned why we mention VLANs.  An unsophisticated home user
>        is not likely to be playing with VLANs.
>
>   10.  Should we get rid of physical standard references?  I think so.
>
>   11.  Modified "bridge whenever possible" text.  Also "Largest
>        possible subnets" section title changed to "Largest practical
>        subnets" for reasons given in comments.
>
>   12.  This is sure to be controversial.  I pointed out that using
>        subnets longer than /64 is OK as long as they are not leaked
>        into global routing.  Please read the text and changes before
>        exploding on this topic.  It may be necessary to subnet a /64 if
>        that is all a provider will give you and you need subnets.  It
>        does work and it is no more unnatural than subnetting a class-A
>        network would be in 1990.  It means using DHCPv6 and not using
>        RA prefixes for GUA (otherwise SLAAC implementations would
>        likely try to use the whole bottom 64).
>
>   13.  There are a few minor wording changes, minor clarifications,
>        etc.
>
>   14.  There may be more fuss about confining interior routing within
>        a border than needed.  I added a paragraph that might help (or
>        might not).
>
>   15.  In the security section I added a subsection named "Marginal
>        Effectiveness of NAT and Firewalls".  (btw- Firewall horror
>        story at bar BOF on request.)
>
>   16.  Added "It has been suggested that Dynamic DNS could be made to
>        operate in a zero-configuration mode using a locally significant
>        root domain and with minimal configuration or using a DHCPv6
>        based (details to-be-defined) means of automated delegation
>        populate a global DNS zone."  Maybe a draft is needed on this
>        but for now please discuss on list.
>
>   17.  Suggest that any mechanism that is subnet-only has to be
>        extended to site *or abandoned by the WG* rather than proxied.
>        Old text said extended but not proxied (sic).
>
>   18.  Updated references (one draft is now RFC, one individual draft
>        is now WG draft, noted those that are expired).
>
>   19.  Question on "ISPs renumber due to privacy laws".  What's that
>        all about?
>
> Curtis
>
>
> BTW- The file still compiles and I made some updates to the references
> section which means the entity defines up front are edited.  I'm quite
> sure you'll want to pick and choose diffs or hand edit the changes you
> want back in.  Hopefully you'll want something.  :)
>
>
>
> - --- draft-ietf-homenet-arch-04.xml.orig	2012-07-16 10:00:38.000000000 -0400
> +++ draft-ietf-homenet-arch-04.xml	2012-09-22 22:06:24.000000000 -0400
> @@ -4,13 +4,17 @@
>
>   <!ENTITY rfc1918  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
>   <!ENTITY rfc2460  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
> +<!ENTITY rfc2462  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2462.xml'>
>   <!ENTITY rfc2775  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2775.xml'>
> +<!ENTITY rfc2827  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
>   <!ENTITY rfc3022  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml'>
> +<!ENTITY rfc3177  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3177.xml'>
>   <!ENTITY rfc3315  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
>   <!ENTITY rfc3633  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'>
>   <!ENTITY rfc3646  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'>
>   <!ENTITY rfc3736  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml'>
>   <!ENTITY rfc2475  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml'>
> +<!ENTITY rfc3972  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
>   <!ENTITY rfc4192  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192.xml'>
>   <!ENTITY rfc4193  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
>   <!ENTITY rfc4291  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
> @@ -52,8 +56,8 @@
>   <!ENTITY I-D.ietf-6man-rfc3484bis
>           PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc3484bis.xml'>
>
> - -<!ENTITY I-D.v6ops-multihoming-without-ipv6nat
> - -        PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.v6ops-multihoming-without-ipv6nat.xml'>
> +<!ENTITY I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat
> +        PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat.xml'>
>
>   <!ENTITY I-D.baker-homenet-prefix-assignment
>           PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-homenet-prefix-assignment.xml'>
> @@ -202,8 +206,9 @@
>   which case such networks may use increasing numbers of subnets, and
>   require methods for IPv6 prefixes to be delegated to those subnets.
>   The assumption of this document is that the
> - -homenet is as far as possible self-organising and self-configuring,
> - -and is thus not pro-actively managed by the residential user.
> +homenet is as far as possible
> +capable of self-organising and self-configuring,
> +and is thus need not be pro-actively managed by the residential user.
>   </t>
>
>   <t>The
> @@ -258,6 +263,9 @@
>   <t>"Advanced Security". Describes advanced security functions for a CER, as
>   defined in<xref target="I-D.vyncke-advanced-ipv6-security"></xref>,
>   where the default inbound connection policy is generally "default allow".</t>
> +<!-- perhaps the citation should be removed.  The draft is an
> +     individual submission, not clearly targeted at any particular WG,
> +     and has expired.  See comments in security section.  -->
>   <t>CER: Customer Edge Router. A border router at the edge of the homenet.</t>
>   <t>LLN: Low-power and lossy network.</t>
>   <t>NAT: Network Address Translation. Typically referring to IPv4
> @@ -283,10 +291,9 @@
>   <section anchor="trends" title="Effects of IPv6 on Home Networking">
>
>   <t>
> - -Service providers are deploying IPv6, content is becoming available on
> - -IPv6 (accelerated recently by the World IPv6 Launch event)
> - -and support for IPv6 is increasingly available in devices and
> - -software used in the home.  While
> +<!-- IMHO: We don't need more IPv6 hype.  Start paragrach here.
> +     Delete prior sentence. -->
> +While
>   IPv6 resembles IPv4 in many ways, it changes address allocation principles,
>   making multi-addressing the norm, and allowing direct IP addressability
>   of home networking
> @@ -323,9 +330,14 @@
>
>   <t>Documents that provide some more specific background and depth on this
>   topic include:
> - -<xref target="I-D.herbst-v6ops-cpeenhancements"></xref>,
> - -<xref target="I-D.baker-fun-multi-router"></xref>, and
> - -<xref target="I-D.baker-fun-routing-class"></xref>.</t>
> +<xref target="I-D.herbst-v6ops-cpeenhancements"></xref>,<!-- expired -->
> +<xref target="I-D.baker-fun-multi-router"></xref>, and<!-- expired -->
> +<xref target="I-D.baker-fun-routing-class"></xref>.</t>    <!-- expired -->
> +
> +<!-- The drafts above are expired.  I don't feel these references add
> +     much to the section except perhaps baker-fun-multi-router.  Note
> +     that a draft that references many others that go nowhere tends to
> +     itself go nowhere as a result. -->
>
>   <t>The addition of routing between subnets raises the issue of
>   how to extend mechanisms such as service discovery which currently rely
> @@ -340,6 +352,10 @@
>   Here, there are a number of choices.  These include
>   an appropriate service discovery protocol, or the use of a
>   well-known name, resolved by some local name service.
> +<!-- "Well known name" as a way to discover a border router is IMHO a
> +     really bad idea.  I don't remember this discussed on the WG
> +     mailing list.  By way of this comment, I would like to open the
> +     discussion of removing this text on "well known name". -->
>   Both might have to deal with handling more than one router responding
>   in multihomed environments.
>   </t>
> @@ -357,6 +373,9 @@
>   allowing every device on every link to be assigned a globally unique
>   IPv6 address.
>   </t>
> +<!-- Note that no advantage for global addressability is cited here,
> +     only security concerns.  Clearly this is an oversight because
> +     benefits have been discussed on the WG list quite a bit. -->
>   <t>
>   The end-to-end communication that is potentially enabled with IPv6 is
>   on the one hand an incredible
> @@ -373,6 +392,12 @@
>   would only be used on private networks or the device itself doesn't
>   have the computing power to apply the necessary security methods.
>   </t>
> +<!-- Those that supply these horribly insecure devices should be run
> +     off the planet.  This document should not make excuses for
> +     vendors that have ignored security but rather warn that the days
> +     when this was at all tolerable may be over.  At the same time we
> +     can acknowledge that some bandaids (firewalls) can exist in the
> +     interim and are at the moment necessary. -->
>   <t>
>   IPv6 networks may or may not have filters applied at their borders, i.e.
>   at the homenet CER.
> @@ -498,11 +523,33 @@
>   should be considered in IPv6-only environments:
>   <list style="symbols">
>
> - -<t>Ensuring there is a way to access content in the IPv4 Internet. This can
> +<t>Ensuring there is a way to access content in the IPv4 Internet.
> +<!-- note: split this into two sub-bullets - NAT64 and DS-Lite. -->
> +<list style="symbols">
> +<t>This can
>   be arranged through incorporating<xref target="RFC6144">NAT64</xref>
>   and<xref target="RFC6145">DNS64</xref>
>   functionality in the home gateway router, for instance. Such features
> - -are outside the scope of this document however, being CER functions.</t>
> +are outside the scope of this document however, being CER functions.
> +Legacy IPv4-only hosts could not function in a network for which the
> +DNS server implements DNS64.  Therefore a DNS64 NS may need to disable
> +DNS64 translation for DNS queries arriving via IPv4 transport.</t>
> +<t>This can also be arranged through use of
> +<xref target="I-D.ietf-v6ops-6204bis">DS-Lite</xref>, with the DS-Lite
> +B4 implemented in the host and the DS-Lite AFTR implemented in the
> +CPE, or the AFTR FQDN passed from the CPE to the host if AFTR is
> +offerred by the service provider.</t>
> +</list>
> +<!-- end of split into two sub-bullets. -->
> +</t>
> +<!-- The above usage of DS-Lite provides yet another means of
> +     supporting a IPv6-only subnet but does not conform the the way in
> +     which DS-Lite defined the deployment.  The purpose of DS-Lite is
> +     to allow the provider to eliminate IPv4 infrastructure (and with
> +     it the addresses).  The above usage doesn't change anything about
> +     DS-Lite except where it is deployed - B4 on host, AFTR on CPE or
> +     at the provider.  The goal is also different - gets rid of IPv4
> +     on the homenet side.  Discussion please. -->
>
>   <t>DNS discovery mechanisms are enabled for IPv6. Both stateless
>   DHCPv6<xref target="RFC3736"/>  <xref
> @@ -517,6 +564,12 @@
>   mode. Some current devices work well with dual-stack but fail to
>   recognise connectivity when IPv4 DHCP fails, for instance.</t>
>
> +<t>It is desirable for mechanisms which enable IPv6-only host
> +operation, to also support IPv4 as a fallback for legacy devices and
> +support DHCPv4 for legacy IPv4 only hosts and for IPv6 DS devices
> +which fail to operate without IPv4 and DHCPv4.</t>
> +<!-- We need to pick a IPv6-only solution that has a viable fallback
> +     so it can be enabled by default in CPE. -->
>   </list>
>   </t>
>   <t>
> @@ -551,7 +604,8 @@
>   expect the resulting network to operate.
>   Significant manual configuration is rarely, if at all, possible, given
>   the knowledge level of typical home users. Thus the network should,
> - -as far as possible, be self-configuring.
> +as far as possible, be self-configuring.  For the benefit of the
> +atypical more advanced user, manual configuration should be supported.
>   </t>
>   <t>
>   The equipment also needs
> @@ -623,6 +677,17 @@
>   infrastructure to allow the rest to operate. In such cases,
>   the user should ideally have some useful
>   indication of the failure mode encountered.</t>
> +<t>There are no topology secenarios which could cause loss of
> +connectivity,<!-- if the WG does a good job! -->  except when the user
> +creates a physical island within the topology.  Some potentially
> +pathological cases that can be created include bridging ports of a
> +router together, however this case can be detected and dealt with by
> +the router.  Routing cycles within a topology are in a sense good in
> +that they offer redundancy.  Bridging cyslces can be dangerous but are
> +also detectable when a switch learns the MAC of one of its interfaces
> +on another or runs a spanning tree or link state protocol.  It is only
> +cycles using simple repeaters that are truly pathological.</t>
> +<!-- Maybe cite IEEE specs - maybe not. -->
>   </section>
>
>   <section title="Network topology models">
> @@ -636,6 +701,14 @@
>   and private networks.
>   </t>
>   <t>
> +Cascading NATs are somewhat common in IPv4 home networks.  Many
> +devices such as SIP devices and some streaming video devices have a
> +WAN side and LAN side Ethernet port and in their installation
> +instructions either recommend or insist on being the device closest to
> +the WAN for QoS reasons.  A user may comply and string these together
> +resulting in two or three or potentially more cascaded IPv4 NAT.
> +</t>
> +<t>
>   In general, the models described in
>   <xref target="RFC6204"/>
>   and its successor RFC 6204-bis<xref target="I-D.ietf-v6ops-6204bis"/>
> @@ -656,6 +729,9 @@
>   subnets, with
>   no direct connectivity between them within the homenet.  Isolation may
>   be physical, or implemented via IEEE 802.1q VLANs.</t>
> +<!-- An unsophisticated home user that can't even type an IPv6 address
> +     knows how to set up IEEE 802.1q VLANs?  I don't think so, but I'm
> +     OK with leaving this mention of VLANs here.  Discussion? -->
>   <t>Demarcation of the CER.  The CER(s) may or may not be managed by
>   the ISP.  If the demarcation point is such that the customer
>   can provide or manage the CER, its configuration must be simple.  Both
> @@ -688,6 +764,23 @@
>   A separate discussion of physical infrastructures
>   for homenets is included in
>   and<xref target="I-D.arkko-homenet-physical-standard"/>.
> +<!-- Should we really cite this?  I don't remember any discussion of
> +     it on the WG mailing list and it is not a WG doc (and expired). -->
> +<!-- Note that this isn't even a very good draft as existing home
> +     wiring includes legacy alarm system (single pair, often #20 or
> +     #22 wire), thermostat wiring (single pair, #18 by electrical
> +     code), cat-3 (2 pair UTP by standard, 1 pair used), legacy
> +     telephone wire hack (using alarm or thermostat wire), RG58 coax
> +     for cable TV, junk coax (home owner or hack installer for cable
> +     TV), older cat-5 UTP for older Ethernet, maybe even RG59 coax for
> +     coax Ethernet, probably no Ethernet "fat coax", more modern
> +     cat5e, cat6, or cat6e coax.  Most home wire runs are short enough
> +     that GbE can run over all but the cheapest old cat5 wiring.
> +     OTOH, even small houses can have WiFi weak signal spots due to
> +     something as simple as a large chimney with a cast iron liner to
> +     conduct more heat into the surounding brick or stone.  Basicly
> +     its a mess.  IMHO We should not be writing premise wiring
> +     requirements. -->
>   </t>
>   <t>
>   In the following sections we give some examples of the types of
> @@ -707,7 +800,8 @@
>   topology itself may also be complex, and it may not be possible to
>   assume a pure tree form, for instance (home
>   users may plug routers together to form arbitrary topologies
> - -including loops).</t>
> +including cycles.</t>
> +<!-- note: routes loop - that's bad, topologies cycle - that's OK -->
>
>
>           <figure align="left" anchor="Figure.1 ">
> @@ -863,7 +957,9 @@
>   A general recommendation is to follow the same topology for IPv6
>   as is used for IPv4, but not to use NAT. Thus there should be
>   routed IPv6 where an IPv4 NAT is used, and where there is no NAT
> - -there should be bridging if the link layer allows this.
> +routing or bridging may be used.  Routing may have advantages over
> +bridging together high speed and lower speed shared media and bridging
> +may not be suitable for some media, such as ad-hoc mobile networks.
>   </t>
>   <t>
>   In some cases IPv4 NAT
> @@ -925,12 +1021,14 @@
>   typically include<xref target="I-D.ietf-6man-rfc3484bis"/>.  Applications may
>   of course do different things, and this should not be precluded.
>   </t>
> +<!-- note: ietf-6man-rfc3484bis is now RFC 6724 -->
>
>   <t>
>   For the single CER Network Model C, multihoming may be offered by source
>   routing at the CER. With multiple exit routers, the complexity rises.
>   Given a packet with a source address on the network, the
> - -packet must be routed to the proper egress to avoid BCP 38
> +packet must be routed to the proper egress to avoid BCP 38
> +(<xref target="RFC2827"/>)
>   filtering at an ISP that did not delegate the prefix the address is
>   chosen from.  While
>   the packet might not take an optimal path to the correct exit CER, the
> @@ -939,11 +1037,12 @@
>   that the packet is routed in the most efficient manner to the correct
>   exit.
>   </t>
> +<!-- BCP 38 (aka RFC2827) should be cited in the references -->
>
>   <t>
>   There are various potential approaches to this problem, one example
>   being described in
> - -<xref target="I-D.v6ops-multihoming-without-ipv6nat"/>.
> +<xref target="I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"/>.
>   Another is discussed in<xref target="I-D.baker-fun-multi-router"/>,
>   which explores support for source routing throughout the homenet.
>   This approach would however likely require relatively significant
> @@ -951,6 +1050,8 @@
>   given the source address.  Such changes should preferably be
>   minimised.
>   </t>
> +<!-- v6ops-multihoming-without-ipv6nat is replaced by
> +     draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 -->
>
>   <t>There are some other multihoming considerations for homenet
>   scenarios.  First, it may be the case that
> @@ -967,6 +1068,7 @@
>   While we should not specifically target walled garden multihoming as
>   a principal goal, it should not be precluded.
>   </t>
> +<!-- townsley-troan-ipv6-ce-transitioning expired - good draft though -->
>
>   <t>
>   Host-based methods such
> @@ -1049,7 +1151,7 @@
>   </section>
>
>
> - -<section title="Largest possible subnets">
> +<section title="Largest practical subnets">
>   <t>
>   Today's IPv4 home networks generally have a single subnet, and
>   early dual-stack deployments have a single congruent IPv6 subnet,
> @@ -1063,9 +1165,11 @@
>   routers and thus need multiple subnets, for
>   the reasons described earlier.  As part
>   of the self-organisation of the network, the homenet should subdivide
> - -itself to the largest possible subnets that can be constructed within
> +itself to the largest practical subnets that can be constructed within
>   the constraints of link layer mechanisms, bridging, physical
> - -connectivity, and policy.
> +connectivity, policy, and where applicable performance or other
> +criteria.  For example, bridging a busy GbE subnet and a wireless
> +subnet together may impact wireless performance.
>   </t>
>   <t>
>   While it may be desirable to maximise the chance of link-local
> @@ -1073,6 +1177,15 @@
>   multi-subnet home networks are inevitable, so their support must be
>   included.
>   </t>
> +<!-- Note that some of the largest *possible* subnets were created in
> +     the late 1980s and all converted to routing by the very early
> +     1990s.  These were a few NSFNET regional networks who proved that
> +     extremely large bridged subnets were possible, but performance at
> +     some point became abysmal.  At least two converted well after
> +     having reach the point of abysmal performance.  Though homenets
> +     won't have those sort of scaling problems, bridging a busy GbE
> +     and a 10 Gb/s wireless can significantly impact performance,
> +     therefore the word "practical" replaces "possible" above. -->
>
>   </section>
>
> @@ -1109,6 +1222,31 @@
>   homenet will need to adapt to the prefixes made available to it
>   through the prefix delegation method used by its upstream ISP.
>   </t>
> +<t>
> +It is important to note that for the purpose of a homenet, a /64
> +prefix is subdividable.<xref target="RFC3177"/>  specifically states
> +"Subnet numbers must be assumed to come from the network part.  This
> +is not to preclude routing protocols such as IS-IS level 1
> +(intra-area) routing, which routes individual host addresses, but says
> +that it may not be depended upon in the world outside that zone."
> +Prefixes longer than /64 are not globally routable but may be used by
> +protocols such as IS-IS or OSPF to subdivide a /64.  Subdividing a /64
> +effectively requires a managed address space, disallowing allocation
> +within that /64 though SLAAC<xref target="RFC2462"/>  and disallowing
> +any technique which requires the use of the full lower 64 bits such as
> +CGA<xref target="RFC3972"/>.
> +</t>
> +<!-- I expect this to be controversial.  To some subnetting a /64 is
> +     herasy, but it does work and in some cases may be needed. -->
> +<t>
> +If faced with allocation of a /64 prefix, or a prefix that is too
> +short to support a /64 for each subnet it may be necessary to
> +subdivide one or more /64.  This need may arise if some providers
> +refuse to allocate anything but a /64 to home users, small office
> +users, or very small businesses.  The need to get the network running
> +may have to be weighed against other needs such as CGA.
> +</t>
> +<!-- It may be that CGA is not needed in most homenets. -->
>
>   <section title="Use of ISP-delegated IPv6 prefixes">
>   <t>
> @@ -1123,7 +1261,8 @@
>   and thus make no assumptions about the stability of the prefix
>   received from an ISP, or the length of the prefix that may be offered.
>   However, if only a /64 is offered by the ISP, the homenet may be
> - -severely constrained, or even unable to function.
> +severely constrained, or even unable to function if the /64 cannot be
> +subdivided due to conflicting requirements (such as CGA).
>   </t>
>   <t>
>   The internal operation of the home network should also not depend on
> @@ -1142,6 +1281,12 @@
>   their prefix pool) changing. It is not expected that ISPs will support
>   Provider Independent (PI) addressing for general residential homenets.
>   </t>
> +<!-- Provider do not allocate fixed or very long lease IPv4 addresses
> +     because of the short supply of IPv4 addresses.  There should be
> +     no shortage of IPv6 prefixes, therefore no reason not to allocate
> +     a fixed prefix or at least grant a ver long lease time.  Chance
> +     of getting a PI prefix for a homenet is equal to some epsilon
> +     where epsilon rapidly approaches zero. -->
>   <t>
>   When an ISP needs to restructure and in doing so renumber its customer
>   homenets, "flash" renumbering is likely to be imposed.  This implies a need
> @@ -1154,6 +1299,8 @@
>   is an extended version of an initial numbering process, the difference
>   between flash renumbering and an initial "cold start" is the need to
>   provide service continuity.
> +The depricated addresses would remain usable within the homenet as
> +described in<xref target="RFC4192"></xref>.
>   </t>
>   <t>
>   There may be cases where local law means some ISPs are required to change
> @@ -1177,6 +1324,11 @@
>   The introduction of any new homenet protocols should not make any form of
>   renumbering any more complex than it already is.
>   </t>
> +<!-- Given that one very large MSO is currently offering trial service
> +     allocating one /128 per customer (an incompetent offering IMHO),
> +     it is not unreasonable to expect that some providers may only
> +     offer a /64 to a homenet.  If so, the /64 will need to be
> +     subdivided if there are any subnets at all in the homenet. -->
>
>   </section>
>
> @@ -1213,6 +1365,30 @@
>   scope through filtering at the border(s) of the homenet, as described
>   in RFC 6092.
>   </t>
> +<t>
> +If a routing protocol (or static routing) is not used, then ULA or GUA
> +connectivity across subnets cannot occur.  ULA connectivity requires
> +that host routes (IPv6 /128 routes) be used.  In a very large network
> +this would pose a scaling issue.  Homenets should be sufficiently
> +small that scalability is not at all an issue, even is the absence of
> +the route aggregation afforded by GUA subnet routes.  An interior
> +routing protocol adjacency (IS-IS or OSPF) should not be attempted by
> +default on a provider interface, and will generally require a shared
> +secret with the provider, implying a need for configuration.  If such
> +an adjacency is configured, route summarization of GUA routes is
> +required and no ULA routes should be advertised to the provider.  Any
> +sensible provider will provide route filters on their end.  More
> +likely no routing protocol adjacency will exist between the homenet CE
> +and the provider.  For medium sized businesses (not a homenet) a BGP
> +adjacency might be used, but still no OSPF or IS-IS adjacency.
> +Similarly the provider would pay no attention to distance vector
> +routing protocol information erroneously sent from the homenet.  The
> +homenet interior routing information would therefore always be
> +confined to the homenet.
> +</t>
> +<!-- Note that some of the problems this WG faces could be solved by
> +     carrying some extra information in OSPFv3 much as TE information
> +     is carried through opaque LSA extensions - or in IS-IS. -->
>
>   </section>
>
> @@ -1230,7 +1406,8 @@
>   <xref target="RFC3633"/>.
>   Then each subnet in the homenet should receive a prefix from within the
>   ISP-provided prefix(es).  The ISP should only see the aggregate from
> - -the homenet, and not single /64 prefixes allocated within the homenet.
> +the homenet, and not single /64 (or longer) prefixes allocated within
> +the homenet.
>   </t>
>
>   <t>  Delegation should be autonomous, and not assume a flat or
> @@ -1281,14 +1458,18 @@
>   <t>
>   Several proposals have been made for prefix delegation within a homenet.
>   One group of proposals is based on DHCPv6 PD, as described in
> - -<xref target="I-D.baker-homenet-prefix-assignment"/>,
> - -<xref target="I-D.chakrabarti-homenet-prefix-alloc"/>,
> +<xref target="I-D.baker-homenet-prefix-assignment"/>,<!-- expired -->
> +<xref target="I-D.chakrabarti-homenet-prefix-alloc"/>,<!-- expired -->
>   <xref target="RFC3315"/>  and<xref target="RFC3633"/>.
>   The other uses OSPFv3, as described in
>   <xref target="I-D.arkko-homenet-prefix-assignment"/>.
>   More detailed analysis of these approaches needs to be made against the
>   requirements/principles described above.
>   </t>
> +<!-- Note that the DHCPv6 solutions don't work well in tough cases
> +     like multihoming with cycles in the topology.  Knowing the
> +     topology is helpful.  Using DHCPv6 is very DV-like rather than
> +     LS-like and therefore may have trouble with topology cycles. -->
>   </section>
>
>   <section title="Privacy">
> @@ -1385,6 +1566,8 @@
>   evaluations of common routing protocols made against the type of requirements
>   described above.
>   </t>
> +<!-- howard-homenet-routing-comparison expired and I'm not sure it has
> +     been discussed enough on the WG list. -->
>
>   </section>
>
> @@ -1406,10 +1589,41 @@
>   to be able to operate securely, end-to-end where required, but also be
>   robust against malicious traffic direct towards them.  We simply
>   note at
> - -this point that software on home devices will have an increase in
> +this point that software on home devices may have an increase in
>   security if it allows its software to be updated regularly.
>   </t>
>
> +<section title="Marginal Effectiveness of NAT and Firewalls">
> +<t>
> +Security by way of obscurity (address translation) or through
> +firewalls (filtering) is at best marginally effective.  The very poor
> +security track record of home computer, home networking and business
> +PC computers and networking is testomony to its ineffectiveness.  A
> +compromise behind the firewall of any device exposes all others,
> +making an entire network that relies on obscurity or a firewall as
> +vulnerable as the most insecure device on the private side of the
> +network.
> +</t>
> +<t>
> +However, given home network products with very poor security, putting
> +a firewall in place does provide some protection, even if only
> +marginally effective.  IPv6 global reachability may increase the need
> +to solve the underlying problem of certain insecure home and business
> +computer and network products.  The use of firewalls today, whether a
> +good practice or not, is common practice and whatever protection
> +afforded, even if marginally effective, must not be lost.
> +</t>
> +<!-- Begin soap box: As someone who has played a major role in
> +     providing a highly secure (formally audited by the best of them)
> +     network without using a firewall, I am deeply disappointed and
> +     dismayed that the PC industry, Microsoft in particular, but other
> +     home products as well, provides such security hole ridden product
> +     and then expects a firewall to protect it and anti-virus programs
> +     to fix it after the breach has occurred.  Yes I know that making
> +     sure network programs are free of security holes is hard but
> +     firewalls and anti-virus programs are clearly not the answer. -->
> +</section>
> +
>   <section title="Addressability vs reachability">
>   <t>
>   An IPv6-based home network architecture should embrace
> @@ -1465,6 +1679,8 @@
>   to be configured on a CER.  Such methods should be able to
>   be automatically updating.
>   </t>
> +<!-- Advance firewalling == primitive security.  Maybe rename the
> +     draft. :) -->
>   </section>
>
>
> @@ -1577,7 +1793,11 @@
>   There are naming protocols that are designed to be configured and
>   operate Internet-wide, like unicast-based DNS, but also protocols
>   that are designed for zero-configuration local environments, like
> - -mDNS.  Consideration should be made for how these interact with each
> +mDNS.  It has been suggested that Dynamic DNS could be made to operate
> +in a zero-configuration mode using a locally significant root domain
> +and with minimal configuration or using a DHCPv6 based (details
> +to-be-defined) means of automated delegation populate a global DNS
> +zone.  Consideration should be made for how these interact with each
>   other in a homenet scenario.
>   </t>
>
> @@ -1634,6 +1854,8 @@
>   to multicast service discovery requests. Those same parts
>   of the network may have less capacity for multicast traffic that
>   may be flooded from other parts of the network.
> +<!-- note that this slower network segment overload occurs only when
> +     bridging is used where routing should have been used -->
>   In general, message utilisation should be efficient considering
>   the network technologies the service may need to operate over.
>   </t>
> @@ -1650,7 +1872,7 @@
>
>   <t>
>   Current service discovery protocols are generally aimed at single
> - -subnets.  If service discovery is to operate across the an entire
> +subnets.  If service discovery is to operate across an entire
>   homenet, by adopting an approach like that proposed as Extended mDNS
>   (xmDNS)<xref target="I-D.lynn-homenet-site-mdns"></xref>, then
>   support may be required for IPv6 multicast across the scope of the
> @@ -1682,12 +1904,14 @@
>   <t>
>   The homenet architecture proposes that any existing
>   protocols that are designed to only work within a subnet should be extended
> - -to work across subnets, rather than defining proxy capabilities
> +to work across subnets or not used by homenet,
> +rather than defining proxy capabilities
>   for each of those functions. However, while
>   it is desirable to extend protocols to site scope operation rather
>   than providing proxy functions on subnet boundaries, the
>   reality is that until all hosts can use site-scope discovery protocols,
> - -existing link-local protocols would need to be proxied anyway.</t>
> +existing link-local protocols would need to be proxied anyway or other
> +solutions found which are not link local in scope.</t>
>   <t>
>   Some protocols already have proxy functions defined and in use, e.g.
>   DHCPv6 relays, in which case those protocols would be expected to
> @@ -1812,10 +2036,14 @@
>   <references title="Informative References">
>
>           &rfc1918;
> +	&rfc2462;
>           &rfc2475;
>           &rfc2775;
> +	&rfc2827;
>   	&rfc3022;
> +	&rfc3177;
>           &rfc3646;
> +	&rfc3972;
>   	&rfc4192;
>           &rfc5533;
>           &rfc5969;
> @@ -1826,22 +2054,26 @@
>           &rfc6296;
>           &rfc6333;
>           &rfc6555;
> - -&I-D.baker-fun-multi-router;
> - -&I-D.lynn-homenet-site-mdns;
> - -&I-D.townsley-troan-ipv6-ce-transitioning;
> - -&I-D.baker-fun-routing-class;
> - -	&I-D.howard-homenet-routing-comparison;
> - -&I-D.herbst-v6ops-cpeenhancements;
> - -&I-D.vyncke-advanced-ipv6-security;
> - -	&I-D.ietf-6man-rfc3484bis;
> - -	&I-D.v6ops-multihoming-without-ipv6nat;
> - -	&I-D.baker-homenet-prefix-assignment;
> +&I-D.baker-fun-multi-router;			<!-- expired -->
> +&I-D.lynn-homenet-site-mdns;			<!-- expired -->
> +&I-D.townsley-troan-ipv6-ce-transitioning;	<!-- expired -->
> +&I-D.baker-fun-routing-class;			<!-- expired -->
> +	&I-D.howard-homenet-routing-comparison;		<!-- expired -->
> +&I-D.herbst-v6ops-cpeenhancements;		<!-- expired -->
> +&I-D.vyncke-advanced-ipv6-security;		<!-- expired -->
> +	&I-D.ietf-6man-rfc3484bis;			<!-- RFC 6724 -->
> +	&I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat;
> +	&I-D.baker-homenet-prefix-assignment;		<!-- expired -->
>   	&I-D.arkko-homenet-prefix-assignment;
>   	&I-D.acee-ospf-ospfv3-autoconfig;
> - -	&I-D.ietf-pcp-base;
> - -	&I-D.hain-ipv6-ulac;
> - -&I-D.chakrabarti-homenet-prefix-alloc;
> - -&I-D.arkko-homenet-physical-standard;
> +	&I-D.ietf-pcp-base;				<!-- IESG eval -->
> +	&I-D.hain-ipv6-ulac;				<!-- expired -->
> +&I-D.chakrabarti-homenet-prefix-alloc;		<!-- expired -->
> +&I-D.arkko-homenet-physical-standard;		<!-- expired -->
> +
> +<!-- Note: expired is FYI.  We just need to watch for abandonned ideas
> +     or ones that were strongly rejected on the WG mailing list.  One
> +     draft above is now an RFC.  One is in IESG eval. -->
>
>           <reference anchor='Gettys11' target="http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf">
>           <front>
> @@ -1953,7 +2185,7 @@
>   <t>Clarified simple and advanced security some more, and RFC 4864 and 6092.</t>
>   <t>Stated that there should be just one secret key, if any are used at all.</t>
>   <t>For multihoming, support multiple CERs but note that routing to the correct CER to avoid ISP filtering may not be optimal within the homenet.</t>
> - -<t>Added some ISPs renumber due to privacy laws.</t>
> +<t>Added some ISPs renumber due to privacy laws.</t>   <!-- huh? explain. -->
>   <t>Removed extra repeated references to Simple Security.</t>
>   <t>Removed some solution creep on RIOs/RAs.</t>
>   <t>Load-balancing scenario added as to be supported.</t>
>
> ------- End of Forwarded Message
>
>