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

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Feb 2012 14:59:31 +0000

On 30 Jan 2012, at 16:38, <[email-masked]>
 <[email-masked]> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Feb 2012 08:52:41 +1300

Hi,

> 3.1. Network Models	
> 				
>  In this section we list six network models.

I have no complaint about those 6 models, but the reality is that
in an unmanaged homenet, the topology will be effectively random,
and solutions have to work whatever the user happens to do.

(Or alternatively, some sort of topology wizard would have to
tell the user to disconnect or move particular cables, but that
seems unreasonable.)

Therefore, these 6 models are useful but they can only be
illustrative. The requirement is that stuff works for any topology.
I think this needs to be said as an introduction to section 3.1,
and it prepares the way for sections 3.4.7 "Self-Organising" and
3.4.8 "Fewest Topology Assumptions".

> PD13) The delegation method should support "flash" renumbering.

and

>    When an ISP needs to restructure and in doing so renumber its
>    customer homenets, "flash" renumbering is likely to be imposed.  This
>    implies a need for the homenet to be able to handle a sudden
>    renumbering event which, unlike the process described in [RFC4192],
>    would be without a "flag day".

This needs more analysis. As the draft mentions, homenets are out of
scope for 6renum, and in any case the emphasis there is on planned
renumbering, which seems the only conceivable approach for enterprises.

I think we need to analyse in what way flash renumbering is different
from a cold start. More or less by definition, if we cold start a homenet
(as after a power cut), everything except ULAs will be renumbered, even
if they end up with the exact same addresses again. It's therefore
accurate to say that a cold start will cause flash renumbering but is
that sufficient to meet the requirement? If not, requirement PD13 seems
to be very demanding.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 10 Feb 2012 13:22:09 +0100

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-masked]>