Subject: Re: [homenet] draft-chown-homenet-arch-00.txt

From: Ray Hunter <[email-masked]>
Date: Tue, 04 Oct 2011 08:29:23 +0200

+1 on starting by replicating the IPv4 stacking approach in use today.

My 2c worth (as I can't attend the meeting)

If the starting point for Homenet architecture is multiple trees of 
stackable devices, I would then define a stackable device to consist of 
one or more of:

1) An ISP port
2) An end device port
3) A L2 VLAN port
4) A stack-in port (optional)
5) A stack-out port (optional)
6) A topology configuration function (either manual or automatic)
7) A packet forwarding function
8) A VLAN function
9) A router function
10) A firewall function
11) name resolution function
12) An address delegation server function
13) An address delegation client function
14) an ISP selection function

All of these functions can be implemented in existing code and hardware 
with IPv4 (e.g. openwrt). There's nothing really crazy or new here that 
people won't be doing already today with IPv4. In fact, the need for 
stackable devices has been written about on the IPv6 lists on several 
occasions.

Please note that the above are functional descriptions, not hard 
allocations. The ports may well be the same Ethernets soft switched 
based on the location of the device in the tree, and their individual 
functions assigned using the topology configuration function. In the 
case of a VM running on an end host, that would implement the stack-in 
port function on the interface connected to a homenet router, and deploy 
other functions such as VLAN's and routing internally within the VM kernel.

Looking at each item in turn:

1. An ISP port would adapt to the physical media of the uplink 
(Ethernet, DSL etc.), would provide any login credentials (PPP etc.) 
negotiate link addresses (address delegation client function = DHCPv4 
client). It would also have a stateful packet firewall function (on by 
default). Existence of a working ISP port implies that this is a "root" 
device of the Homenet tree. How do you know if this interface is an ISP 
port? Manual configuration, interface type, PD learns a prefix via this 
interface.

2. An end device port would be a flat L2 LAN port. I think these are 
well understood. Although the endless debate of SLAAC or DHCPv6 or 
something else will probably remain just that. Given the massive 
deployment of DHCPv4 in home networks, I'm tempted to say DHCPv6 should 
be preferred, without any intention of restarting a war.

3. An L2 VLAN port would be any standard switch port, either internal or 
external.

4. The stack-in port connects to upstream Homenet devices.

The stack-in port in IPv4 does not have to be any different from an ISP 
port in an IPv4 implementation. It acts as a DHCPv4 client and can spoof 
the remote end into thinking it's simply an end host by applying 
outbound NATv4 (also for address conservation). Obviously I think we'd 
prefer to avoid NAT66 by default. Equally there's no fundamental reason 
why the stack-in function should have the firewall function enabled by 
default. So in an IPv6 implementation it would have the firewall 
disabled by default, and would receive delegated prefixes (see prefix 
delegation below)

5. The stack out port connects to downstream Homenet devices.

The stack-out port in IPv4 does not have to be any different from an end 
device port in an IPv4 implementation. It acts as a DHCPv4 server to any 
attached devices. In IPv6 it would have to be able to cascade Prefix 
Delegation obtained from the root CPE router. (see prefix delegation below)

6. The topology configuration function would be new for IPv6. Although 
it exists implicitly in IPv4 Homenet's, the fact that stack-out ports 
are largely functionally identical to end device ports and stack-in 
ports are largely identical to ISP ports makes it largely redundant: 
thus the firewall function, DHCPv4 client and server, and NATv4 are 
almost always enabled by default in IPv4 implementations. This would not 
work for IPv6. I think the topology configuration function should be 
automatic given the plug and play requirement for configuration by 
non-expert end users.

7. Packet forwarding is a basic kernel function of the device. It may 
either route or switch, depending on the port type.

8. A VLAN function would be allowed to speak any standard VLAN protocol, 
and can either be internal to the box as a virtual interface or a 
physical interface for inter-switch connection.

9. The router function can speak standard IGP on any interface (as 
already being discussed). Default would be disabled on the ISP port.

10. I think the firewall function is well understood for both IPv4 and 
IPv6, even though it is not fully standardized within the IETF. I don't 
think Homenet needs to specify too much here expect that the firewall 
should be stateful.

11. Name Resolution
Here's where I start to run into problems.

In IPv4 implementations with NATv4, you've always got the option of 
split DNS.

There are a number of local name resolution specs which AFAIK assume 
flat LANs and are not generally routeable.
I'm not sure that there's a simple solution for Homenet to handle the 
combination of local names and potentially multiple ISPs. I could well 
be wrong.

12+13. Prefix Delegation Client and Server:
Whilst there's no requirement for address conservation yet in an IPv6 
implementation, there's a real danger of getting stuck because AFAIK 
Prefix Delegation is only defined between an ISP router and _the_ 
(singular) customer premises router. Also if an ISP only provides a 
single /64 to the root CPE router via PD, there are no standards for how 
or whether to subdivide this prefix further. Does Homenet then simply 
fail? Or should it implement true CIDR to provide >/64 prefixes to 
sub-devices in the tree?

14. ISP Selection function
The ISP selection function in IPv4 implementations can be a straight 
outbound ping to a remote device to check basic reachability, plus 
application of NATv4 to ensure that the return route is correct. Note 
that for Homenet I would bundle NATv4 in with the ISP selection 
function, not necessarily the ISP interface. There are many such basic 
load balancing implementations on the market already. Despite all of the 
various multi-homing initiatives, I have yet to see how an IPv6 ISP 
selection function would work.

So the main 3 challenges IMHO are:

1) A protocol suitable for topology detection and configuration.

2)  A protocol suitable for cascaded prefix delegation within the Homenet.

Unless all Homenet devices implement a routing protocol that can 
distribute the address of a DHCPv6 server so a DHCPv6 client can be made 
to contact a DHCPv6 server in the root CPE device, which distributes 
prefixes it has learned via PD from the ISP.

3) Any protocol that allows ISP selection and correct reverse routing to 
the end device (without resorting to NAT66, or dynamic routing to end 
devices, or DHCPv6 distributed address selection) Homenet is unlikely to 
solve this in detail, but it should/could be used as a signal to other 
WG's of the importance of multi-homing. A basic choice of whether ISP 
selection and multihoming is a homenet router function, or an end device 
function would already be a useful pointer IMHO.

I'm sure there's smarter people than me on the list that can fill these 
gaps, or exclude these requirements in V1.

best regards,
RayH
> Subject:
> Re: [homenet] draft-chown-homenet-arch-00.txt
> From:
> Erik Nordmark <[email-masked]>
> Date:
> Mon, 03 Oct 2011 21:35:54 -0700
>
> To:
> Tim Chown <[email-masked]>
> CC:
> [email-masked]
>
> Content-Transfer-Encoding:
> 7bit
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email-masked]> 
> <[email-masked]> 
> <EMEW3|507144591d242f9fb36239f554f547a1[email-masked]> 
>
> In-Reply-To:
> <EMEW3|507144591d242f9fb36239f554f547a1[email-masked]> 
>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset=ISO-8859-1; format=flowed
> Message:
> 7
>
>
> On 9/21/11 5:27 AM, Tim Chown wrote:
>> Hi,
>>
>> I have been working with Jari, Jason and Ole to produce a new version
>> of the homenet architecture draft. Mark, who produced the first
>> version with Jari, is now of course WG chair and has stepped down as
>> editor of the text. 
>
> One thing I've been looking for is a way to avoid boiling the ocean; I 
> think being able to assign stable IP address prefixes in an arbitrary 
> topology is a hard problem, yet I think there simple home topologies 
> that show up today with IPv4 NATs that we should be able to handle 
> with relative ease.
>
> Today's IPv4 consumer home routers have a designated uplink port 
> (labeled "Internet", "WAN", or something similar) and the behavior is 
> different on that port (where it runs a DHCPv4 client) and the other 
> ports (where it runs a DHCPv4 server). If we start with a simple 
> solution to target such devices for IPv6 home networks (without IPv6 
> NATs), then we can come up with hierarchical prefix delegation and 
> default routes towards the delegating routers; no need to ensure that 
> a single stable prefix is assigned to each link in an arbitrary 
> topology of routers.
>
> Then we can work on that harder problem as an extension of the simple 
> approach for the simple topologies.
>
>    Erik