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

From: Curtis Villamizar <[email-masked]>
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>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 22 Sep 2012 23:37:26 -0400

Since you invited flames...

The argument on /64 as the longest prefix is not that it is magically 
unnatural.
Rather, it is that there are a number of current and evolving protocols 
that depend upon that /64.  The obvious example is that SLAAC does not 
work if subnets are longer than /64.

The rules in this regard are written into approved RFCs.  If homenet 
wants to change that, it really needs to go to 6man with a strong case. 
  (for point-to-point inter-router links this was recently relaxed.

At the same time, andy operator who insists on giving homes a /64 is 
being inappropriately restrictive.  Homenet should say that, rather than 
trying to change the IPv6 architecture.

Yours,
Joel

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Sep 2012 19:09:15 -0400

In message <[email-masked]>
 
> trying to change the IPv6 architecture.

Joel,

I don't consider your email a flame at all.  Thanks for responding.

SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO
no loss.  CGA also won't work but then again I've also never been a
fan of security half measures.  Yes anti-spoofing without prior
exchange of a key is nice, but no reasonable authorization could be
based on CGA without also exchanging some sort of key or cert and at
that point the CGA as a public key is redundant.

If SLAAC and CGA are the only things that break *and* providers do
hand out prefixes that are too small, then /64 prefixes will have to
be subdivided.

So a question for you is what else if anything will break?

I also understand that you are suggesting that this be taken to 6man.
That is a good suggestion.

Curtis

---

From: Don Sturek <[email-masked]>
Date: Sun, 23 Sep 2012 17:36:25 -0700

Hi Curtis,

SLAAC not working is a major problem.

Don

On 9/23/12 4:09 PM, "Curtis Villamizar" <[email-masked]> wrote:

>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2012 14:49:56 -0400

> SLAAC not working is a major problem.

Don,

Why?  This is an assertion without basis as far as I am concerned.
Except CGA there is nothing that breaks without SLAAC.  Joel brought
up ILNP in private email, but I beleive ILNP can also work as the
constraints in ILNP are in the ILNP identifier which is not the same
as the interface address in ILNP for which there is no constraint.

I have subnets running fine using a few /112 allocated from within a
/64 with fixed addresses on rack mount hosts and desktops and DHCPv6
for dynamic allocations for laptops.  It works fine.  Link local
addresses are all that is needed to get DHCPv6 to work.  No host ever
receives a RA since my routers won't give them one, so no host ever
tries to generate an address using SLAAC.  The only constraint is that
any host connecting to my Ethernet or wireless must run a DHCP client
and if they want an IPv6 GUA must run a DHCPv6 client.  DHCPv4 and
DHCPv6 servers are available in every subnet except one GbE subnet in
the rack and to a few hosts in my home office.

So as far as I am concerned we have an assertion that no SLAAC is a
problem and existance proof that it is not.  Beside CGA and requiring
that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support
on these /112 subnets?

Curtis

---

From: Don Sturek <[email-masked]>
Date: Mon, 24 Sep 2012 12:17:03 -0700

Hi Curtis,

Here is the use case:
1)  Customer has a legacy AP in their house
2)  Customer brings home new devices supporting IPv6 (which are designed
to communicate only with other IPv6 based devices in the home)
3)  The only way these new devices can communicate is through address
assignment using SLAAC and then some discovery method the two new devices
support (without support from the AP).  Here these devices are assuming
bridging through the AP......

Placing a requirement that every customer who buys a new IPv6 device,
intended to communicate only with other IPv6 devices in the home, will
require a forklift upgrade of a deployed network in order to work will not
be popular.

Don

On 9/24/12 11:49 AM, "Curtis Villamizar" <[email-masked]> wrote:

>> >> >        exploding on this topic.  It may be necessary to subnet a
>>/64
>> >>if

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Sep 2012 16:08:39 -0400

> bridging through the AP......

And since current legacy AP's all bridge, we win (even though we need to
route in the future).
> require a forklift upgrade of a deployed network in order to work will not

Good point.

I loathe DHCP (of any sort) *for basic address assignment, anyway* in
the home environment.

The loathing comes from the exquisite pain of suffering with a flaky
home network  for several months, before realising I had a rogue DHCP
server somewhere on my network (from wireshark).  I then had to take the
mac address, figure out who may have manufactured some device from that
information, and finally figured out the little VOIP ATA adaptor I had
been given liked to do DHCP.

This was by far the hardest debugging I've had to do in my home network
in normal operation.

This is well beyond normal home debugging capability of consumers.
            - Jim

                - Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2012 18:24:10 -0400

> bridging through the AP......

Fine.  Use link local addresses.  SLAAC simply can't be used with the
GUA prefix.  SLAAC can be used with link local or ULA.

Does this mean problem solved?

> require a forklift upgrade of a deployed network in order to work will not

Maybe I wasn't clear in the summary paragraph.  SLAAC can still be
used but not for GUA.  For the GUA DHCPv6 can be used and SLACC has to
be avoided *if* the provider forced subdividing a /64 by refusing to
allocate a prefix large enough (for example a fixed policy of /64 only
for homes).

I am not suggesting depricating SLAAC or not implementing it.  All I
am suggesting is that *if* you have a prefix that is too small, then
you can sacrifice CGA but still support all the subnets you need by
not providing an RA and providing DHCPv6 for the GUA prefixes that
need to be longer than /64 within the homenet.

If providers are all cooperative and are all willing to give out short
enough prefixes, then the "if" in the prior paragraph never evaluates
to "true" and the suggestion is a NOOP.

I hope that was a bit more clear.

btw- It seems to me that some respondents are reading the diffs to the
draft and are replying only to the summary (or worse yet replying only
to Joel's comment on summary point #12).  Any reply is better than
none, but please also read the diffs to the draft.

Curtis

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Sep 2012 18:36:13 -0400

> This was by far the hardest debugging I've had to do in my home network

In all fairness, the exact same kind of brokenness can happen with rogue RA messages, and a non-geek will have an equally hard time diagnosing it.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Sep 2012 15:52:55 -0700

> In all fairness, the exact same kind of brokenness can happen with rogue RA messages, and a non-geek will have an equally hard time diagnosing it.

I'm trying to think of whether it's worse with v6: with v6 it at least
shows every address that it's auto-configured rather than the luck
of the draw for dhcp of whether you at any renew time happen to
get the rogue server. Not that normal human beings have ever typed
"ifconfig".

Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Sep 2012 19:23:05 -0400

> get the rogue server. Not that normal human beings have ever typed

If you have a good happy eyeballs implementation, an IPv6 host ought to be able to ride right over it, as long as the rogue router isn't doing an MiTM attack.

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Sep 2012 19:37:35 -0400

> In all fairness, the exact same kind of brokenness can happen with rogue RA messages, and a non-geek will have an equally hard time diagnosing it.

The worst of this was that the little box was much slower than my
regular dhcp server, so it was like a 20% failure rate.

Sigh.

Be that as it may, relying on dhcp to get addresses strikes me as much
more error prone.

- Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2012 20:11:01 -0400

> And since current legacy AP's all bridge, we win (even though we need to

Jim,

The point was how do you get local IPv6 within the home with the
legacy AP that does only IPv4 and just does bridging of IPv6.  First
of all you have no subnets.  There is no CER to do DHCPv6.

In this case you use link local or if everything has a MAC you can use
ULA based on the MAC addressses.

> > require a forklift upgrade of a deployed network in order to work will not

But invalid.  The use case Don gave would still work fine.  Only GUA
addresses are affected.

> been given liked to do DHCP.

It did DHCP on the *WAN side*?  You didn't put the rest of your
network behind the VOIP box on the LAN side I hope.

> This is well beyond normal home debugging capability of consumers.

We all have plenty of crappy IPv4 product horror stories.  My VOIP
phone locked up now and then and I figured out that if the call lasted
longer than the DHCPv4 lease, then it lost the least because it didn't
try to renew it.  Not only did the call drop, but the device locked
up.  The first solution was to reboot it now and then.  The answer was
to configure a fixed address.  I was lucky to figure it out before my
wife threw the phone through a window.  For all I know a later
firmware upgrade might have fixed it.  VOIP might be more popular if
VOIP phones under $600 worked reasonably well.

Both nice stories, but both are DHCPv4 related and have nothing at all
to do with SLAAC.

Curtis

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Sep 2012 20:16:55 -0400

> network behind the VOIP box on the LAN side I hope.

It did dhcp on my network; evil.  Only had one ethernet port, IIRC.

> Both nice stories, but both are DHCPv4 related and have nothing at all

My point is I don't like to depend on DHCP to get my addresses, as it
seems lots of people add them as a "feature" to this or that home
device, setting up for unhappy broken networks.

And it's really painful to debug when you can't even access the network
at all (which is the failure mode that was happening to me).
                    - Jim

---

From: Don Sturek <[email-masked]>
Date: Mon, 24 Sep 2012 18:01:29 -0700

Hi Curtis,

I would expect most Wi-Fi AP manufacturers to support the same address
assignment they do today (ie, manual assignment and DHCP).  I would also
expect as more IPv6 deployments happen that SLAAC will also be supported
(and, yes, even for GUA).

For the types of devices which will be added to Wi-Fi networks in the
future (eg, headless devices like appliances, thermostats, etc.) that the
preferred address assignment will be SLAAC and DHCPv6 (and, yes, I
purposely did not remove SLAAC.....)

Don

On 9/24/12 5:11 PM, "Curtis Villamizar" <[email-masked]> wrote:

>> >>>>> being inappropriately restrictive.  Homenet should say that,
>>rather
>> >>>>> than

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2012 21:52:14 -0400

In message <[email-masked]>
Don Sturek writes:
 
> assignment they do today (ie, manual assignment and DHCP).  I would
> also expect as more IPv6 deployments happen that SLAAC will also be
> supported (and, yes, even for GUA).
>  
> future (eg, headless devices like appliances, thermostats, etc.) that
> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I

Don,

We seem to be talking past each other so let me again try to be clear.

What every host does is:

  if it has no MAC:
    pick a random link local (not ULA) address
  else
    use the MAC to create a ULA address
  run DAD to make sure no one else has same address

  send a RS

  if it gets RA
    use the RA prefix for SLAAC
  else
    time out and don't bother with SLAAC

then hopefully the host also does the following:

  send DHCPv6 client request

  if response
    it has yet another address to pick from if it got one using SLAAC
  else
    time out and get nothing from DHCPv6

Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server
the address that it already has (from SLAAC).

If as in the case of your Wi-Fi with a bridging AP example, there is
no router to give it an DHCPv6 the link local or ULA addresses are
still there and still usable.  There is also no router to give it an
RA response so it has no SLAAC assigned address and no DHCPv6 assigned
address.

That is the end of your example.

If there is a router then there is something that can hand out a RA or
DHCPv6 response.

In the case were there exists multiple subnets and the CER has been
granted a /64 (or too few /64s to handle the number of subnets), then:

  it can use RA with /64 on some subnets and give them GUA addresses
  and some subnets have no access outside the homenet

  --or--

  it can not use RA (and therefore prevent SLAAC from being used) and
  hand out DHCPv6 addresses and make use of prefixes longer than /64.
  This prevents the use of CGA but get connectivity to the entire
  homenet.

If every consumer oriented provider is willing to allocate prefixes
shorter than /64 on request to home users, then the above situation
never occurs.  If it does, my argument is that the second option above
is better than the first.

Curtis

---

From: Don Sturek <[email-masked]>
Date: Mon, 24 Sep 2012 19:42:00 -0700

Hi Curtis,

I think the difficulty is each device cannot "use the MAC to create a ULA
address".  Some authoritative device in the network (eg, the AP) must
create the ULA prefix.  If a ULA prefix is not present because the AP is a
legacy device not capable of providing a ULA prefix, the STA devices must
use link locals only.

Don

On 9/24/12 6:52 PM, "Curtis Villamizar" <[email-masked]> wrote:

>> >> >>>>> that depend upon that /64.  The obvious example is that SLAAC
>>does
>> >> >>> not
>> >> >>>>> wants to change that, it really needs to go to 6man with a
>>strong
>> >> >>> case.
>> >> >>>>> At the same time, andy operator who insists on giving homes a
>>/64
>> >>is
>> >> >>>> based on CGA without also exchanging some sort of key or cert
>>and
>> >>at
>> >> >>>> hand out prefixes that are too small, then /64 prefixes will
>>have
>> >>to
>> >> >>>> be subdivided.
>> >> >>>>
>> >> >>>>>>        that is all a provider will give you and you need
>>subnets.
>> >> >>> It
>> >> >>>>>>        network would be in 1990.  It means using DHCPv6 and
>>not
>> >> >>> using

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Sep 2012 00:45:05 -0400

Don,

You are right about there being nothing to generate the ULA prefix in
your example.  My mistake.

But it doesn't change anything.  If the AP is a dumb bridge and there
is no router of any kind, then link local addresses are perfectly
fine.  There is only one subnet in that example, and ULA is not
needed.  That was the example you gave.

Your example had no router just an old AP that acted as a bridge,
therefore nothing to generate any sort of RA.  If there is a router
and no GUA prefix (which is not your example, but a useful example),
then ULA can be used.  The only RA that is seen is the RA providing a
ULA prefix which the router can generate.

I did say that the possibility of having to subdivide a /64 only
exists for GUA.  If a router exists which gets a GUA from a provider,
and there are more subnets than the prefix length can support the two
options are the ones listed below.  (Search for --or--).

Curtis

---

From: Robert Cragie <[email-masked]>
Date: Tue, 25 Sep 2012 09:57:05 +0100

So let's tweak Curtis' sequence slightly:

What every host does is:

  if it has no MAC:
    pick a random link local address
  else
    use the MAC to create a link local address
  run DAD to make sure no one else has same address

  send a RS

  if it gets RA
    use the RA prefix for SLAAC
  else
    time out and don't bother with SLAAC; can only use link local address

  if response

This should work fine for legacy APs where everything is bridged 
underneath it. Where it gets interesting is in the case of cascaded 
subnets behind a router connected to an ISP, where one or more of those 
subnets may be a mesh network comprised of mesh routers and hosts. I am 
not quite sure how ULAs and DHCPv6 would work in this case as there are 
limitations as far as I can see (although I accept I probably have a bit 
more reading to do on the subject).

Robert

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Sep 2012 14:35:30 +0100

> (and, yes, even for GUA).

It MUST be supported according to RFC 6204 and 6204bis (and of course
by all hosts, according to RFC 6434).

   Brian

---

From: Don Sturek <[email-masked]>
Date: Tue, 25 Sep 2012 09:47:22 -0700

Hi Robert,

One more point touched on in your note below:
1)  Ideally, it would be great if a single authorizatative device existed
in the home providing DHCPv6 server services (if supported) and prefix
delegation.

One challenge in the description below is having multiple routers on
multiple subnets, each possibly acting as a DHCPv6 server within their own
subnet and also providing their own ULA prefix.

We certainly don't want to further confuse address assignment in a setting
where IT support does not exist.

Don

On 9/25/12 1:57 AM, "Robert Cragie" <[email-masked]> wrote:

>>>>>>> server somewhere on my network (from wireshark).  I then had to
>>>>>>>take
>>>>> the
>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will
>>>>>>>>>>>so
>>>>>>> IMHO
>>>>>>>>>>>>>         into global routing.  Please read the text and
>>>>>>>>>>>>>changes
>>>>>>>>>> before
>>>>>>>>>>>>>         does work and it is no more unnatural than
>>>>>>>>>>>>>subnetting a
>>>>>>>>>> class-A

---

From: Teco Boot <[email-masked]>
Date: Tue, 25 Sep 2012 21:34:11 +0200

Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven:

Sorry to jump in.

> in the home providing DHCPv6 server services (if supported) and prefix
I don't agree. When adding another gateway, to another ISP, I would like 
such to be independent form the existing gear.
(3.2.2.2.  B: Two ISPs, Two CERs, Shared subnet)

> subnet and also providing their own ULA prefix.
When hosts get their addresses for each RA prefix, by using SLAAC and/or 
DHCPv6, what is the challenge? (protocol-wise, not current host behavior)

When hosts get only one GUA, they will use only one link to one ISP (no 
translation). For multi-path, this needs an update.

> where IT support does not exist.
Agreed, we need to improve address assignment. And routing based on 
destination & source addresses.

Teco

---

From: Don Sturek <[email-masked]>
Date: Tue, 25 Sep 2012 12:55:20 -0700

Hi Teco,

The main requirement I see is that a home network with multiple ISP
connections, multiple CERs and a shared subnet must support the ability to
discover services within the entire site (home) despite having devices
with differing ULA prefixes and GUA prefixes.

How would you see discovery working in such a home network?

Don

On 9/25/12 12:34 PM, "Teco Boot" <[email-masked]> wrote:

>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and,
>>>>>>>yes,
>>>>>>> I
>>>>>>>>>> assignment using SLAAC and then some discovery method the two
>>>>>>>>>>new
>>>>>>>>> devices
>>>>>>>>>> intended to communicate only with other IPv6 devices in the
>>>>>>>>>>home,
>>>>>>> will
>>>>>>>>>> require a forklift upgrade of a deployed network in order to
>>>>>>>>>>work
>>>>>>>>> will not
>>>>>>>>>> be popular.
>>>>>>>>> 
>>>>>>>>> Good point.
>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment,
>>>>>>>>>anyway*
>>>>>>>>> in
>>>>>>>>> the home environment.
>>>>>>>>> 
>>>>>>>>> mac address, figure out who may have manufactured some device
>>>>>>>>>from
>>>>>>> that
>>>>>>>>> information, and finally figured out the little VOIP ATA adaptor
>>>>>>>>>I
>>>>>>> had
>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work.  No
>>>>>>>>>>>host
>>>>>>> ever
>>>>>>>>>>> tries to generate an address using SLAAC.  The only constraint
>>>>>>>>>>>is
>>>>>>>>> that
>>>>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC
>>>>>>>>>>>is
>>>>>>> a
>>>>>>>>>>>>>> Rather, it is that there are a number of current and
>>>>>>>>>>>>>>evolving
>>>>>>>>>>>> protocols
>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and*
>>>>>>>>>>>>>providers
>>>>>>> do
>>>>>>>>>>>>> I also understand that you are suggesting that this be taken
>>>>>>>>>>>>>to
>>>>>>>>> 6man.
>>>>>>>>>>>>>>>   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

---

From: Teco Boot <[email-masked]>
Date: Tue, 25 Sep 2012 22:59:32 +0200

> How would you see discovery working in such a home network?

It might be the right moment to come up with my earlier work on border 
router discovery. I have to update to incorporate the homenet-arch, and
remove details for MANET/Autoconf. Intro & highlights:
http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt

If there is interest, I'll resubmit for Homenet. 

Teco

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 30 Sep 2012 15:48:15 -0400

In message <[email-masked]>
 
> by all hosts, according to RFC 6434).

Brian,

The "I would expect" wording is due to the very long lag between RFC
mandates and the consumer products on retailer shelves that support
those RFCs.  Consumer products have yet to catch up to the RFCs in the
2xxx and 3xxx RFC range let alone anything in the 6xxx range.

For example, the 4 port GbE and 2 Wifi channel AP I recently bought to
run cerowrt supported little more than bridging IPv6 with the vendor
firmware yet is advertised as having IPv6 support.  That is not even
the low end of consumer products.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 30 Sep 2012 18:36:47 -0400

> where IT support does not exist.

We want things to "just work" witb no config.  Link local on each
subnet and a routing protocol works for any topology.  ULA just allows
summarization of subnets in the routing protocol, such that host
routes are not needed (though not a big deal if host routes are used
in a homenet).

This would "just work" when using link local or ULA.  How to subdivide
a GUA prefix among the subnets is another issue.

In principle, though I know of no proposals to do this yet, the set of
GUA that are available from one of more routers with a provider link
could be coordinated via the routing protocol (for example, using a
new OSPF Opaque LSA).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 30 Sep 2012 19:02:50 -0400

> If there is interest, I'll resubmit for Homenet. 

Just looked at that draft.  It solves one of the problems, having more
than one GUA prefix.  It does not solve another closely related
problem, having more than one subnet behind the CER or border routers
(BR101 and BR201 in your diagram) where there is no prior
configuration.

In your "Figure 2: Scenario 2" all routers have the same set of
addresses on each of their interfaces.  This is not generally how
subnets are laid out.  Each interface on a router gets a different
link local address.  The /48 is usually split into a set of /64, one
per subnet.  In a managed network (enterprise, clueful soho, etc) the
split of a /48 into 16 or less /64s today is done by configuration
(configuration of prefixes on the routers or DHCP server and relays).

Curtis