Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

[Tim Chown <[e-mail]>]

Hi,

Some comments in line.

On 15 Sep 2013, at 01:06, S Moonesamy <[e-mail]> wrote:

> I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> Document: draft-ietf-homenet-arch-10
> Title: Home Networking Architecture for IPv6
> Reviewer: S. Moonesamy
> Review Date: September 14, 2013
> IETF Last Call Date: August 8, 2013
> IESG Evaluation: September 26, 2013
> 
> Summary: This draft is not ready for publication as an Informational RFC.
> 
> The document defines a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements.  It draws parallels with IPv4 scenarios to explain the proposed architecture to the reader.  There is an assumption that the IPv6 home network runs as an IPv6-only or dual-stack network.
> 
> I am not sure whether application developers will be able to understand the document as it is written from a routing perspective.  I found the document confusing.  After reading the document I am left with a sense that it tried to solve the problems the working group participants could think about instead of taking an architectural view of IPv6 home networking.

The document was produced with five general areas in mind, which was the brief agreed by the chairs after the original interim meeting in Philiadelphia. Those are routing, prefix configuration, name resolution, service discovery, and network security.  There is thus no specific consideration of applications.  That said, such guidance would be very useful, and it would be quite feasible to draft a separate application-oriented/perspective text, including expertise from apps area - would that address your concern?

> Major issues:
> 
> I am listing these issues as major mainly for the attention of the Applications Area Directors.
> 
> According to RFC 1958:
> 
>  "4.2 A single naming structure should be used."
> 
> This document introduces a "Locally Qualified Domain Name" in Section 1.1.  Section 3.7.3 refers to it as a "Unique Locally Qualified Domain Name".  There is also a mention of "Ambiguous Local Qualified Domain Name space" in that section.

There is already a split namespace for existing home networks. Devices may live under .local (for mDNS/DNS-SD), which has meaning on the subnet in question (though some emerging vendor products are proxying this through routers - hence the desire to form a dnssdext WG to look at that topic), and/or may use a globally unique name space.

The issue in future home networks is how naming and SD works across a routed, multi-link home. What is the equivalent "local" name space, that can be used whether the home is externally connected or not, providing independent operation where necessary.

That section discusses how that "local" name space might look, and is the result of considerable discussion in the homenet WG.

Do you have something specific to propose to say instead?

> The document mentions ".sitelocal (or an appropriate name reserved for the purpose)".  Quoting RFC 6761:
> 
>  "Are writers of application software expected to make their
>   software recognize these names as special and treat them
>   differently?  In what way?"

It's interesting that the dnssdext BoF pushed back on tackling name space issues, and focusing on service discovery, should that WG be formed. But there has been plenty of discussion in the BoF(s) and (old name) mdnsext list about the issues. For example how names used in "local" service discovery protocols might be published in a global DNS name space.  One of the three proposed deliverables of dnssdext would be to identify and document those issues as the SD work progresses.  Input from application developers would be welcome.

> In Section 3.7.7:
> 
>  "Similarly the search domains for local FQDN-derived zones should
>  be included."
> 
> Why is the document recommending search domains?

The point here is that hosts in a self-configuring routed home network need to learn the DNS resolvers to use. How for example the leaf router determines which DNS resolvers to put into RAs. There has been discussion on homenet and elsewhere about how that could be done, whether it might (for example) be passed in the routing protocol (e.g. OSPF could support it) or whether a separate protocol is required.  The search domain sentence is an example of other configuration information. It could be omited if prefered.

> Minor issues:
> 
> In Section 2.6:
> 
>  "It is likely that IPv6-only networking will be deployed first in
>   'greenfield' homenet scenarios, or perhaps as one element of an
>   otherwise dual-stack network."
> 
> Given that this is an architectural document intended for a wide audience it would be clearer to the non-English reader to have a description instead of "greenfield".

OK.

> In Section 3.2.3:
> 
>  "A general recommendation is to follow the same topology for IPv6 as
>   is used for IPv4, but not to use NAT."
> 
> As a non-actionable comment, there are benefits to such an approach, i.e. IPv6 is like IPv4.  The drawback is that it may encourage an IPv4 mindset.

This was a general principle agreed early on in the WG, and appears to have wide consensus. The sentence is in the context of a dual-stack homenet.

> "In some cases IPv4 home networks may feature cascaded NATs.  End
>  users are frequently unaware that they have created such networks
>  as 'home routers' and 'home switches' are frequently confused."
> 
> I don't see the relevance of the second sentence in a document about architecture.  The document has a tendency to get into IPv4 NAT details (first sentence).  That is odd for a document about IPv6 home networking.

The second sentence stems from the 'support arbitrary topologies' principle. Do you have alternative text, or would you prefer it was omited? I think we'd need to have words there to suggest that the homenet user is most likely unaware of the creation of internal NAT, be that from introducing an IPv4 internal router, or by running a VM or something similar.  So long as it "just works".

> In Section 3.4.1:
> 
>  'One particular situation that must be avoided is having an end site
>   feel compelled to use IPv6-to-IPv6 Network Address Translation or
>   other burdensome address conservation techniques because it could not
>   get sufficient address space."'
> 
> The document references RFC 6177 for address assignments to end sites.  It then goes into the details of IPv6 prefix length and highlights that NPTv6 must be avoided.

There is very strong consensus in homenet against introducing NPTv6. Whether that affects what ISPs do is of course another question.

>  "There are many problems that would arise from a homenet not being
>   offered a sufficient prefix size for its needs."
> 
> The above argues that not having an acceptable prefix side for the homenet can be a problem.  It would be easier to start with an assumption that the IPv6 homenet will have sufficient address space.

Certainly.  The above text stems from some ISPs already only offering a /64. Currently some offer /48, while many offer a /56. But it's too early still to make any firm comment on common practices.

>  "For a typical IPv6 homenet, it is not recommended that an ISP offer
>   less than a /60 prefix, and it is highly preferable that the ISP
>   offers at least a /56."
> 
> From RFC 6177:
> 
>  "RFC 3177 [RFC3177] called for a default end site IPv6 assignment
>   size of /48.  Subsequently, the Regional Internet Registries (RIRs)
>   developed and adopted IPv6 address assignment and allocation policies
>   consistent with the recommendations of RFC 3177"
> 
> What follows after that is a mention of policies no longer consistent with RFC 3177.  This document seems to be taking the same approach as RFC 3177 which has to be updated because of policy issues.

Well, RFC 3177 is now considered obsolete.  There is strong consensus in the homenet WG that the text from RFC 6177 is appropriate, and I have spoken to a number of ISPs about it, who seem to agree. So emphasising what RFC 6177 says today seems a reasonable approach.

Of course, some countries may introduce laws or regulations that make RFC 6177 hard to follow.  But that shouldn't affect our document on architectural principles, should it?

>  "There may be cases where local law means some ISPs are required to
>   change IPv6 prefixes (current IPv4 addresses) for privacy reasons for
>   their customers."

My understanding is that this was added as a result of German law. 

> In Section 3.6:
> 
>  "The most notable difference to the IPv4 operational model is the
>   removal of NAT"
> 
> The following is under a "Security" heading.  I assumed that the stance of the IETF was that NAT does not provide security.

It provides some security. Is there specific text in 3.6 or one of its subsections that's problematic for you?

> In Section 3.7.3:
> 
> "Such name spaces may be acquired by the user or provided/generated
>  by their ISP or an alternative cloud-based service."
> 
> What is a cloud-based service and what name space does it provide?

That could instead say "third party service" - would that be better?

>  "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."
> 
> The IAB has issued a statement about "dotless domain considered as harmful" ( http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harmful/ ).  I don't understand why this document discusses about the introduction of dotless domains.

I don't understand why it would not mention the issue. The IAB statement post-dated the (brief) text in this draft. Would a reference to the IAB statement address your point?

> In Section 3.7.8:
> 
>  "It is likely that some devices which have registered names within the
>   homenet Internet name space and that are mobile will attach to the
>   Internet at other locations and acquire an IP address at those
>   locations."
> 
> What is the homenet Internet name space?  There is an IAB technical comment about a unique DNS Root (RFC 2826).

The wording is clumsy here I agree. The point is that some devices in the homenet may be registered under the/a global name space associated with the homenet, but where mobile may acquire a different IP address to that registered to that name in their home network. Hence the next sentence and next paragraph. We can rewrite that text to be clearer.

> Nits:
> 
> I suggest fixing "This text" in the Abstract.

This document? Or…?

> This review does not include other editorial nits.
> 
> I am including the review from Dave Cridland for APPSDIR:
> 
> §1 para 5: Apparently home networks are what they are. I admit to being easily baffled, but I cannot understand how they might not be what they are. Perhaps:
> 
> "We assume that the IPv4 network architecture currently deployed in home networks can not be modified by new recommendations."

That's fine by me.

> In general, §1 uses a lot of the terms of art from §1.1, which I found quite hard to deal with - perhaps some of the paragraphs of §1 could be moved below §1.1, either as a §1.2 or something else.

Ah yes, we could do that.

> §1.1
> 
> "CER" I understand as "the router"; that is, it's the pre-existing DSL/Cable router that's in the majority of home networks now, right? The term used elsewhere in the document is "modern home router", which seems obvious enough, but isn't present in the definition.

Yes. Though I can only find one instance of "modern home router". But that can certainly be changed to CER.

> I've read through the rest of the document, it looks good to me (though some parts I've only skimmed).
> 
> §4 seems less of a conclusion and more of a summary; I'm not really sure what it's there for. What I was hoping to find here was a bullet point list of new work needed. Instead, potential new work items are scattered throughout the text, making them hard to locate and enumerate.

Yes, it could be improved. An AD I think asked if there should be a summary of recommendations/principles, perhaps as an appendix.  In an earlier version we had these enumerated in each section, but that was undone at the request of the chairs, because (I think) they felt it broke the flow of the text. Do you think an appendix summary (with pointers back to the sections they are taken from) is desirable as a form of "checklist" for readers?

Tim

> 
> Regards,
> S. Moonesamy
>