Subject: Comments on IP host config requirents in draft#4

From: Cuneyt Akinlar <[email-masked]>
Date: Thu, 10 Aug 2000 09:38:01 -0400 (EDT)

In this posting, my intention is to try to contribute (or add more
confusion, however you look at it :-)) to the current discussion on
what is a zeroconf protocol and also pinpoint some of the deficiencies
in IP host config requirements as defined by draft#4.

Firstly, on the definition of a zeroconf protocol I agree with Myron
Hattig in the sense that I always thought a zeroconf protocol to be a
protocol that does not require manual configuration.  

I will extend this definition as follows: "A protocol is zero-config
if does not require manual configuration AND does not use an entity
that requires manual configuration". According to this definition, a
host using DHCP protocol for IP host config is zero-conf if the
DHCP-server is also autoconfig. That is, the DHCP server was not setup
by an administrator. If the DHCP-Server was setup by an admin (that is
it might have been burned down to the hardware by the vendor), the
host IP protocol is NOT zero-conf. My thinking process to arrive at
this definition is the following: I always though of something to be
zeroconfig if I buy that entity, power it up and boom it works without
requiring any manual setup. So, lets say I buy a router and a couple
of hosts. Hook them up, turn the power up. If this system can setup
itself, I call this a zeroconf system. In this scneraio, the router
might have a vendor burned in DHCP-Server and the hosts might be using
DHCP for IP host config but the whole thing did not require manual
setup. So, it is zeroconfig. Of course the hosts have to configure an
IP address in case no DHCP-Server is available. Some people suggested
that a zeroconfig protocol does not use a server. I don't see why you
cannot call a protocol zeroconfig if the server does not require
manual configuration?  So much for the definition of a zeroconfig
protocol.

I actually wanted to comment on IP host config requirements as defined
in draft#4. I think that some of the reqs. are too vague and some
terms have to be defined before being used.

In section 2.1.1, the draft talks about Ping and defines several
requirements which I quote below (I numbered some of the sentences for
further reference): 

" Specifically, the values for the IP address, netmask, and default
route within a host must be chosen such that the following statements
are true:

   (1)- All hosts on an IP subnet have a common netmask.
   (2)- When a host computes (HostIPAddr & netmask) the result is
     identical for all hosts on a single IP subnet.
   (3)- When a host computes (HostIPAddr & ~netmask) (inverse netmask)
     the result is unique for all hosts on an IP subnet.
   (4)- All hosts get a default route that is used for communication
     with other IP hosts off the local subnet.

   In addition IP subnets must somehow be unique on different IP
   subnets within an internet over which the zeroconf IP host
  configuration protocol is operating; this insures unique IP
   addresses (regardless of the value of the host portion of the IP
   address) across the entire internet.

   The zeroconf IP host configuration protocol only defines packets
   sent over a wire and the associated semantics. Here are zeroconf
   IP host configuration protocol requirements to satisfy ping:
   (5)- The ability to determine the netmask for an IP subnet.
   (6)- The ability to determine the default route for an IP subnet.
   (7)- The ability to have unique IP addresses within an IP subnet.
   (8)- The ability to have unique IP subnets within an internet.
"

Firstly, items (1)-(3) give the definition of an IP subnet which we
already know. (4) is similar. By definition, a default route is used
to communicate with hosts off the local subnet. As for (7), it does
not prevent IP address conflicts in a link-layer network (as I give an
example below). I belive (8) should not be the job of an IP host
config protocol and should be removed. Only (5) and (6) make sense in
these requirements as (5) requires a hosts to determine a netmask and
(6) requires a host to determine a default router if one is available.

Below I will try to give an example network that complies with all of
the requirements listed above but probably is not what we are talking
about.

+---+     +---+  
| A |     | B |  
+---+     +---+
  |         |
  +---------+
       ^ 	
       |     
   A Segment   

Consider the network shown above. This is a single segment network
with 2 hosts. A segment is a single link-layer network or several
link-layer networks bridged together. All hosts in a segment CAN
communicate only with MAC addresses.

Now assume that host A comes up, sets up:
IP address: 10.10.10.10.
Netmask:    255.255.0.0

Since host A is the only host at that point, everything is
fine. Notice that host A defines a logical IP network (an IP subnet)
over the segment. This IP network's subnet number is 10.10/16. It can
easily be seen that all of the requirements listed above are
satisfied.

Now host B comes up, and sets up the following parameters:
IP address: 10.10.10.10
netmask: 255.255.255.0

So, host B defines another IP network over the same segment whose
subnet number is 10.10.10/24. Again, all of the requirements listed
above are satifies as the requirements are defines in terms of IP
subnets and there are two IP subnets over the same segment. Each IP
subnet contains a single hosts though.

Obviously, there is an anamoly in the network as 2 hosts have the same
IP address but requirement (7) is still satisfied as the IP addresses
are unique within their own IP subnets. To make a long story short,
all requirements listed above and in section 2.1.4 are all satified by
this network configuration. Obviously, these two hosts cannot talk to
each other and the network is useless.

Of course the requirements listed in the draft are trying to say that
both hosts must use the same netmask, namely, be part of the same IP
subnet. Then other requirements follows. But they are not rigorous
enough. So I suggest to use the following definitions and
requirements:

Segment: A single link-layer network or a collection of link-layer
networks connected by bridges.

IP Network (IP subnet): A network that consists of hosts with
interfaces that share the same subnet number of their IP addresses.
That is, all hosts on an IP subnet get the same value when they
perform (IPAddrr&netmask) and different value when they perform
(IPAddrr&~netmask).

Given these 2 definitions, I suggest the following requirements:

1. All hosts connected to the same segment MUST aggree on a common
netmask. That is, there must be a single IP subnet defined over a
segment aggreed upon by all hosts.

2. All hosts connected to the same segment MUST have unique IP
addresses and hosts must enforce this after initial configuration.

3. All hosts MUST configure a default router when at least a router is
connected to the segment.

4. All hosts MUST detect the presence or absence of a DHCP-Server and
MUST switch to the DHCP-Server assigned address when one is detected.

I believe these 4 requirements rigoruosly handle all cases. I also
believe that the requirement to make sure that all subnets within an
internet to be unique is NOT a IP host config requirement but maybe a
single-router autoconfig requirement as it will be the router which
determines which subnets are assigned to segments connected to the
router. I am saying this based on Aboba's single-router autoconfig
draft which suggests to use a self-configuring router that uses
mini-DHCP to configure the hosts on the segments.

As for the discussion on periodic checks versus proactive IP address
collision detection, req. # (2) above only mandates that IP address
collisions must be detected but it does not mandate a way to do
it. You could do it by periodic checks by the hosts or proactively by
changing ARP. Tt is up to the implementor of the protocol.

I don't know if I have added more confusion to the discussion but just
wanted to express my ideas.

Cuneyt

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Aug 2000 20:12:36 -0700

>By definition, a default route is used
>to communicate with hosts off the local subnet.

That's not the definition of a default route.

A default route is the route you use if you don't find a match in any 
other route in your routing table. Hence the use of the word, "default."

Most Windows and Mac OS machines only allow two entries in the routing 
table -- "my local ethernet" and "everything else", leading people to 
believe that a "default route" is something fundamental about IP 
networking. It is not. Having a default route just says, "When you don't 
know what to do, send the packet to this guy, who might know what to do 
with it." Because Windows and Mac OS machines don't know what to do quite 
a lot of the time, people tend to over-emphasize the importance of that 
case.

>All hosts MUST configure a default router

Large chunks of the Internet backbone are "default-free", meaning that 
the machines don't have a default route entry in their routing table, 
because they all know exactly what to do with every packet, and never 
need to forward any packet to some other machine because they don't know 
what to do with it.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer