2.3.9 Networks in the Small - aka Home Networks (nits) bof

Current Meeting Report

Minutes for NITS BOF
45th IETF, Oslo, Norway, 12-16th July 1999
Date: Tuesday, 13th July

Stuart Cheshire Cheshire@apple.com
Eric Guttman Erik.Guttman@sun.com

Thanks to John Richardson for recording these minutes.

Mailing List Information:
Discussion: nits@merit.edu
E-Mail-Archive: http://www.merit.edu/mail.archives/html/nits/
(un)subscribe requests to: nits-request@merit.edu


Why are we here? - Stuart Cheshire & Eric Guttman - 30 min
Home Network Considerations - Myron Hattig - 10 min
Charter Discussion - 30 min


The focus of this BOF is to discuss chartering a working group. The technical issues were covered at the BOF in Minneapolis.

Why are we here? - Cheshire / Guttman

Focus is on making IP easy to use in small networks. AppleTalk, IPX and NetBEUI already do this, how can we make IP "plug and ping"? How can we make hosts operate where we don't have manual configuration and administered solutions (like DHCP servers) are not available?

The goal today is to charter a working group. The scope of discussion is not to define new protocols. Instead, it's to identify the requirements, identify the protocols that meet the need, and to identify the gaps that (may) exist. If any new protocol work is needed, we will identify the appropriate place to get that work done, re-chartering our WG if appropriate.

What is needed for a small network? Automatic address configuration, name-to-address resolution, and service discovery. While DHCP can do this, it requires a configured server, which may not be available in the small network environment. While there has been progress in adding these capabilities to IPv4, these are still just internet drafts and have no formal standing.

What is small? No administrator, no infrastructure support. A small network needs a zero-administration / administrator environment - no manual configuration, no DHCP server, no DNS server. Limited network scope - not too many users or hosts.

Peaceful coexistence is required - devices must work in both "small" and "large" networks. The NITS protocols must transition graceful into comparable protocols for an administered network.

There are some issues: including renumbering or renaming as the entire small network gets connected to a larger network, deciding on target platforms (small devices, non-configurable devices, computers, ...), and figuring out how to provide security in a zero-admin environment (physical security, disconnection, use existing security mechanisms? What about VPNs, firewalls, Socks?)

Note that the NITS profile will specify both IPv4 and IPv6 solutions.

NITS clients must do no harm in a large network, and must detect when they are in a large network and modify their behavior accordingly.

There exists a draft <draft-guttman-nits-reqts-00.txt>.

Terminology: smaller network is autonomous and limited in scale. In a larger network, the hosts are configured and an infrastructure exists.

In the NITS scenario, you plug it in and it just works. The essential services operate whether you are connected to a large network or not.

Host configuration: no static configuration or no DHCP implies address auto-configuration. See: draft-ietf-dhc-autoconfig-04.txt and draft-ietf-dhc-IPv4-autoconfig-04 and RFC2462 - IP6 stateless address configuration.

Name resolution: must be available in the absence of DNS server. Some form of multicast request/unicast reply is needed. Perhaps draft-manning-multicast-dns-01.txt or Dan Harrington's "Link Names" proposal will get us there. When a DNS server is available, it must be used instead of multicast.

Service discovery: issue: by type or by query? What constitutes discovery - location or more information like configuration data? You might be able to have service advertise availability. Clearly there's debate in this arena. For example: SLP [RFC 2609], multicast DNS + SRV RR [draft-ietf-dnsind-rfc2052bis-02.txt; rfc 2052, draft-manning-mulitcast-dns-01.txt]; SSDP [draft-cai-ssdp-v1-02.txt], or we could Punt (constrain the charter of the group to not address service discovery).

Home Networks Requirements - Myron Hattig

Presentation goals: provide perspective, show key scenarios, and discuss need for multiple subnets in the home.

The goal of home network is to connect a home network to a corporate network, the Internet, or to other homes. (There was some pushback on whether all of these scenarios are in the scope).

Scenarios: Intra-home networking, Internet access sharing, corporate telecommuting, inter-home network, services from the home.

Comments on security - open.

Suggestion to change the name of the group - maybe home networking?

Multicast Discovery of DNS Services - Bill Manning

How do you find things? Suggested is that DNS queries are multicast and answers are unicast. Once a host found a server, it should use unicast to talk to it. This is experimental, some code written, lots of assumptions to be tried. This is not zero configuration. See draft-manning-multicast-dns-01.txt for more information.

Charter Discussion

A straw poll on whether the group should include name-to-address-resolution seemed to show general consensus in agreement.

Michael Thomas: How many of the problems we are solving are based on "partially on" networking? Do we need this work as the world is transitioning to 24x7 networks?

Alan Oneill: Home networking has been around for a while. Finding and fixing the missing tools in the IP protocol suite should be the key focus of this group.

Straw poll: If this work was limited to one media, no bridging routing etc. who would still be interested? [not as many as previous poll, but lots - guess at 20%].

<general discussion>: Just because you have always on access to the internet doesn't mean that you'll want it to be the only solution - why would you want all of your devices in the home to be globally reachable. We could decide that zero-configuration says you can't reach all devices by default and if you want to enable access, then you can ask the user to configure.

Abel Weinrib: There seems to be general agreement to talk about zero-administration networking. Lots of requirements are in people's heads. The first work assignment is to figure out what would be useful to solve. Scenarios may help identify what people think is important.

Erik: Suppose we charter a WG that defines what zero-configuration networking is. We've advanced some areas that are difficult. We can rule out issues that may not scale or other attributes in the large.


[I most likely got every single name wrong ;-) Humblest apologies. -JR]

Michael Thomas: are we presuming that there's no residential broadband?
Answer: We consider a large service like a broadband connection to be an administered network.

<missed the name>: Network with only transient connectivity is not quite right - a network in the home that doesn't require administration, and can support broadband connectivity.

Keith Moore: Plugging devices into the small network and having them connect to the larger Internet is out of the scope? Erik: we separate out disconnected networks and the transition to connected networks. Keith: How can we tell disconnected networks from connected networks with connectivity problems? Erik: This is all about setting up disconnected networks. If we can also solve the problem of connecting to the larger network this would be cool.

Rupert Heiden: There will be hybrids - ISP provides address, but doesn't configure the printer.

Bob Frankston: Concerned we are trying to solve different problems. One is about IP connectivity. The second is application services - DNS, service location, etc. We should consider separating into two groups to solve the problems separately.

Vijay Guratani: Might be a problem with keyboards plugged into an IP network. Erik: that wasn't the point of the example.

James Kempf: Will multicast play a large role here? Multicast addressing schemes from (Madcap and mzap) are pretty complex and unlikely to be easily implemented in an embedded device.

Yaron Goland: What happens when you bridge two networks? Stuart: Many technology combinations don't allow bridging. Bridging between 802.11 (11Mb/s wireless) and HomePNA (16Mb/s phone-line carrier) is feasible, whereas Ethernet and Firewire are sufficiently different that bridging makes less sense. In those situations we may need routers. Once you have a piece of hardware routing packets between Ethernet and Firewire, it is less of an imposition to say that this piece of hardware should also offer DHCP service, to tell the devices on those networks how to configure. However, it's not the WG charter to solve the problem where a house may have multiple network technologies and multiple routers cascaded around the house. Large complicated networks can be managed today using DHCP servers. The environment that is currently served very poorly by IP is the small simple network which has no DHCP server.

Bob Frankston: The consumer space is where you see the messiest networks. Lots of houses have ancient messy disorganized Victorian telephone wiring. You can't just exclude things because they are messy. Stuart: physically disorganized telephone wiring does not equate to a complicated network topology. HomePNA provides a single broadcast domain regardless of how messy the physical topology is.

David Allen: I thought the theme of this was the more interesting case of providing services to devices in the home, including Internet access.

Thomas Narten: You always want your local domain to work. Sometimes you're part of the Intenet, too, at the same time - it should all just work.

Bill Brandt? : The only way to make progress is to focus. The drafts as done today does include the "edge" issues.

Keith Moore: Whatever we do must be useful to people who connect at home, and in hotels, at work, etc. Do we form a working group that doesn't include the Internet? We must be careful about how we scope this problem. Erik: It would be really nice if we had a solution to the plug and play problem - but that's the "over the horizon" goal.

Bill Woodcock: The goal of this working group is not to be meeting for the next ten years.

Stuart Cheshire: NITS protocols do not preclude also being connected to the greater Internet at the same time. An iMac user today might be connected to the Internet via modem, and print to a local laser printer using AppleTalk over Ethernet. It would be better if they were printing using IP over Ethernet instead of AppleTalk, and this could be achieved be having a link-local NITS IP address on their Ethernet interface while still keeping their globally addressable IP address on their PPP interface. A cable modem or DSL customer could run with a globally addressable IP address AND a link-local IP address at the same time on a single Ethernet interface.

Keith Moore: In IPv6 a host can have multiple IP addresses. Why is this different? Stuart: It's not. IPv6 already provides a lot of NITS-friendly features.

Yaron Goland: Demand IPv6 from your vendors. [Applause]

<missed the name>: Note if you use IP to connect to your modem and it connects to the Internet, here's an example of why you'd need both scopes.

Erik Nordmark: Always-disconnected networks are not the scope of IETF. Interesting problems come from dealing with cases of intermittent connectivity.

Abel Weinrib: The driving application is consumer networking either occasional or always on always connected networking. This should be focused on usable consumer networking.

<missed the name>: The IETF exists to work on the "Big I" Internet [i.e. a single AOL-like world-wide service which consumers "dial-in" to], not to develop protocols that might be useful on any kind of network.

<general discussions>: about the scenarios included the main question of gateway addressing problems (like NAT).

<missed the name>: This working group should not be called NITS. It should be called "Home Networks" and should address all the problems of a consumer building a large complicated network with lots of hardware like gateways, routers, and bridges, and connecting it all to the (Big I) Internet.

Yaron Goland: I support changing the name and the charter of the working group from "NITS" to "Home Networking".

<missed the name>: Solving all the problems of large compliated home networks is a in interesting challenge, but that would be a different working group, with a different name, and a different charter. I don't think the chairs of this working group have volunteered to take on that challenge.

<missed the name>: I raised my hand in support of zero-admin, not for "home networking".

Abel Weinrib. Zero administration is an interesting problem to solve.

Dave <?>. We should consider adding safe coexistence with larger (administered) networks to the charter.

M. Khalandovsky: What do you mean by the requirement (on internet access sharing scenario) by forwarding requests. Who will make the decision regarding forwarding of requests?

Yaron: Please include small business, too - they have the same issues.

Alan M: Note that we have revived the Link Names draft from IPv6 and have an implementation.

Mike Thomas: Default should be that devices in the house are NOT globally reachable. The user should have to make the decision to make a device globally reachable.

Final Discussion

At the end of the questions, Erik displayed the current charter draft on the overhead projector for discussion:

This WG will study the requirements for zero-admin networks. These networks can include (but are not limited to) environments where neither DHCP servers nor DNS servers are present. The WG will also survey existing IETF protocols that address the problem of autoconfiguration, with the aim of understanding whether existing IP protocols are adequate to solve the needs for autoconfiguration in the NITS environment, or whether additional protocols are needed.

This working group will address the requirements for following functions:

Other functions which are not of fundamental importance to host and application configuration are outside the scope of the working group.

This WG will produce two informational documents. The first describes the requirements for the configuration information and services a node needs in order to fully participate on NITS networks and/or the Internet at large. The second details a 'profile' specifying which protocols specifically satisfy the requirements outlined in the first document. If it is determined that no existing standard protocol fulfils the requirements, the profile may specify that a new protocol is required or recommend a change to an existing standard to apply to the NITS environment.

Erik asked for a show of hands in support of forming a working group with the charter of investigating "zero configuration networking", as displayed on the overhead projector. Roughly forty people raised their hands.

Erik asked for a show of hands for those opposed to forming a working group with this charter. Two people raised their hands.

Next steps

Send the draft charter to the list and say does it look reasonable. Send it to the AD / IESG and see if it's OK. Open up discussion on the list for 2-3 weeks where we can see what problems we might add to the charter, like VPNs, etc.

Another straw poll, taken after the draft charter was shown, indicates that we have rough consensus on what we've written.

Somebody suggested adding "connecting zero-admin networks to separately administered networks". Erik's answer was that we'd try to add it if it doesn't break the other requirements.

Somebody suggested we ensure the charter reflects that the requirements are coming from consumer networking - that will help as we clarify the scope and check for sufficiency.


Inter-Home Networking