IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-17

There's been a good discussion that's come out of the AppsDir review:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html
...and I trust the authors to know what's appropriate to do as a result of that.

In his GenART review:
http://www.ietf.org/mail-archive/web/gen-art/current/msg08984.html
...Elwyn brings up a few minor points that are more than editorial, which I want to highlight:

Section 2.4 begins with a discussion of ULAs "within the scope of a single site," and the fifth paragraph in Section 3.4.2 arguably belongs in 2.4, probably early in the section, rather than down in 3.4.2.

The paragraph in Section 3.7.3 that discusses dotless domains probably needs a little work, at least to (1) be more fluffy about whether dotless domains are really upon us, and (2) say a word or two about what a dotless domain is, for readers who haven't been following the situation.

It's probably true that a reference for WPA2 would be good, but I've checked around and can't find something suitable.  There's some vague stuff on the WiFi Alliance pages:
http://www.wi-fi.org/knowledge-center/glossary/wpa2%E2%84%A2
...but otherwise, it's buried in the 802.11 specs.  It's probably not worth spending a lot of time looking for a good reference, but if one turns up that's fine.

And I'm sure the authors will address the editorial comments appropriately.

The new changes address my DISCUSS. Thanks

This one is a new comment, which you should really change (RC editor note would do it)

OLD:

   The specific protocols required to facilitate homenet management and
   monitoring are out of scope of this document. 

NEW:
   Specifying the required protocols to facilitate homenet management and
   monitoring is out of scope of this document. 



Below I left the comments that have not replied to/addressed AFAICT.
Up to your AD to follow up or not at this point in time.


- 

   [RFC6204] defines basic requirements for customer edge routers
   (CERs).  This document has recently been updated with the definition
   of requirements for specific transition tools on the CER in
   [I-D.ietf-v6ops-6204bis], specifically DS-Lite [RFC6333] and 6rd
   [RFC5969].  Such detailed specification of CER devices is considered
   out of scope of this architecture document, and we assume that any
   required update of the CER device specification as a result of
   adopting this architecture will be handled as separate and specific
   updates to these existing documents.  Further, the scope of this text
   is the internal homenet, and thus specific features on the WAN side
   of the CER are out of scope for this text.

I don't understand if, in this architecture you expect all CERs to be compliant with RFC 6204 or [I-D.ietf-v6ops-6204bis]? At least partly for the features on the homenet side?
You mentioned "Such detailed specification of CER devices is considered out of scope of this architecture document", but I don't understand what it means. Do you mean "irrelevant": "Such detailed specification of CER devices is considered irrelevant for this architecture document"?
But I guess that the some features, which are required by 6204/6204bis are required.
I read the above paragraph multiple times, and could not get it.


- Section 3.2.3 Dual-stack topologies

   That said, it is desirable that IPv6
   works better than IPv4 in as many scenarios as possible.

What does "works better" mean?

-
It seems that a big problem in home networks today is with WIFI, actually multiple WIFIs and combination of (powerline, wifi). I'm surprised to see so little about this aspects in the draft.

- I start to see home wifi routers that are forced by the service provider to offer free hot spots for other customers of this ISP (for example: http://www.voo.be/en/internet/wi-free/) Is this considered as a guest network in your draft? Any specific requirements in that area. Or maybe this is outside of the border of the homenet... 

- Below is some more feedback from Jouni Korhonen (JiK), part of this OPS-DIR review (I don't think I've seen a reply to this).

2.4.  Unique Local Addresses (ULAs)

   ...
   Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
   not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
                    ^^^^^^^^^^^^^^^^^^^^

JiK: Might be just me but what exactly is "host-based NAT"? I know what you
are after but is this term defined somewhere? I found at least two
interpretations for it.

3.2.2.  Network topology models

   ...
   For IPv6 homenets, the network models described in [RFC6204] and its
   successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
   be supported.
   ...

JiK: I would reword "successor RFC 6204-bis" to just "successor".

   ...
      used for one or more providers, or multiple CERs.  The presence of
      multiple CERs adds additional complexity for multihoming
      scenarios, and protocols like PCP that need to manage connection-
      oriented state mappings.
   ...

JiK: Reading the document so far it is unclear to me how PCP (and without expanding
the acronym, nor giving a reference to it) relates to the number of CERs.

3.2.2.2.  B: Two ISPs, Two CERs, Shared subnet

   ...
   example shows one shared subnet where IPv6 nodes would potentially be
   multihomed and receive multiple IPv6 global addresses, one per ISP.
   ...                             ^^^^^^^^^^^^^^^^^^^^^^

JiK: I take prefix is meant here, not address.

3.2.4.  Multihoming

   ...
   routed to the proper egress to avoid BCP 38 filtering if exiting
   ...

JiK: I would reword "BCP 38 filtering" to "BCP 38 ingress filtering".

JiK: The discussion of multihoming seems to neglect the case where the CER
would actually speak some routing protocol to its upstream provider. I take
that is done purposely but I cannot find any text saying why it has been
neglected. I understand it does not fit the existing model of consumer
subscriptions but in Section 2.6. it is said that "IPv6-only networking will
be deployed first in 'greenfield' homenet scenarios", which would at least to
me imply some more freedom on choices how to deploy a service.

3.3.4.  Homenet realms and borders

   ...
   e.g. for some specific Grid or LLN-based network, and for these to be
   ...                    ^^^^

JiK: a reference or explanation about Grid is missing in the I-D.

3.4.1.  Use of ISP-delegated IPv6 prefixes

   ...
   prefixes longer than /64 (which would break SLAAC), use of NPTv6, or
   ...             

JiK: SLAAC is never expanded.

   Thus a homenet CER should request, for example via DHCP-PD, that it
                                                      ^^^^^^^

JiK: First time occurrence.. not expanded nor reference given.


3.4.2.  Stable internal IP addresses

   ...
   filtering at the border(s) of the homenet, as mandated by RFC 6024
   requirement S-2.                                          ^^^^^^^^
   ...

JiK: Should be RFC 6204.

3.4.3.  Internal prefix delegation

JiK: It seems that DHCP PD is used with and without '-' in other polaces
in the document . Choose one style.

3.5.  Routing functionality

   ...
   Multiple interface PHYs must be accounted for in the homenet routed
   ...                ^^^^

Jik: PHY is used twice in the document. Never expanded or explained. Same
for MoCA..

3.5.  Routing functionality

   ...
   environment, but as a guideline a maximum convergence time at most 30
   seconds should be the target.
   ...

JiK: For my curiosity.. how did we end up to this 30 secs convergence time
again?

   networks.  IPv6 VM solutions may also add additional routing
                   ^^

JiK: Although explained in the terminology & abbreviations I would expand
VM on the first occurrence.

3.6.1.  Addressability vs reachability

   protocol such as UPnP or PCP [RFC6887].  In networks with multiple
                    ^^^^

JiK: No reference given to UPnP. (well in terminology and abbreviations yes
but would add one here too). Maybe expand UPnP on the first occurrence also.

3.6.5.  ULAs as a hint of connection origin

   As noted in Section 3.6, if appropriate filtering is in place on the
   CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address
                          ^^^^^^^^

JiK: Should be RFC 6204

3.7.1.  Discovering services

   ...
   Users will typically perform service discovery through GUI interfaces
   ...
   an appropriate API for the discovery to be performed.
   ...

JiK: Expand GUI and API on the first occurrences.

3.7.3.  Name spaces

   ...
   Unique Locally Qualified Domain Name
   ...

JiK: give the abbreviation as well (for the similar style as in the
rest of the document is using).

   ...
   Also, with the introduction of new 'dotless' top level domains, there
   ...

JiK: A reference to some document?

   ...
   available by name via an Internet name space, and that a 'split view'
   is preferred for certain devices.
   ...

JiK: A reference to a document that describes the 'split view' ?

3.7.4.  The homenet name service

   ...
   to support appropriate name service security methods, including
   DNSSEC.
   ...

JiK: Add a reference to DNSSEC.

3.7.5.  Independent operation

   ...
   Having an independent local trust anchor is desirable, to support
   secure exchanges should external connectivity be unavailable.
   ...

JiK: What is the local trust anchor? Reading so far it is not immediately
clear to me.

3.7.6.  Considerations for LLNs

   ...
   solutions for use by the Constrained Application Protocol (CoAP) in
   ...

JiK: Give a reference to CoAP?

3.7.7.  DNS resolver discovery

   ...
   local FQDN-derived zones should be included.
   ...

JiK: It is not clear to me what local FQDN-derived zones
are supposed to mean.

1.  I will channel some of my I* colleagues and say that section 2.2 should probably discuss privacy issues that may arise.

2. I think it would be useful if the discussion of ULAs in section 2.4 mentioned that the address selection policy in IPv6, by default, prefers using ULA source addresses when the destination is a ULA.

3. Section 2.5 uses the term "zeroconf" without any previous definition.

4. Section 3.4.4 makes no sense to me.  Other sections have a copious amount of detail and this one just says "timers have different lifetimes, figure it out".

was discuss

The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware of the discussion in the working group and the nuance of the respective arguments having been a contributor to the discussion.

I personally would rather see:

The document declare a lack of consensus with respect to which is more appropriate.

Describe the policy as situationaly appropriate (e.g. there are consensus cases where one model is appropriate or the other model is appropriate).

this is not strongly held but it's worth discussing.

A bunch of comments and a few questions follow. None of these rise to the level of requiring a DISCUSSion; t is, after all, just Informational. However, please take these into consideration, and I'd appreciate answers to the queries:

1.1: You define LLN here. But throughout the document, sometimes you use LLN to mean "home automation device network" (see 2.1 below), where the network might not necessarily be low-power or lossy, and sometimes you truly mean LLN. I suggest you look through the document and make sure you identify which are which. (For example, in 2.4, I don't think you're really talking about LLNs; you're talking about home automation networks.)

There's no need for a definition for UPnP here. It is only cited once (in 3.6.1), and even there it's simply an example. (I'm not at all clear why this document, even in 3.6.1, has to advertise for UPnP, a non-IETF technology. I'd rather the example simply be removed from 3.6.1 and stick to PCP.)

You refer to "guest" networks throughout the document, but don't define it here. I find the concept a bit odd myself; I know many corporations have a concept of a guest network, but it's rare for home networks to have such a thing. Can you explain why this is a useful construct in a home network? If it turns out to be, it's probably worth defining here.

2.1. Instead of "building control", please use the term "home automation" here. "Home automation" encompasses more than "building control" for homes, and "building control" includes things that are not part of home networking. By the way: It is a home automation (or building control) "network" or "subnet", not a home automation "extension", isn't it?

The use of the word "extension" here and elsewhere (as in "corporate extension" or "extension network") is nothing I've heard used before and it is undefined in this document. In the context of a corporate network, don't you simply mean a "corporate virtual (private?) network"? Or are you really talking about the possibility of corporations providing a dedicated network in a home premise that might be interconnected with the user's ISP and home automation networks?

2.4: I think you're simply talking about home automation devices here, not LLNs.

2.5: (Tilting at a windmill) Zeroconf and simple naming are really only useful for ULAs. To avoid the need for manual configuration of GUAs, the ability to configure DDNS (i.e., giving the user the ability to type in a domain name and have it update the AAAA record with the auto-configured address) must be provided. (See also 3.7.3 below.)

3.1.2: This section seems a little thin, and frankly I can't figure out what it really means: Certainly few home CERs nowadays allow you to plug them into other home CERs from different providers and have anything useful happen, so saying that changes to routers needs to be "minimized" seems unrealistic. Sure, you won't be making wholesale changes to IPv6, but this section seems to be saying something different. What do you mean by "minimized"?

3.2.2.1: What's the interest of Link F? The Interior Router looks like it's linked to the CER through Network E already. Does having F separate mean anything in particular?

You mention that B and E are "bridged". Is that any different than in figure 2, where the two CERs are bridged across a single network?

3.2.3:

   ...it is important not
   to introduce new IPv6 capabilities that would cause a failure if used
   alongside IPv4+NAT...

Are there examples of what you're thinking of here?

3.3:

   The home network architecture should be naturally self-organising and
   self-configuring under different circumstances relating to the
   connectivity status to the Internet, number of devices, and physical
   topology.  At the same time, it should be possible for advanced users
   to manually adjust (override) the current configuration.

The architecture is not "self-configuring" or configurable. I think you mean that homenet (routing?) *devices* need to be self-configuring and that advanced uses be able to override their configurations. If not, please explain.

3.4.1:

   ...it is recommended that the receiving router instead enters an error
   state and issues appropriate warnings.
   
That sure sounds like a recommendation designed to be ignored. You are either saying that manufacturers should make equipment that will fail to function in certain circumstances, or you're encouraging the creation of a "HOMENET certified" brand. Neither one seems like a good thing.

The last 5 paragraphs of this section strike me as a bit odd: The norm for homenets (from the earlier discussion) seems to be that it must handle users plugging together of devices from different providers and removal of those devices from the network. It seems like handling *that* gracefully will make all issues of renumbering/prefix changes/new ISP/etc. simply degenerate cases of the bigger issue of dealing with networks being plugged together and unplugged randomly.

3.5.2: This seems a bit hand-wavy. Perhaps that's the best that can be done in this document.

3.7.3: This section is a bit thin on how global name spaces will work. If homenets are going to have global name spaces, the authoritative server you mention in the first paragraph is going to almost certainly be a DDNS server, and changes are going to be needed on the hosts to support this. We certainly *do* want printers and other services to keep their names up to date with different GUAs coming and going. I think a discussion of this would be useful.

I support my fellow AD's discuss points.

0) abstract: Is it that network is getting geographically larger or that it's getting more populated or both?

  This text describes evolving networking technology within
  increasingly large residential home networks.

maybe in the abstract:

  This text describes evolving networking technology within
  residential home networks that are increasing in size and
  density of IP-enabled devices (e.g., toasters).

Always want to give a nod to Jari's toaster.  Did it ever get a name?

1) I support Brian's 1st point about this also being a requirements draft as well as an architecture.  Maybe that can't be helped, but I did think that some uses of the term requirement could just be totally dropped.  Further, s3 says:

 The aim of this text is to outline how to construct advanced IPv6-
 based home networks involving multiple routers and subnets using
 standard IPv6 addressing and protocols [RFC2460] [RFC4291]. 

But then you're not going to do that you're going to add requirements for new protocols - which fine in my mind I'd just like the words to match up.

2) s1: r/that we would like to avoid/that should be avoided

3) s1: Might also be good to say why you don't want these:

  Such networks also
  typically employ solutions that we would like to avoid, such as
  private [RFC1918] addressing with (cascaded) network address
  translation (NAT)[RFC3022], or they may require expert assistance to
  set up.
  
e.g., private addresses leak and then we ended up with AS112 ... etc.

4) s1.1: Would have added subnet in the list. Add informative reference for WPA2?

5) s2.1: should this be "to Ethernet" as opposed to "from Ethernet":

 Constraining the flow of certain traffic from Ethernet links to much
 lower capacity links thus becomes an important topic.
 
The idea being you'd want as much to run on ether as you could right to help with the poor constrained device bandwidth?

6) This might just be a wording thing so it might be easy to clear up:

s2.1 contains the following

  Likewise, there may be a need to separate building control or
  corporate extensions from the main Internet access network, or
  different subnets may in general be associated with parts of the
  homenet that have different routing and security policies.

The corp extensions part kind of threw me for a loop.  Are those the ISP's extensions, a home user's employer's extension when they're using a VPN, some sensor gone rogue in my house ... ?

6) s2.2: I think it does a pretty good job of distinguishing between reachability and addressability.  A back pointer to s3.6 would definitely help here because I originally thought out wait that's it but was later appeased somewhat.  I do think the last sentence in the first paragraph should be changed to include the words "and possibly malicious traffic" because it's not just like you're being bothered by the traffic it's some script kiddie (or worse) trying to hack in to your new smarttv to watch you watch tv.

7) s3: Does this sentence line up with the new requirements being introduced:

 The aim of this text is to outline how to construct advanced IPv6-
 based home networks involving multiple routers and subnets using
 standard IPv6 addressing and protocols [RFC2460] [RFC4291]. 

Shouldn't it say and point out where we think tweaks need to added.

8) s3.6:  I'd like to hear some more on the call about Joel's idea, but the mitigation discussed most is filter - firewalls are kind of glossed over.  Should there be some kind of recommendation about having a default firewall turned on?

9) s2.2/s.6: Firewalls vs Filtering.  I kind of tripped over this because it seems like in s3.6 a firewall is just a big filter, but in s2.2 it mentioned applications so I thought maybe an application layer firewall, but there's also stateful firewalls.  I assume you're not discussing application layer firewalls at all in this draft, but it might be good to explain the difference between plain filtering and stateful filtering in the terminology section.

This is one big chunk of good work - thanks to the working group for putting it together.

I have some comments, that I'd appreciate the authors looking at, along with any other comments they consider.

About half of my comments involve name services, and telling a TSV AD to get a clue about DNS might be a reasonable way to address those comments :-)

There are three places in the document where the word "cascaded" to describe NATs. I'm pretty sure I know what you mean, but I didn't see a definition or reference. Could one or both be provided?

In 3.3.4.  Homenet realms and borders

   It is expected that a realm would span at least an entire subnet, and
   thus the borders lie at routers which receive delegated prefixes
   within the homenet.  It is also desirable, for a richer security
                        ^^^^^^^^^^^^^^^^^^^^
   model, that hosts are able to make communication decisions based on
          ^^^^^^^^^^^^^^
   available realm and associated prefix information in the same way
   that routers at realm borders can.

and in 3.6.4.  Device capabilities

   In terms of the devices, homenet hosts should implement their own
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   security policies in accordance to their computing capabilities.
   They should have the means to request transparent communications to
   be able to be initiated to them through security filters in the
   homenet, either for all ports or for specific services.  Users should
   have simple methods to associate devices to services that they wish
   to operate transparently through (CER) borders.

I wonder if the places where you have expectations about hosts could be gathered into a single higher-level section ("considerations for hosts in homenets", or something). In the current version of the draft, they're buried in descriptions about homenets, and I wonder whether the people who need to see them will actually see them. and you don't have very many of them. I wouldn't expect much text to change (the expectations are clearly stated). But even if that higher-level section just pointed to the sections where the material is now ("hosts should do whatever, as described in Section 3.6.4"), I'd expect more people who can influence host implementations to notice.

In 3.7.2.  Assigning names to devices

   Given the large number of devices that may be networked in the
   future, devices should have a means to generate their own unique
   names within a homenet, and to detect clashes should they arise, e.g.
   where a second device of the same type/vendor as an existing device
   with the same default name is deployed, or where two running network
   elements with such devices are suddenly joined.  It is expected that
                                  ^^^^^^^^^^^^^^^
   a device should have a fixed name while within the scope of the
   homenet.

I find myself wondering if anything else might need to take action where two running network elements are suddenly joined - this is the only place in the document where I saw the word "join", although I could easily have missed other mentions using different wording.

In 3.7.3.  Name spaces

   Also, with the introduction of new 'dotless' top level domains, there
   is also potential for ambiguity between, for example, a local host
   called 'computer' and (if it is registered) a .computer gTLD.  Thus
   qualified names should always be used, whether these are exposed to
   the user or not.

Is there a useful reference that could be provided for "dotless"? If there's not a better one, perhaps http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/?

Also in 3.7.3.  Name spaces

   It may be the case that not all devices in the homenet are made
   available by name via an Internet name space, and that a 'split view'
   is preferred for certain devices.

Is there a useful reference that could be provided for "split view" ("split horizon")? I didn't see one during a quick poking-around, but if there's not, perhaps a short definition would be helpful?

In 3.7.4.  The homenet name service

   To protect against attacks such as cache poisoning, it is desirable
   to support appropriate name service security methods, including
   DNSSEC.

Two things here. I'm curious about a useful reference for "cache poisoning", but even more - you were allowing for the preference of "split view" in 3.7.3, and in 3.7.4, you're saying support for DNSSEC is desirable. How well does that work? http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04#section-4.1 (expired) described several ways to do "split view DNSSEC", but each had disadvantages. Is there a requirement for work on DNS in support of what you think homenets will need?

And if you can come up with a reference that's not expired, that would be great ...

Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the long term interests of the Internet would be best served by the removal of the routing text from this draft and the definition of the routing components in a working group that will get better scrutiny by routing specialists, i.e. adopting of the routing protocol requirements and definition by a WG within the router area.

"A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP38 ingress filtering problems."

The reason for this requirement could be given greater clarity in the text.