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

[Curtis Villamizar <[e-mail]>]

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