I have reviewed this document. Generally I like it.
I have a lot of detailed comments.
p4
> The assumption of this document is that the homenet is "not actively
managed".
I think this is a very challenging assumption. I think it is perfectly
reasonable to require some basic level of low-tech management (to be
defined). I think this assumption effectively as written says that a
Homenet needs to be "self organising" which to me is a step far beyond
what happens today. Even in today's Homenet of cascaded IPv4 devices
with NAT, an end user still has to physically plug the boxes together in
a fixed hierarchy in order for it to work. I see no reason why a future
IPv6 Homenet could not require some topology restrictions (some time ago
I proposed multi-rooted tree topology to mirror current IPv4 practice
with 1 root per ISP).
> Discussion in the homenet WG has led to a suggestion that there
should be a baseline homenet "version 1" architecture, based on
protocols and implementations that are as far as possible proven and
robust. A future architecture may incorporate more advanced elements.
Feedback is sought on what if anything do we want to say about potential
homenet versions here.
Support. IMHVO the likely major challenge is going to be how to handle
multihoming.
IMHO V1 should therefore concentrate on a single ISP model with multiple
devices. [model A-C]
V2 should concentrate on a multiple, competing, ISP model. [model D-F]
Section 2.3 p6 talks about external and internal communication.
May be useful to define "internal" and "external" in 1.1 as traffic that
crosses the "border interface" for the hard of thinking like me.
p7. > It may be useful to classify the border of the home network as a
unique logical interface separating the home network from service
provider network/s.
I think defining a Homenet "border" at least in terms of management is
going to prove essential in the long term. There may be instances when
the ISP manages the Homenet, but there will also be instances where it
doesn't. The document already defines demarcs at various points. I think
formalizing these interfaces will be a major benefit to interoperability
and flexibility.
Section 2.4 p7 should mention RFC 6177 IPv6 Address Assignment to End Sites
Without sufficient addresses you can't have multiple subnets and still
use SLAAC.
Section 3.1 p10-15
Why are the topologies limited to 2 ISPs? I already have potentially >=
4 ISPs in my house.
Is there any benefit limiting the discussion specifically to 2 ISPs,
rather than "multiple" ISPs?
Section 3.4.6 p22
RT12 could be challenging, and is arguably a host function to select the
correct source address.
I miss some discussion of the unique challenges of using wireless
connections with many existing IETF protocols, which have largely been
developed on wired networks and where all nodes enjoy mutual visibility
(unless your segment is too long).
Section 3.4.7
PD13 Flash Renumbering
Not sure why this is a requirement? We've said earlier that reachability
and addressing are orthogonal. What harm would it do if some older
prefixes were to hang around on interfaces, but not be routed or
selected for new sessions? Wouldn't deprecation and eventual removal of
a default route tagged per ISP achieve the same effect? e.g. RFC4192
together with a new prefix policy table to prefer the new prefix for new
outbound sessions at some point during the transition? I think it's
perfectly reasonable to drop the odd long-lived session and require the
app to reestablish if necessary.
I miss some discussion on the transient nature of some connectivity,
perhaps requiring the topology to auto-update and flush information e.g.
a mobile phone as an ISP, or a tablet computer acting as a host entering
and leaving the home, perhaps even suggesting that the CER could also
act as the Mobile IPv6 Home Agent (RFC3775). I did see Shim6 (RFC5533)
Section 3.4.9 p26
Agreed. Now that end to end connectivity is being restored, there is
more potential scope for DNSSec (RFC 4033 4034 4035) and DNS update
(RFC2136) in the home.
Section 3.4.10 p27
Generally, in my humble experience, most enterprises use DHCP to
discover any services from a centralized DHCP server reached via a DHCP
relay configured on each local switch interface, or via downloading a
centralized proxy pac file, or distributing a Domain policy (Windows
only). The natural extension of this to Homenet would be to run a DHCPv6
server on the CER, with one LAN interface per subnet running as a DHCPv6
Relay, but that still leaves the challenge of providing relay interface
ID's, and combining information from multiple ISPs.
I miss some discussion on the challenge of handling multiple
authoritative sources of configuration and management information. e.g.
conflicting routing tables / selection of competing ISPs, election of a
single CER to act as the Homenet DHCPv6 server, or how to communicate
with multiple DHCPv6 servers.
Section 3.4.11 p27
Not sure flash renumbering will work. See previous comments suggesting
RFC4192.
A natural consequence of removal of NAT, and opening up bi-directional
end to end connectivity, is that upstream providers have to communicate
with downstream users.
Section 3.5 p28
I don't think a summary is useful.
IMHO Two alternative topologies should also be considered and discussed
(even if they are rejected):
1. Use of RFC3931 L2TPv3 LNS - LNS to create flat emulated /64 subnets
extended from each CER to all hosts in the Homenet over an underlying L3
routed infra based on ULA, with the tunnel endpoints terminating in the
Homenet routers. The end devices could then connect to multiple subnets
either with a dedicated 802.1Q interface per provider, or to a single
subnet via the default L2 LAN. This could have the advantage of avoiding
modifying existing protocols that are limited to a single L2 segment,
and hide the internal complexity of the Homenet from hosts.
2. Use of one or other standard p2p tunneling protocol (or mobile IPv6)
so that each end node (or a router acting as a proxy for the end node)
builds an overlay network to one or more CER's for external traffic.
regards,
RayH
Ray Bellis wrote:
On 30 Jan 2012, at 16:38,<[email protected]>
<[email protected]> wrote:
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.
We'd like to urge all WG participants to review this draft and provide feedback.
This is our major chartered work item and forms the basis for all future work
in the group.
thanks,
Ray and Mark
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
