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

[S Moonesamy <[e-mail]>]

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.

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.

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?"

In Section 3.7.7:

   "Similarly the search domains for local FQDN-derived zones should
   be included."

Why is the document recommending search domains?

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

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.

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

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

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

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

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.

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?

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

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

Nits:

I suggest fixing "This text" in the Abstract.

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

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.

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

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.

Regards,
S. Moonesamy