Subject: [Issue 27]: LL-only hosts

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 08:47:36 -0800 (PST)

I propose that this issue be rejected.

It does seem reasonable to require that a host be able to configure a
routable address, but I can also see devices being shipped that do not
configure such an address by default.

My recommendation would be to replace the currently proposed text with
something along these lines:

"Host supporting configuration of LLv4 address MUST also support
configuration of a routable address, whether manually or automatically."

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Feb 2003 13:22:27 -0500

> I propose that this issue be rejected.

it appears that you're supporting the issue in principle, but have
issues with the proposed wording.

> configuration of a routable address, whether manually or

manual configuration as an alternative would be fine with me as long
as 

a) the manual configuration includes netmask and default route
   (address alone is insufficient), and
b) a host that does not support the standard method of determining
   local network configuration for connected networks (presumably DHCP)
   SHOULD require manual configuration to enable LL.

but I don't want to see devices advertised as "complies with IETF LL
standard for zero configuration" if they do require configuration
to work correctly on connected networks.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 17 Feb 2003 23:38:29 -0500

> configuration of a routable address, whether manually or automatically."

No. Again, it is not the IETF's place to decide how a standard is to be
*used*. If someone creates a device that is v4LL only, but follows the
standard, then it's a compliant device. We have no business telling you that
"You must support routable addressing, even though your device will never
need, nor use one."

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Feb 2003 00:09:05 -0500

> *used*.

that's a completely ridiculous and unsupportable statement.  
worse yet, it's irrelevant.  if you take the care to read the proposed
text, it says nothing about how LL is used - it says that use of LL
for LL-only hosts is not within the scope of the standard.

what you seem to want is for IETF to endorse use of LL for purposes
that harm interoperability.  why in the world IETF should do that is
completely incomprehensible.

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 19 Feb 2003 06:22:03 +1100

> configuration of a routable address, whether manually or automatically."

I reject this, and anything else that requires a routable address to be 
implemented.

There are a range of applications where a routable address is of absolutely no 
value. I came to zeroconf looking for a solution for USB host-to-host cables. 
In Linux, those devices are presented by the OS as equivalent to ethernet 
devices. Several PDAs also use this.

I don't want a proprietary solution. I want to establish compatible IP 
addresses on each end, and run ftp/rsync/distcc/whatever over that 
connection, point-to-point. DHCP isn't going to be running, so there is no 
point in testing for it, and implementing DHCP clients in a PDA for spec 
compliant is stupidity.

I could agree if the requirement was changed to SHOULD.

Brad

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Feb 2003 14:40:34 -0500

> value. I came to zeroconf looking for a solution for USB host-to-host cables. 

please explain what that has to do with the Internet, why it's relevant to
the purpose of IETF or this WG, and why IETF should standardize a practice
that will harm Internet interoperability.

---

From: Brad Hards <[email-masked]>
Date: Wed, 19 Feb 2003 06:50:47 +1100

On Wed, 19 Feb 2003 06:40, Keith Moore wrote:
> > There are a range of applications where a routable address is of
> > absolutely no value. I came to zeroconf looking for a solution for USB
> > host-to-host cables.
>
Keith - please keep calm, and don't make emotive and unjustified statements in 
the form of questions. 

Either this WG has scope to discuss a protocol enhancement that only works on 
the local link (that is, using protocols already developed by the IETF), or 
it doesn't. If it doesn't, could all those who are only here for IETF reasons 
please move on, and let the rest of us get on with making it work. If it 
does, then what difference does it make whether the underlying transport is 
USB or ethernet?

Brad

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Feb 2003 15:12:19 -0500

> Keith - please keep calm, and don't make emotive and unjustified statements
> in the form of questions. 

FWIW, I'm very calm.  These are genuine questions.  To standardize LL-only
devices we need a convincing argument that these are in scope for this WG, and
by extension, IETF.  For this WG to exceed its scope would be a process error.
For this WG to produce devices which cannot interoperate with the Internet
would be a technical error. 

> Either this WG has scope to discuss a protocol enhancement that only works
> on the local link (that is, using protocols already developed by the IETF),
> or it doesn't. If it doesn't, could all those who are only here for IETF
> reasons please move on, and let the rest of us get on with making it work. 

if LL-only devices aren't in scope (and I'd claim that they're not), then the
people who want LL-only devices are the ones who need to move on.

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 19 Feb 2003 17:33:40 +1100

On Wed, 19 Feb 2003 07:12, Keith Moore wrote:
> devices we need a convincing argument that these are in scope for this WG,
> and by extension, IETF.  For this WG to exceed its scope would be a process
> error. For this WG to produce devices which cannot interoperate with the
> Internet would be a technical error.
If there is a mandatory requirement for zeroconf allocation of Internet 
routable addresses, then clearly we cannot achieve that with IPv4, and we 
should probably just give up and wait 10-20 years for IPv6. However I don't 
see that as a requirement.

If the requirement is really to achieve networking on a single network segment 
(ie where all hosts are reachable by link-layer broadcast/multicast), then 
there is no apparent requirement for anything except Link Local address 
assignment - DHCP is not needed.

BTW: In the absence of unambiguous statements on IETF scope as it relates to 
link local networking (which there may be, but I am not aware of), then 
precedence is a use guide. I'll cite ARP as an example of previous work that 
is clearly link-local.

Brad

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 19 Feb 2003 00:57:11 -0600

----- Original Message ----- 
From: "Brad Hards" <[email-masked]>
> should probably just give up and wait 10-20 years for IPv6.
=========================================================

It appears that the "LL" that you are interested in standardizing, could be classified
as part of the FM InterNAT, as opposed to the aging legacy AM (low quality) Internet.

You might want to consider setting the FM bit in the 160 bit header as part of your "LL" standard.

Are you on the AM Internet or the FM Internet ?

128-bit DNS AAAA Record Flag Day Formats
2003:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1AAAAAAAAAAAAAAA[32-bits][Port]
A...A=ASN=32769...65535

Jim Fleming
http://IPv8.isfun.net

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 19 Feb 2003 11:18:39 -0000

Saying that a standard which extends TCP/IP is immediately out of scope for
IETF wherever it does not connect to *The Internet* seems a very narrow
reading of the IETF's scope and begs a lot of questions about what would
happen should another standards body emerge specifically to develop IP
extensions. Suppose someone were to take IPv4LL to another standards body
because they perceive a need to to get a standard for LL only devices, there
then gets to be a problem of tracking and synchronisation of standards and
all sorts of thorny issues.

On the other hand Keith is right when he has continually beaten us around
the heads with the fact that as soon as a LL-only device gets connected to a
larger routed network, it (and more significantly other devices) starts to
misfunction and reminds us that this is an *interoperability* standard as
opposed to some other kind.

I would say that what is really needed is to split this into one
specification which simply defines how LL claim-defend works and a second
which dictates the conditions, warnings, prerequisits etc for using it in
generic devices which might be connected into routed networks. While, I
don't really see that there is the appetite or even possibility to make this
major change, the emphasis in the current doc could be along those lines.

I would like to see a phrasing which only allows LL-only devices where it is
known that the device, by virtue of its design, cannot or is highly unlikely
to be connected to a routed network. It should be possible to specify a
phrase such devices must use if claiming compliance such as "Isolated link
only".

Philip

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Brad Hards" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 18, 2003 8:12 PM
Subject: Re: [Issue 27]: LL-only hosts

> devices we need a convincing argument that these are in scope for this WG,
and

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Feb 2003 13:43:27 +0200

> From: "Philip Nye" <[email-masked]>

> phrase such devices must use if claiming compliance such as "Isolated link

I strongly disagree on this. I want to be able to run LL-only node in
parallel to the connected node.

And that, these "nodes" could be located virtually at same machine
sharing the network interface.

That is, for other hosts it looks like there are two hosts on the
link: one LL4 only host and another host, with global address. It is
no concern of IETF how I manage this situation internally within the
node.

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Feb 2003 13:53:10 +0200

And replying to myself...

> no concern of IETF how I manage this situation internally within the

The logical conclusion of above is, that if LL4 only nodes are out of
scope for this WG, the result of this WG is also irrelevant for me, as
I ONLY have LL-only node and globally connected node.

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 19:24:15 +0700

Date:        Wed, 19 Feb 2003 06:22:03 +1100
    From:        Brad Hards <[email-masked]>
    Message-ID:  <[email-masked]>

I support LL27 - the newer wording for it that has been proposed
is better than the original...  (there's less of it...)

  | There are a range of applications where a routable address is of
  | absolutely no value.

There are way too many people who believe that makes a difference.

This is irrelevant - if some manufacturer can guarantee that some
device can never possibly need a routable address, then the device is
clearly not going to be connected to the internet, and so claiming
conformance with an Internet standard would be irrelevant and useless.

This doesn't mean that the manufacturer can't implement, and use, LL
addresses, exactly as defined in the spec, without implementing any
more.   Such a manufacturer might also choose to do lots of other things
that the internet standards don't allow, like not bothering to check
TCP checksums (because they know the link level checksum, which is most
likely a much better algorithm, will have found any errors), and ignoring
anything in IP options (because none will ever be relevant) and not
implementing ICMP at all (because nothing in their system ever needs it).

None of that is ever permitted in an IETF standard however.

But ...

  | I came to zeroconf looking for a solution for USB host-to-host cables. 
  | In Linux, those devices are presented by the OS as equivalent to ethernet 
  | devices. Several PDAs also use this.

These kinds of devices are ones where routable addresses most certainly
are needed.   What's more it is almost inconceivable to imagine the
manufacturer of such a device that would limit their potential market
by not allowing any way where routable addresses could be assigned.

  | I don't want a proprietary solution. I want to establish compatible IP 
  | addresses on each end, and run ftp/rsync/distcc/whatever over that 
  | connection, point-to-point. DHCP isn't going to be running,

How can you possibly know?    It might not be running in your particular
case, and there's nothing stopping you disabling DHCP if the extra couple
of seconds delay is really going to bother you.   Other users will want
to use the device to its full potential, and that includes accessing random
web pages over that USB host to host "pretend to be an ethernet" device
via the router at the other end of the cable, etc.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 19:37:11 +0700

Date:        Wed, 19 Feb 2003 17:33:40 +1100
    From:        Brad Hards <[email-masked]>
    Message-ID:  <[email-masked]>

  | If there is a mandatory requirement for zeroconf allocation of Internet 
  | routable addresses,

You're misreading the request, which is not that.   What is being asked
is that nodes should be able to be configured to use routable addresses.
The mechanism doesn't belong to this WG.

The same nodes should also be able to autoconfigure themselves (LL addresses)
when there is no other configuration, so they can work on isolated nets.

  | If the requirement is really to achieve networking on a single network segment 
  | (ie where all hosts are reachable by link-layer broadcast/multicast), then 
  | there is no apparent requirement for anything except Link Local address 
  | assignment - DHCP is not needed.

It wouldn't be, if you can find a way for the node to know whether it is
on an isolated LAN, or whether it is connected to a LAN to which lots of
other LANs (and perhaps the whole internet) is also connected.

Or more relevantly here, if you can simultaneously describe a node which
cannot ever be connected to a LAN where having a routable address would be
an advantage, and which also has some need to conform with Internet standards.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 08:43:05 -0500

> see that as a requirement.

you're misunderstanding both the meaning of routable addresses and
the meaning of the requirement.  the requirement is that devices be able
to be assigned a routable address.  a routable address is essentially
an address other than an LL address.  (RFC 1918 addresses are routable,
though not globally routable)

one effect of the requirement is that the device can be connected to the
Internet if its user desires to do so.  

> I'll cite ARP as an example of previous work that 
> is clearly link-local.

but ARP permits devices to have routable addresses, and thus, to work with
the Internet.  LL by itself does not.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 08:58:51 -0500

> extensions. 

True.  And we've understood for years that while our standards are designed
for the Internet, they're often used in private and/or isolated networks. 
However what we're talking about here is a standard that allows a conforming
device to not _be able_ to connect to the Internet, which does seem over the
line.

> Suppose someone were to take IPv4LL to another standards body

It doesn't have to be that way.  For instance, the other standards document
could reference the relevant portions of the IETF standard.

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 21:26:20 +0700

Date:        Wed, 19 Feb 2003 13:43:27 +0200
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | I strongly disagree on this. I want to be able to run LL-only node in
  | parallel to the connected node.
  | 
  | And that, these "nodes" could be located virtually at same machine
  | sharing the network interface.

It isn't clear from this what you mean, I see two (at least) quite
different things that you might be doing.

You might mean that you're running a system, with two OS's on it
(in the sense of one OS hosting another, or virtual machines, each
running an OS), each of which is essentially independent of each
other (processes on one use network protocols to communicate with
the other in most cases).

Or, you might be meaning an implementation technique.

If its the latter, then for all practical purposes, you are doing both
routed and LL, and LL27 would not be of any concern to you - your system
will be able to be connected to the Internet, using routable addresses.
Your implementation method to allow this to work is of concern only
to you (and perhaps your users, depending upon how much of it is exposed).
Since I think you're concerned with Linux, and it is pretty hard to
imagine a linux system which (by design) cannot be connected to the
Internet, I suspect that fro your point of view anyway, you can ignore Ll27.

(There are other issues which would be relevant, but not this one).

On the other hand, if what you're describing are virtual machines,
each essentially independent of the other, then I can't see how you can
possibly know in advance whether either or both of them need global
connectivity or not, and I'd expect that both should (independently)
be able to acquire both LL and routable addresses.   I doubt this is
the interpretation you mean though.

kre

ps: Any time a node has 2 (or more) addresses, it looks to other hosts
(or hosts which don't examine the MAC addresses anyway, which would not
be reliable in any case) as if there are two distinct nodes.   There's
no defined (IPv4) way to take one address and discover other addresses
that may apply to the same node that I'm aware of.

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 19 Feb 2003 09:01:49 -0600

"RFC 1918 addresses are routable, though not globally routable" ?

By convention, that may be true with TOS=0x00,0x0*,0x*0 and when the AM/FM bit is 0.

The InterNAT is capable of routing around the aging, toy, legacy, 32-bit core network and
can use the 10.*.*.* address space and the other address spaces which are black-holes on the Internet.

Jim Fleming
http://IPv8.isfun.net

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 19 Feb 2003 09:06:03 -0600

"standards are designed for the Internet, they're often used in private and/or isolated networks..."
===

It is estimated that over 80% of all IPv4 equipment, is never physically connected to what some
claim is the global public transport. Did the Space Shuttle use the "Internet" for guidance information ?

Jim Fleming
http://IPv8.dyn.ee

.PS...Did the Space Shuttle use the "Internet" for guidance information ?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:29:55 -0500

> > True.  And we've understood for years that while our standards are
> > designed for the Internet, they're often used in private and/or isolated
> > networks. However what we're talking about here is a standard that allows
> > a conforming device to not _be able_ to connect to the Internet, which
> > does seem over the line.
>
> Devices with Net10 addresses cannot connect to the Internet either, except
> by NAT or application level proxy. 169.254/16 addresses are the same.

<ObNATflame>
NAT is not standardized, and use of RFC 1918 by NATs is a violation of RFC
1918.
</ObNATflame>

Of course RFC 1918 does allocate a block of addresses for use in isolated
networks.  But IETF's purpose in approving RFC 1918 as a BCP was to enhance
interoperability on the public Internet by giving private networks an
alternative to picking address blocks at random.  That way when those
addresses leak, as they inevitably do, they can be filtered, and the
condition can be unambiguously recognized as an error.

Now if this group were trying to publish a BCP that merely allocated a block
of IPv4 addresses to be used as LL addresses, without specifying the LL
protocol, I'd argue that RFC 1918 is an appropriate precedent.  (though many
would argue that RFC 1918 was a mistake and that based on experience we should
not make another similar mistake).

So please tell me - how does declaring LL-only devices to be in scope for
the standard enhance interoperability on the Internet?

Keith

---

From: Markku Savela <[email-masked]>
Date: Wed, 19 Feb 2003 22:50:01 +0200

> From: Keith Moore <[email-masked]>
> 
> protocol, 

The ONLY difference between use of RFC 1918 addresses and LL addresses
is that this group specifies a protocol by wich LL addresses are
automaticly assigned.

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 15:54:01 -0500 (EST)

> not make another similar mistake).

What is the mistake here you are talking about ? NAT ?

> the standard enhance interoperability on the Internet?

What is the Internet for you ? The globaly routable address space,
the backbone routers (which by the way are usually manmaged through
a 10.0.0.0 address) , or the 192.168/16 space in my home network ?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:51:44 -0500

> is that this group specifies a protocol by wich LL addresses are

no, that's not the only difference.  another important difference is that
RFC 1918 addresses are not supposed to be used except on isolated networks,
while LL addresses are permitted on links that are connected to the
Internet.

even so, if we knew then what we know now, we would not have approved
RFC 1918.  it was barely approved as it was.  those who said it would
be harmful were exactly right.  (I was one of those who was wrong.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:57:02 -0500

> What is the mistake here you are talking about ? NAT ?

yes.  there is a widespread belief that RFC 1918 encouraged NAT.

> What is the Internet for you ? 

the set of networks that are connected together using IP.

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 16:11:52 -0500 (EST)

> yes.  there is a widespread belief that RFC 1918 encouraged NAT.

Why is the  mistake in NAT ? What else was there ? Finally without
the private address space IP would have been choked to unuse.

> the set of networks that are connected together using IP.

What exactly do you mean by using IP ? What addresses, what protocols ?

What exactly do you mean by connected together ?  My home network
is connected togther by IPv4/Ethernet  - is it the Internet ?

I am begining to think that what you call Internet is not the same
as what others think. I do not really know what the term
Internet means, if there is any meaning at all.

Subrata

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:15:17 -0500

> the private address space IP would have been choked to unuse.

I'll reply in private as this is no longer relevant to this group.

---

From: Mika Liljeberg <[email-masked]>
Date: 19 Feb 2003 23:35:45 +0200

On Wed, 2003-02-19 at 22:51, Keith Moore wrote:
> another important difference is that

That claim is false.

RFC1918 divides hosts into different classes based on what type of
addresses they need. There is no restriction to use RFC1918 in networks
connected to the global internet.

	MikaL

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 16:35:43 -0500 (EST)

No, I think it is relevant to undertand what
you are trying to convey. Not only the NAT part, but
also the Internet part.  Till a precise meaning
is associated with the term Internet, I do not think
we should write a draft based on that.

Subrata

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:39:42 -0500

> connected to the global internet.

from RFC 1918, section 3:

   Private hosts can communicate with all other hosts
   inside the enterprise, both public and private. However, they cannot
   have IP connectivity to any host outside of the enterprise.

---

From: Mika Liljeberg <[email-masked]>
Date: 19 Feb 2003 23:46:19 +0200

>    have IP connectivity to any host outside of the enterprise.

A network having a few private hosts in addition to public ones does not
equal an isolated network.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:53:54 -0500

> equal an isolated network.

true enough.  1918 mostly talks about hosts being isolated, not networks.

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 17:42:28 -0500 (EST)

> true enough.  1918 mostly talks about hosts being isolated, not networks.

RFC 1918 is a BCP, not Internet Standard, hence non-binding.  Similarly
RFC3022 for NAT is an Informatioanl RFC.  So it is left to the user
community to determine what to use what not to use. Whereas RFC1918
does not categorically preclude NAT, it allows one to have ALG's.
In a generic way NAT's are ALG's, where payloads are left intact
and IP headers are slightly modified.

It looks to me that RFC1918 does a good deal of hand waving with
ALG's.

Also RFC1918 came in February 1996, whereas NAT became an RFC in
May 1994. Looks like a classic example of "Ex Post Facto Law".

Take the following staemet in RFC1918 Section 3.

"Private hosts can communicate with all other hosts inside the
   enterprise, both public and private.  However, they cannot have IP
   connectivity to any external host."

What this statement seem to convey is that if I need to access
the Web from my desk I will either have to have 2 networks or
physically move my computer to a second, public network. Absurd
requirements !

Subrata

---

From: Erik Guttman <[email-masked]>
Date: Thu, 20 Feb 2003 22:29:12 +0100 (CET)

[WG chair hat off]

On Tue, 18 Feb 2003, Keith Moore wrote:
>>> please explain what that has to do with the Internet, 

A LL-only device will support IETF standards for L4 and up.

>>> why it's relevant to the purpose of IETF 

There is no requirement that a host support all elective standards.
There is no standard which states that a host must support
configuration.  The closest we come is in RFC1123 where we say

         Finally, we note that a vendor needs to provide adequate
         documentation on all configuration parameters, their limits and
         effects.

and section 6.2.1(1)
           Diskless machines often have no permanent storage in which
              to store network configuration information, so that
              sufficient configuration information must be obtained
              dynamically to support the loading phase that follows.
 !            This information must include at least the IP addresses of
 !            the host and of the boot server.  To support booting
 !            across a gateway, the address mask and a list of default
 !            gateways are also required.

...
         A host with a disk may perform the first step, dynamic
         configuration.  This is important for microcomputers, whose
         floppy disks allow network configuration information to be
         mistakenly duplicated on more than one host.  Also,
 !       installation of new hosts is much simpler if they automatically
 !       obtain their configuration information from a central server,
 !       saving administrator time and decreasing the probability of
 !       mistakes.

Automatic (serverless) configuration of IP addresses is not envisioned
here. Support of configuration of a gateway address and network mask is
required only to boot over a gateway. 

            The suggested approach to dynamic configuration is to use
            the BOOTP protocol with the extensions defined in "BOOTP
            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
            defines some important general (not vendor-specific)
            extensions.  In particular, these extensions allow the
 !           address mask to be supplied in BOOTP; we RECOMMEND that the
            address mask be supplied in this manner.

Again, other ways of providing parameters are not excluded.

Nowhere is there a requirement that a host have an address of some
specific scope.  Nowhere is there a statement that a host without such
an address is outside fo the scope of IETF standardization. 

[WG chair hat]
>>> or this WG, 

This has been a stated objective of the WG since the first BOF.  This
was part of both Stuart's and my materials at nearly all of our WG
meetings.

[/WG chair hat]

>>> and why IETF should standardize a practice that will harm
>>> Internet interoperability. 

It is true that there may be issues for higher layer protocols which
work with LL addresses if there are any such devices which have
addresses in different scopes.   I have not seen any arguments that that
show that there are problems for a set of devices *solely* in link-local
scope.

We all agree this may not be completely straightforward to support
hosts using higher layer addresses with link-local address in an
environment with both link-local and non-link-local scoped
addresses.  We are committed to identifying the issues, finding a way to
minimize their effects and ensuring that *if* a host is configurable it
will interoperate well.  I do not see how one can then conclude that the
devices *must* be configurable.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Thu, 20 Feb 2003 22:29:38 +0100 (CET)

On Wed, 19 Feb 2003, Philip Nye wrote:
> generic devices which might be connected into routed networks. 

This is not an option at this late a date.  This would add months to the
process of completing work on the specification.

Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 17:01:38 -0500

> A LL-only device will support IETF standards for L4 and up.

but it won't interoperate with anything on the Internet.

I assert that it is a serious process violation, as well as a technical
error, if this WG tries to endorse LL-only devices in an IETF standard.

> There is no requirement that a host support all elective standards.

there is no requirement that IETF endorse things that won't interoperate
with the internet, and which if encouraged will degrade internet 
interoperability.

> specific scope. 

at the time 1123 was written, all IP addresses were globally scoped,
so any such requirement would have been superfluous.

> This has been a stated objective of the WG since the first BOF. 

and IIRC, there was significant pushback about this at the NITS BOFs.
did you think the problem would go away if it were ignored?

> addresses in different scopes. 

forget higher layer protocols for the moment.  LL-only devices can't
even exchange IP packets with devices that aren't on the link.
thus they cannot function with the INTERnet, which is fundamentally
a network consisting of concatenated networks.

furthermore I'll claim that encouragement of devices which cannot 
communicate with the Internet but can claim to conform to IETF standards
does harm to the Internet and dilutes the value of IETF standards.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Feb 2003 11:17:13 +0100

> error, if this WG tries to endorse LL-only devices in an IETF standard.

Folks,

It is fine for Keith to assert this.  He has however no special 
authority which allows him to interpret IETF process or determine
what is suitable for IETF standardization.  The IESG is the body
at the IETF who has this authority.

We will consider specific technical arguments as part of the call
for WG consensus on issues.  Please be concrete - abstract evocation
of architectural disasters have less weight than a single example
of useful technology.  The number, vehemence, or length of postings
will have no bearing on the WG consensus call.  Given that please
post sparingly, remain respectful, give concrete examples and keep
your statements to the point.

Erik
ZEROCONF WG chair

ps.  This message should not be taken to defend the position that
      I took in the mail Keith is responding to.  That position was
      taken by me as a WG contributor and so it also will be given no
      special authority or weight in the consensus call.

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Feb 2003 06:09:55 -0500

> of useful technology. 

Erik,

I consider it inappropriate for you, as chair, to make such an assertion. 
There is no basis for such an assertion in IETF process.  Giving direction to
WG participants as to which criteria they may use in making judgements as to
the suitability of this proposal for standardization is a process error.

Arguments about specific problems are more easily dismissed than general
architectural arguments.  Almost any specific example can be dismissed as
irrelevant, but a general problem that applies to multiple applications should
not be so easily dismissed.

Keith