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

On 2 Oct 2012, at 22:54, Curtis Villamizar <curtis@occnc.com> wrote:

> Now that we beat summary item #12 to death, can we please turn our
> attention to the remaining 18 summary items listed below and the diffs
> to the draft?

Hi Curtis, 

Many thanks for these suggestions.  

Comments in line.

> 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.

That was already in there, but have added your edit to the intro.

>  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.

We'll remove some of these.  This was also suggested in Vancouver.  Final judgements can be made as we approach WGLC, but I expect a bigger cull then if those documents are still expired with little sign of further work on them.  For now they may help inform the discussion.

>  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.

Done.

>  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)

Some advantages have been listed.  Some more text has been added.  I don't think we need to convince on the benefits of IPv6.

>  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.

Indeed.

>  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.

Fair enough, but that's not the focus here, and I've made that clear.

I haven't added information about IPv4 fallback, as that's not a focus of this text.

>  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.

We have said that as far as possible the architecture should support arbitrary topologies. Your paragraph is added.

>  8.  Cascading NATs are common.  Added text as to why.

This is already included in two places, so added a pointer.  We're trying to de-duplicate text where possible.

>  9.  Questioned why we mention VLANs.  An unsophisticated home user
>      is not likely to be playing with VLANs.

Note added.

> 10.  Should we get rid of physical standard references?  I think so.

That was a 'plug' for Jari's draft.  Now removed. I suggest you send your specific comments on that to him :)

> 11.  Modified "bridge whenever possible" text.  Also "Largest
>      possible subnets" section title changed to "Largest practical
>      subnets" for reasons given in comments.

That's a better choice of word, agreed.

> 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).

Not included (see other email).

> 13.  There are a few minor wording changes, minor clarifications,
>      etc.

Thanks - many included, some re-reworded :)

I have also left "loops" in, rather than "cycles" - I hope you don't mind.

> 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).

I think your comment about carrying extra information in OSPFv3 has at least in part been followed in Jari's work, for example.

> 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.)

Your soapbox is added, in brief!

> 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.

Added.

> 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).

Proxying is still in scope; I don't think we can rule that in our out as yet, bearing in mind we'd like a solution that works with existing hosts.  But see the new mdnsext BoF and mail list and push thoughts there...

> 18.  Updated references (one draft is now RFC, one individual draft
>      is now WG draft, noted those that are expired).

Noted.

> 19.  Question on "ISPs renumber due to privacy laws".  What's that
>      all about?

Germany, I believe.  Also note that some other big ISPs have stated they don't plan to give long-term static IPv6 prefixes to residential customers.

Many thanks,

Tim

> 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
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet