Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E0AE3CF.2070504@piuha.net>
Date: Fri, 1 Jul 2011 18:24:18 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECEBBF3B-B240-48DF-8A6B-F0566322F18D@cisco.com>
References: <4E0AE3CF.2070504@piuha.net>
To: fun@ietf.org
Subject: [fun] Routing ?
Precedence: list

I'm sure this is a spectacularly clueless question but, .... could =
someone say a bit more about why we need a routing protocol. I get that =
there is a need for small number of subnets, but it seems like most the =
requirements I have seen could be deal with using a single router that =
could route between all the subnets. As I said, clueless questions but =
can someone fill me in a bit on the use cases for a routing protocol? Or =
why a new routing protocol might be needed. Thanks.=20



On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote:

> I wanted to provide an update of the situation with this working group =
proposal.
>=20
> HOMENET is a new working group proposal, a variation of the =
HOMEGATE/HOMENET theme that we discussed last year, but this time =
looking at it from a different angle. The old effort was mostly focused =
about what home gateways should do: forwarding, transport, and DNS =
proxying issues. The new effort is about home networks themselves, in =
particular what kind of network architecture and configuration is =
necessary to support IPv6-based home networks. We view IPv4-based home =
networks as "done" at this time (or perhaps as "cannot be changed =
anyway").
>=20
> I have been discussing this effort in the background for the last =
couple of month with Mark Townsley and others, and more publicly since =
early June. The proposal has been brought to the IESG, IAB and some =
directorates for discussion, and we've been going back and forth whether =
this is ready to become a working group or needs to be run as a BOF in =
Quebec City. The current plan is that the working group proposal goes to =
IETF-wide review this week, and if the feedback from the community, IAB, =
and the IESG is positive, we will create the working group just in time =
for the IETF. Otherwise, the slot reserved in the agenda for the meeting =
will be used to run the proposal as a BOF.
>=20
> In any case, I would like to solicit discussion on this topic, and =
perhaps some early drafts as well. Please comment on the charter at =
least.
>=20
> Note that the new proposal was called FUN at the time that we created =
the list. It has now been renamed back to HOMENET to be more =
descriptive. The list will be renamed soon as well (current subscribers =
will stay).
>=20
> This is the most recent version of the charter we should discuss:
>=20
> Home Networks (homenet)
> -----------------------------------
>=20
> Current Status: Proposed
> Last Edit: Wednesday, June 29th, 2011
>=20
> Chairs:
> TBD
>=20
> Internet Area Directors:
> Ralph Droms <rdroms.ietf@gmail.com>
> Jari Arkko <jari.arkko@piuha.net>
>=20
> Internet Area Advisor:
> Jari Arkko <jari.arkko@piuha.net>
>=20
> Routing Area Technical Advisor:
> TBD
>=20
> Security Area Technical Advisor:
> TBD
>=20
> Mailing Lists:
> General Discussion: fun@ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
> Archive: http://www.ietf.org/mail-archive/web/fun
>=20
> Description of Working Group:
>=20
> This working group focuses on the evolving networking technology
> within and among relatively small =93residential home=94 networks. For
> example, an obvious trend in home networking is the proliferation of
> networking technology in an increasingly broad range and number of
> devices. This evolution in scale and diversity sets some requirements
> on IETF protocols. Some of the relevant trends include:
>=20
> o Multiple segments: While less complex L3-toplogies involving as few
> subnets as possible are preferred in home networks for a variety of
> reasons including simpler management and service discovery, the
> introduction of more than one subnet into a home network is enough
> to add complexity that needs to be addressed, and multiple
> dedicated segments are necessary for some cases. For instance, a
> common feature in modern home routers in the ability to support
> both guest and private network segments. Also, link layer
> networking technology is poised to become more heterogeneous, as
> networks begin to employ both traditional Ethernet technology and
> link layers designed for low-powered sensor networks. Finally,
> similar needs for segmentation may occur in other cases, such as
> separating building control or corporate extensions from the
> Internet access network. Different segments may be associated with
> subnets that have different routing and security policies.
>=20
> o Service providers are deploying IPv6, and support for IPv6 is
> increasingly available in home gateway devices. While IPv6 resembles
> IPv4 in many ways, it changes address allocation principles and allows
> direct IP addressability and routing to devices in the home from the
> Internet. This is a promising area in IPv6 that has proved challenging
> in IPv4 with the proliferation of NAT.
>=20
> o End-to-end communication is both an opportunity and a concern as it
> enables new applications but also exposes nodes in the internal
> networks to receipt of unwanted traffic from the Internet. Firewalls
> that restrict incoming connections may be used to prevent exposure,
> however, this reduces the efficacy of end-to-end connectivity that
> IPv6 has the potential to restore.
>=20
> Home networks need to provide the tools to handle these situations in
> a manner accessible to all users of home networks. Manual
> configuration is rarely, if at all, possible. The purpose of this
> working group is to focus on this evolution, in particular as it
> addresses the introduction of IPv6, by developing an architecture
> addressing this full scope of requirements:
>=20
> o prefix configuration for routers
> o managing routing
> o name resolution
> o service discovery
> o network security
>=20
> The task of the group is to produce an architecture document that
> outlines how to construct home networks involving multiple routers and
> subnets. This document is expected to apply the IPv6 addressing
> architecture, prefix delegation, global and ULA addresses, source
> address selection rules and other existing components of the IPv6
> architecture. The architecture document should drive what protocols
> changes, if any, are necessary. Specific protocol work described below
> is expected to be within the scope of the working group one the
> architecture work is complete. However, the group is required to
> review its charter and milestones with the IESG and IETF community
> before submitting documents that make protocol changes. It is expected
> that the group has to discuss some of the below solutions, however, in
> order to complete the architecture work.
>=20
> The group will apply existing protocols to handle the five
> requirements above. For prefix configuration, existing protocols are
> likely sufficient, and at worst may need some small enhancements, such
> as new options. For automatic routing, it is expected that existing
> routing protocols can be used as is, however, a new mechanism may be
> needed in order to turn a selected protocol on by default. For name
> resolution and service discovery, extensions to existing
> multicast-based name resolution protocols are needed to enable them to
> work across subnets.
>=20
> For network security, the group shall document the concept of
> "advanced security" as a further development of "simple security" from
> RFC 6092. The main goal of this work is to enable a security policy
> that adapts to IPv6 threats as they emerge, taking into account not
> only traffic from the Internet at large, but within and leaving the
> home network itself.
>=20
> It is expected that the working group will define a set of protocol
> specifications to accomplish the five requirements from
> above. However, it is not in the scope of the working group to define
> entirely new routing protocols or address allocation protocols. As
> noted, additional options or other small extensions may be necessary
> to use the existing protocols in these new configuration tasks. The
> working group shall also not make any changes to IPv6 protocols or
> addressing architecture. Prefix configuration, routing, and security
> related work shall not cause any changes that are not backwards
> compatible to existing IPv6 hosts. There may be host visible changes
> in the work on naming and discovery protocols, however. In its design,
> the working group shall also consider security aspects and the impact
> on manageability. The main focus of the working group is home
> networks, but the group's results may also find applications in other
> small networks.
>=20
> The working group will liaise with the relevant IETF working
> groups. In particular, the group should work closely with the V6OPS
> working group, review any use or extension of DHCP with the DHC
> working group, and work with additional DNS requirements with the
> DNSEXT and DNSOP working groups. If it turns out that additional
> options are needed for a routing protocol, they will be developed in
> the appropriate Routing Area working group, with the HOMENET working
> group providing the architecture and requirements for such
> enhancements. The working group will also liase with external
> standards bodies where it is expected that there are normative
> dependencies between the specifications of the two bodies.
> It is expected that in the architecture definition stage liaising
> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>=20
> Milestones:
>=20
> Jul 2011 Formation of the working group
> Sep 2011 First WG draft on the architecture
> Dec 2011 Submission of the architecture draft to the IESG as =
Informational RFC
> Dec 2011 Charter re-evaluation based on the architecture work
> Dec 2011 First WG draft on prefix configuration
> Dec 2011 First WG draft on routing
> Jan 2012 First WG draft on name resolution
> Feb 2012 First WG draft on service discovery
> Feb 2012 First WG draft on perimeter security
> Feb 2012 Start of routing related work in the relevant routing area =
working group, if needed
> Mar 2012 Submission of the prefix configuration draft to the IESG as =
Standards Track RFC
> Apr 2012 Submission of the routing draft to the IESG as Informational =
RFC
> Sep 2012 Submission of the name resolution draft to the IESG as =
Standards Track RFC
> Nov 2012 Submission of the service discovery draft to the IESG as =
Standards Track RFC
> Dec 2012 Submission of the perimeter security draft to the IESG as =
Informational RFC
>=20
> _______________________________________________
> fun mailing list
> fun@ietf.org
> https://www.ietf.org/mailman/listinfo/fun