Subject: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt

From: [email-masked]
Date: Mon, 30 Jan 2012 08:38:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF.

	Title           : Home Networking Architecture for IPv6
	Author(s)       : Jari Arkko
                          Anders Brandt
                          Tim Chown
                          Jason Weil
                          Ole Troan
	Filename        : draft-ietf-homenet-arch-01.txt
	Pages           : 34
	Date            : 2012-01-30

   This text describes evolving networking technology within small
   "residential home" networks.  The goal of this memo is to define the
   architecture for IPv6-based home networking and the associated
   principles, considerations and requirements.  The text highlights the
   impact of IPv6 on home networking, illustrates topology scenarios,
   and shows how standard IPv6 mechanisms and addressing can be employed
   in home networking.  The architecture describes the need for specific
   protocol extensions for certain additional functionality.  It is
   assumed that the IPv6 home network is not actively managed, and runs
   as an IPv6-only or dual-stack network.  There are no recommendations
   in this text for the IPv4 part of the network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-homenet-arch-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-homenet-arch-01.txt

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jan 2012 15:08:25 -0500

Thanks for this update!
(to all: If you haven't tried the rfcdiff tool, I highly recommend it
    http://tools.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-01
)

I notice the additional text in the security area.
I am still uncomfortable about "Advanced security" being in scope, as
RFC6092 already exists, but does not spell out PCP vs uPNP at all.
(never mentioned in that document, uPNP mentioned in 4864).  If our
document simply specifies (one, or makes the security mechanism
discoverable), then I would be very very happy.

re, router is well known at 192.168.1.1, we could very well define (IANA
action) some ULA-C space from fec0::/7 as being always a router.
"fec0::1" (/128) maybe.   That could easily go into a DNS name that the router
vendor would provide.  

Scenario F has been added, which I think is rather reasonable.
Nobody so far has shouted that any of the scenarios are completely
unrealistic.   I feel that they are all relevant.

This paragraph is too inclusive (wishy-washy) if taken out of context of
the subsequent text:
   The general approach for IPv6 multihoming is for a hosts to receive
   multiple addresses from multiple providers, and to select the
   appropriate source address to communicate via a given provider.  An
   alternative is to deploy ULAs with a site and then use NPTv6
   [RFC6296], a prefix translation-based mechanism, at the edge.  This
   obviously comes at some architectural cost, which is why approaches
   such as [I-D.v6ops-multihoming-without-ipv6nat] have been suggested.
   There has been much work on multihoming in the IETF, without (yet)
   widespread deployment of proposed solutions.  Host-based methods such
   as Shim6 [RFC5533] have also been defined, but of course require
   support in the hosts.

I would like MH3 to use a stronger term than "desireable".

change:
  MH4)  Solutions that REQUIRE host changes should be avoided, but
        solutions which incrementally improve with host changes MAY
        be acceptable.

(I'm thinking shim6 here!)

change:
   MH7)  "Just" picking the right source address to use to fall foul of
         ingress filtering on upstream ISP connections (as per Network
         Model D) is not a trivial task.  A solution is highly
         desirable, but out of scope of homenet.

to:
   MH7)  Picking the wrong source address will run afoul of upstream ISP
         ingress filtering on upstream ISP connections (as per Network
         Model D). However, "just" picking the right source address
         is not a trivial task.  A solution is highly desirable, but
         out of scope of homenet.  Solutions SHOULD assume that "Happy
         Eyeballs" (reference?) solutions do exist on hosts, and that
         hosts/applications will try all combinations of destination
         addresses. 

(MH8 says more about this, and maybe some it is redundant)

I have read the rest of the document, and I had no further comments.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.