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 protected] http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
