+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 protected]>
Date:
Mon, 03 Oct 2011 21:35:54 -0700
To:
Tim Chown <[email protected]>
CC:
[email protected]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<[email protected]>
<[email protected]>
<EMEW3|507144591d242f9fb36239f554f547a1n8KDRS03tjc|ecs.soton.ac.uk|[email protected]>
In-Reply-To:
<EMEW3|507144591d242f9fb36239f554f547a1n8KDRS03tjc|ecs.soton.ac.uk|[email protected]>
Message-ID:
<[email protected]>
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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
