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