Subject: RE: Solving the wrong problems

From: "Subrata Goswami" <[email-masked]>
Date: Sun, 26 Jan 2003 15:34:46 -0800

All IPv4 nodes except some should DHCP have clients, right? These some
exceptions
being the servers whose IP addresses are manually configured. There is 
all ready a exception for not using DHCP clients and LL would be just 
another one.  

In my view an IPv4 node MAY be configured an IP address in any of the
following ways: 
Manual, DHCP, PPP/RADIUS, LL, ... The order of preference SHOULD be
Manual, 
DHCP, LL, ... 

Why is it that a node that has no manual config or no DHCP is useless ?
Networking world has
many examples to the contrary (in Ethernet the MAC address is not
usually manually 
configured). Why can not IETF standardize LL independent of DHCP ? Why
is a device
that does not have DHCP is useless (LL can certainly supply the required
IP address in a 
non-conflicting way) ?

Subrata

> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]] 
> Sent: Sunday, January 26, 2003 2:25 AM
> To: Subrata Goswami
> Subject: Re: Solving the wrong problems 
> 
> 
>     Date:        Sun, 26 Jan 2003 01:26:09 -0800
>     From:        "Subrata Goswami" <[email-masked]>
>     Message-ID:  <008001c2c51c$f6994070$c900a8c0@SGOSWAMIPCL>
> 
>   | You are mandating a DHCP Client for all LL hosts - why ????
> 
> Not all LL hosts, all IPv4 hosts (except those for which 
> manual configuration alone is adequate, which may mean some 
> types of servers).
> 
> Hosts using LL are just a subset of that.
> 
> If a host has no DHCP, and no manual configuration, then it 
> is useless on the internet, and the IETF (in particular) has 
> no business standardising
> that.   We want to make standards that work in all environments, for
> all users - that's the point of having standards.
> 
> No-one is going to mandate that you use the DHCP that is 
> there, but if it isn't there, the device is simply useless to 
> me, and certainly isn't anything useful for the Internet (as 
> in *I*ETF).
> 
> kre
>

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Jan 2003 09:02:42 +0700

Date:        Sun, 26 Jan 2003 15:34:46 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL>

  | All IPv4 nodes except some should DHCP have clients, right? These some
  | exceptions
  | being the servers whose IP addresses are manually configured. There is 
  | all ready a exception for not using DHCP clients and LL would be just 
  | another one.

No.   LL is not "just another one".   DHCP and manual configuration offer
exactly the same functionality, just done by different people (in different
ways).   LL does not.   A host with a LL address is useless on the internet.

  | Why is it that a node that has no manual config or no DHCP is useless ?

Because it cannot communicate with the network if all it has is LL.
All it can communicate with is the link.   If that's all it wants to
communicate with, it doesn't need IP at all, it may just as well send
raw ethernet (or whatever its link layer is) frames and be done with it.
Why even pretend it is using internet protocols, when it is using them in
a way that they won't & can't work over the internet?

  | Networking world has many examples to the contrary (in Ethernet the
  | MAC address is not usually manually configured).

Of course it is, by someone at the factory.   If you want to (and can
invent a scheme that will actually work with Internet routing) have IP
addresses configured at the factory, that would be fine too.

  | Why can not IETF standardize LL independent of DHCP ? Why
  | is a device that does not have DHCP is useless (LL can certainly
  | supply the required IP address in a non-conflicting way) ?

No, LL only supplies LL addresses, which are useless on the internet.
Read the draft, routers aren't allowed to forward packets containing
them.   What use (on the internet) is a packet that no router is allowed
to forward?

Note: I am not saying that there's anything wrong with being able to get
a LL address, if that is all available on some particular net, that's fine.
What I am saying is that if there's some other address available for the
node, which will work better than the LL address, the node has to be able
to acquire that other address (via DHCP, manual configuration - or via
PPP or similar, though LL addresses and PPP aren't often going to be in
conflict).

kre

---

From: "Subrata Goswami" <[email-masked]>
Date: Sun, 26 Jan 2003 21:42:27 -0800

See inline

> Sent: Sunday, January 26, 2003 6:03 PM
> To: Subrata Goswami
> Cc: [email-masked]

 Agreed LL packets are not supposed to be forwarded by a router ( I
would
say this needs to be changed too), but it is still useful in the
link-local 
internet. Primarily because all application written on IP can still work
- 
there are very  few applications that work directly on top of the link
layer
protocol.

> communicate with, it doesn't need IP at all, it may just as 
> well send raw ethernet (or whatever its link layer is) frames 
> and be done with it. Why even pretend it is using internet 
> protocols, when it is using them in a way that they won't & 
> can't work over the internet?
> 

Not really, as I mentioned previously most applications are IP based
and primarily uses the Sockets API. LL would  allow these applications
to still work within the link (e.g. applications such as HTTP, Telnet,
FTP,
NetBIOS, NFS, etc.).

> invent a scheme that will actually work with Internet 
> routing) have IP addresses configured at the factory, that 
> would be fine too.
> 
> No, LL only supplies LL addresses, which are useless on the 
> internet. Read the draft, routers aren't allowed to forward 
> packets containing

Let us address the issue of forwarding packets to the Internet.
I guess the draft can allow for a NAT function in the LL link which
can be part of the router.  The NAT would translate the 169.254/16
address to a routable (locally or globally) address as they do for
192.168/16 or 10/24.  Although if a NAT is allowed then there is very
little distinction between 169.254 and 192.168. 

Currently the draft allows a LL node to access the  internet 
through an application level intermediary (i.e. the intermediary
can do the required NAT/forward when you type http://www.ietf.org ).

I my view the draft can be also be changed by replacing the following 
statement in several places  (this would allow disposing off the
intermediary).

From 

"The host MUST NOT send the packet to any router for forwarding"

To

"The host MAY send the packet to a router for forwarding" 
 
The router should be responsible for making the decision to 
forward/not-forward the 169.254/16 packets. If the router can
NAT a 169.254/16 then it MAY forward the 169.254 packet, if the 
router can not NAT the 169.254 packets it MUST not forward the 
169.254 packet.  

I concur with you  that adding the capability to access the global 
Internet would increase the value of LL.

> Note: I am not saying that there's anything wrong with being 
> able to get a LL address, if that is all available on some 
> particular net, that's fine. What I am saying is that if 
> there's some other address available for the node, which will 
> work better than the LL address, the node has to be able to 
> acquire that other address (via DHCP, manual configuration - 
> or via PPP or similar, though LL addresses and PPP aren't 
> often going to be in conflict).
> 
> kre
>

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Jan 2003 14:55:53 +0700

Date:        Sun, 26 Jan 2003 21:42:27 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL>

  | Agreed LL packets are not supposed to be forwarded by a router ( I
  | would say this needs to be changed too),

OK. you go and design the scheme that makes this work, write it up
as an I-D, and it will be considered, I'm sure.   In the meantime
I'd suggest that we should just continue with what we know can work.

  | but it is still useful in the link-local 
  | internet. Primarily because all application written on IP can still work
  | there are very  few applications that work directly on top of the link
  | layer protocol.

Of course.   No-one is doubting the utility of LL addresses when they're
appropriate to use.

The question (this particular question) is whether the IETF should be
suggesting to people that devices which only work on one link are reaosnable?
And all so that the implementors of those devices can avoid adding in a
DHCP client (which for an embedded device is likely to take a few hours
of effort - the hard part in most DHCP clients is interfacing with the
rest of the system, which isn't a problem embedded devices usually have).

  | Let us address the issue of forwarding packets to the Internet.
  | I guess the draft can allow for a NAT function in the LL link

Hmm - you're mandating NAT exist, and be enabled, in every router,
to allow LL devices to exist there.   And by inference you're also
mandating just one router on any LAN (NAT doesn't work when there are
alternate paths traffic can take).    I think I'll leave it for someone
else to respond to that suggestion.

  | Although if a NAT is allowed then there is very
  | little distinction between 169.254 and 192.168.

If there's only one LAN, yes, but 1918 addresses work (and are routed)
just fine throughout the whole organisation usually - with just one NAT
point at the exit from it to the Internet.   LL addreses don't work
like that.

  | I concur with you  that adding the capability to access the global 
  | Internet would increase the value of LL.

That's interesting, as that's not something I have ever said.   Devices
should be able to access the Internet (in case they are connected in
a place where that is possible - they should also be able to use LL, in
case they're connected in a place where there is no address management).

But the way to access the internet (and even just the rest of the
organisation) is to acquire an address of whatever kind is appropriate for
use in the organisation (if that happens to be a LL address, with NAT in
every router, I personally don't mind that too much, but I am dead certain
I am never going to use a net like that, so if the device is to have any
utility at all, it had better be able to get some other address instead).

kre

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 00:23:00 -0800

see inline

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Elz
> Sent: Sunday, January 26, 2003 11:56 PM
> To: Subrata Goswami
> Cc: [email-masked]

let me reiterate, there are applications such as HTTP, Telnet,
FTP, NetBIOS, NFS, which would still work with LL (within the link)
without  modification.

> The question (this particular question) is whether the IETF 
> should be suggesting to people that devices which only work 
> on one link are reasonable? And all so that the implementors 
> of those devices can avoid adding in a DHCP client (which for 
> an embedded device is likely to take a few hours of effort - 
> the hard part in most DHCP clients is interfacing with the 

It is not time needed to adding DHCP stack to a node, the question
is DHCP needed at all in all circumstances ?  In my view  DHCP
is not always needed and an LL node does not need to be DHCP cognizant.

> else to respond to that suggestion.

No I am not mandating NAT in every router, only the ones that are
willing
to forward 169.254 packets. In any case the draft already mandates that
every router be aware of 169.254, no harm in extending that notion a
little bit
more.

> If there's only one LAN, yes, but 1918 addresses work (and 
> are routed) just fine throughout the whole organisation 
> usually - with just one NAT

That is exactly what I meant. Its behavior similar to a packet with TTL
of 0.

> That's interesting, as that's not something I have ever said. 

well you mentined accessing the internet, which I assume can include
the global Internet too.

>   Devices
> should be able to access the Internet (in case they are 
> connected in a place where that is possible - they should 
> also be able to use LL, in case they're connected in a place 
> where there is no address management).
> 
> organisation) is to acquire an address of whatever kind is 
> appropriate for use in the organisation (if that happens to 
> be a LL address, with NAT in every router, I personally don't 
> mind that too much, but I am dead certain I am never going to 
> use a net like that, so if the device is to have any utility 
> at all, it had better be able to get some other address instead).
> 

What happens if you want a network that is not part of an organization 
(i.e. no central authority etc.) ? There is use for such networks 
(for instance in defense ). In such a situations you do not care about
any node outside the link.

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Jan 2003 16:46:32 +0700

Date:        Mon, 27 Jan 2003 00:23:00 -0800
    From:        "Subrata Goswami" <[email-masked]>
    Message-ID:  <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL>

  | let me reiterate, there are applications such as HTTP, Telnet,
  | FTP, NetBIOS, NFS, which would still work with LL (within the link)
  | without  modification.

Of course, within the link, any IP application will work with LL
addresses just fine (the application doesn't need to know they're
LL addresses, it probably doesn't know there's just one link, in
this particular environment, LL addresses are just addresses).

You don't need to keep repeating this, we all understand already.

  | It is not time needed to adding DHCP stack to a node, the question
  | is DHCP needed at all in all circumstances ?  In my view  DHCP
  | is not always needed

To there. I agree with you, DHCP isn't always needed.   But ...

  | and an LL node does not need to be DHCP cognizant.

How can the device (MP3 player, toaster, lightbulb, ...) possibly know
if it is going to be installed on a net where DHCP is needed, and used,
or whether it is not to be?

No-one is asking you to use DHCP on your net if you don't want to, and
if you don't, LL addresses as they currently seem to be being defined will
work for you just fine.

But on my net, such devices simply won't work - the system I use to
control my light bulbs will not be on the same LAN as the light bulbs
themselves.   And there will ne no NAT.   If the light bulbs are unable
to use DHCP to get addresses, they are useless, they'll never turn on
(or off perhaps) and so are no better than no lightbulb at all.   Why
would a light bulb manufacturer even consider making bulbs that can't
work for many consumers, when they can trivially be made for everyone?
Why would the IETF want to suggest that making such things is an
acceptable thing to do?

(Of course, no-one can stop a manufacturer manufacturing them if it
wants to, if it thinks it can make them that much cheaper, and so
attract the consumers for whom LL addresses alone are sufficient, then
it will do that, whatever the IETF says).

  | No I am not mandating NAT in every router, only the ones that are
  | willing to forward 169.254 packets.

OK, but if LL addresses are to be useful outside one LAN, the router
on that LAN has to be in that set - which would effectively mean every
router has to have it, just in case.   After all, you would never be able
to tell whether or not someone might just connect one of your proposed LL
only devices on that particular LAN.

  | In any case the draft already mandates that every router be aware
  | of 169.254, no harm in extending that notion a little bit more.

I kind of suspect you won't find many people agreeing that the step
between "don't forward LL" and "automatically NAT LL packets" is
just "a little bit more".

  | >   | I concur with you  that adding the capability to access 
  | > the global 
  | >   | Internet would increase the value of LL.
  | > 
  | > That's interesting, as that's not something I have ever said. 
  | 
  | well you mentined accessing the internet, which I assume can include
  | the global Internet too.

Yes, of course, it was the implication of accessing it from LL
addresses that I didn't ever say.

  | What happens if you want a network that is not part of an organization 
  | (i.e. no central authority etc.) ?

Then there'd be no-one to run DHCP, and you'd be using LL addresses.
Do remember that "node attempts to use DHCP" (which is what is being
requested) does not mean "there must be a server to answer" - if there
is none, then the node just reverts to using LL addresses instead.

  | There is use for such networks (for instance in defense ).

The concept of a defence network with no central authority is mind
blowing to me, but for your point, that doesn't really matter.

  | In such a situations you do not care about any node outside the link.

Yes, there are lots of times that that will be sufficient.  And once again,
no-one wants to prevent that from working.   Nothing that is being proposed
would do that.   Such networks are the basic model for zeroconf.

The issues that are being raised are all to make sure devices that are
planned for use on those networks, also will be able to work properly,
without disruption, when connected to other kinds of nets.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 27 Jan 2003 10:38:41 -0000

Robert,

> or whether it is not to be?

I agree with you but draw slightly different conclusions. I see the
rationale in adding the DHCP client as a commercial one: Add a DHCP client
and your device will scale (from tiny to huge networks) without any
configuration required (at the device). Omit the client and you will have to
answer to disappointed customers. While it is good to point this out (I
would be happy with a "SHOULD" clause), I don't see a need to mandate DHCP -
the market will decide. If a manufacturer is sufficiently sure that their
specialist device will only be used on a single link why shouldn't they omit
the DHCP client.

The only other reason to _mandate_ DHCP is to make an RFC2563 style option
work to allow central administration to turn LL off entirely.

Otherwise the draft should just ensure that if a DHCP client is present, the
v4LL code interracts with it properly.

Philip

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jan 2003 10:25:53 -0500

I came to the conclusion while commuting to work this AM that this 
discussion is mixing zeroconf with zerodesign.  That is, we're trying to 
come up with a protocol that provides zeroconf AND also provides zerodesign 
- trying to take away the requirement for any design decisions on the part 
of the device implementer.

For example, consider these four cases (please give me a little suspension 
of disbelief; I've heard each of these scenarios proposed as real scenarios):

1 Bluetooth sensor device - will never connect to off-link
   device; always uses special-purpose applications for
   access and management.

2 Printer in home office - will never be used by off-link
   computer; accessed through existing, standard printing
   applications

3 Printer in enterprise network - will be used by on-link
   and off-link computers; accessed through existing,
   standard printing applications

4 Laptop - will be used in internets and ad hoc networks,
   will use existing and new applications

These cases require different design decisions:

1: LLv4-only, perhaps no connectivity if DHCP admin
    says "no LLv4"?
2: LLv4-only, no attempt to use global address
3: Perhaps LLv4 and global; perhaps global only
    if device admin knows device will never
    be accessed with LLv4-compatible applications
4: Perhaps LLv4 and global; perhaps global only;
    user may want notification or choice of action
    if global address assignment fails

Maybe the problem is a "mechanism" versus "policy" issue;
trying to impose encode a single policy in the protocol
rather than providing a mechanism for implementing
a variety of policies - both in the client and in
the network...

So, here's a concrete proposal:

We devise mechanisms for obtaining an LLv4
address, recognizing conflicts in address assignment
and recovering from conflicts.  This standard
is independent of DHCP.

We devise a mechanism for DHCP through which
a network admin can advise cooperating devices
that those devices SHOULD NOT obtain or
use LLv4 addresses.

We write a BCP doc that suggests strategies for using
these two mechanisms in different operational
scenarios.

We let individual device implementers, device admins
and network admins make the design
decision about how to employ each of these
mechanisms.

- Ralph

---

From: Alex Karahalios <[email-masked]>
Date: Mon, 27 Jan 2003 08:52:29 -0700

Hi Ralph,

Your proposal sounds very reasonable. You have a yes vote from me.

Alex Karahalios

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 27 Jan 2003 11:36:26 -0500

> that those devices SHOULD NOT obtain or

I would add a third mechanism independent of DHCP that allows for LL to be
turned on or off manually. There is a need. We don't dictate the how, just
that it's there. 

john

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 11:37:33 -0500

strongly disagree.

It's entirely unreasonable for a device to assume that it's okay to
run LL on an IP network.  It's almost entirely unreasonable for a device
to assume that LL will be sufficient for its purposes.  

I don't care what the mechanism is, but there MUST be some mechanism
to allow a network to disable LL, and devices MUST support it.

this is a showstopper.

Keith

---

From: Daniel Senie <[email-masked]>
Date: Mon, 27 Jan 2003 12:12:29 -0500

>ways).   LL does not.   A host with a LL address is useless on the internet.

And...? So LL addresses are useless on the big-I Internet. They are not 
useless overall. Is that a problem?

>a way that they won't & can't work over the internet?

Because there are USEFUL THINGS to do with the TCP/IP protocol suite OTHER 
than talking to someone on the far side of the planet. LL can and does 
provide a communications path for such.

>Of course it is, by someone at the factory.

I suspect he was implying overriding of the factory value, but cannot be 
sure. Most people should not mess with this, but there are times when it's 
useful.

>    If you want to (and can

That would not be fine.

>No, LL only supplies LL addresses, which are useless on the internet.

The fact that the addresses are "useless on the Internet" does not mean 
they are useless on a local network. I'm not sure whether you're trying to 
imply this or not.

>them.   What use (on the internet) is a packet that no router is allowed

None. But that does not make such addresses or packets useless. There's 
more to the world of networking than the big-I Internet.

>a LL address, if that is all available on some particular net, that's fine.

OK

>PPP or similar, though LL addresses and PPP aren't often going to be in

And this is FINE for a Host. However, if we're talking about a printer or 
print server, it may not be fine. A printer may do better having both an LL 
address and a non-LL address. The preference would be to use the non-LL, 
but if talking with a device that has no non-LL address, having the ability 
to print might be useful (if that's what the owner of the devices wants).

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jan 2003 14:01:39 -0500 (EST)

Keith - I think we are going to disagree on this point...but maybe we're
disagreeing about different points.

In your second paragraph, what do you mean by "okay to run LL on an IP
network"?  Do you mean "LL will be sufficient for its purposes" or that LL
is something that the network admin wants to allow on the link.

IMHO, the assumption that "LL will be sufficient for its purposes" is a
design decision by the device/stack/application implementer.

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 14:29:02 -0500

> IMHO, the assumption that "LL will be sufficient for its purposes" is
> a design decision by the device/stack/application implementer.

Strongly disagree.  The device/stack/application implementor has no idea
about the characteristics of the networks that the device will
connect to, and therefore has no idea whether or not the device is going
to be able to talk to the other hosts it needs to talk to using only the
local link.

Or at least, the set of devices for which this is a reasonable
assumption is within epsilon of the null set.

---

From: "s. goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 14:34:29 -0500 (EST)

> assumption is within epsilon of the null set.

The device knows who it needs to talk to but does not know what
type of network it would be connected to ? I am not even sure I follow
the logic. May be an example would help.

Subrata

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 14:42:17 -0500

> the logic. May be an example would help.

the device doesn't know either one. 

do you really expect me give an example of something that doesn't exist?

Keith

---

From: "s. goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 14:48:43 -0500 (EST)

> do you really expect me give an example of something that doesn't exist?

It would be good if you can, else I am having a hard time imagining
the situation.

Subrata

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jan 2003 14:50:44 -0500 (EST)

Keith,

So, I guess we'll agree to disagree on this point.  Does the following
protocol design requirement capture your argument?

  Because a device/stack/application cannot know the characteristics of
  the network that the device/stack/application will use, it is a
  requirement that there be a mechanism through which a network
  administrator can disable the use of LLv4 addresses.

My requirement might read:

  The use of LLv4 addresses by a device/stack/application is a design
  decision of the implementer.  It is a requirement that there be a
  mechanism through which a network administrator can indicate that a
  device/stack/application should not use LLv4 addresses.

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 14:57:56 -0500

> > > type of network it would be connected to ? I am not even sure I
> > > follow the logic. May be an example would help.
> >

okay, how about Santa Claus.  or the Easter Bunny?

Let me put it to you another way.  You want to sell a device that
performs function X  to a customer, and the only way it can get an IP
address is via LL.  How do you whether that customer's other devices
that need to talk to your product are going to be on the same network
link as your device?  You have no idea.  You may think it's useful or
desirable to impose that constraint on your product for security
reasons, but that's also being naive - you have little or no idea about
which threats your customer is concerned about, and no idea about the
distribution of those threats relative to the network link your customer
is going to use with your device.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 27 Jan 2003 20:04:43 -0000

> to be able to talk to the other hosts it needs to talk to using only the

I see this purely as a commercial decision. It is clear that the uses of a
LL only device will be severely limited. However there may well be
applications where those limitations may well be recognised and accepted.

Stop thinking of "computers" and think of the IP/Ethernet equivalent of a
USB or CAN or GPIB "network" but with some advantages of range and bandwidth
scalability. USB doesn't sweat about routability it lives with its
restrictions - so could an LL only device. The user probably wouldn't even
know that IP was being used.

I see this as separate from the issue of whether a network administrator
wants to keep such devices off a more general purpose network - for which
DHCP option is one way to go.

Philip

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 15:12:43 -0500

>   Because a device/stack/application cannot know the characteristics
>   of the network that the device/stack/application will use, it is a

It's also a requirement that the device be able to use DHCP addresses.

The underlying requirement is that the device be able to interoperate
with the address allocation mechanisms (i.e. DHCP) in existing IP
networks, when they exist.  Being able to function on ad hoc IP networks
that use v4LL is fine, as long as the device uses the DHCP-assigned
address on networks that use DHCP.

>   device/stack/application should not use LLv4 addresses.

I don't think this is a useful way to state it.

*Of course* LLv4 support is optional for the implementor.  We've had ~23
years of IPv4 deployment and have done fine without LLv4 support for
most of this time.  We're not going to start telling vendors that they
have to implement LLv4 in order to comply with the internet protocol. 

But don't expect IETF to write a standard that says that LL-only devices
are okay.  We know there are problems with such devices, we know that a
specification that allowed such devices would not meet 2026 requirements
for standards track.  We also know that IETF can't stop vendors from
shipping such devices if they wish.   (and sadly, IETF isn't likely to
sue vendors who mislead their customers about how well these devices
conform to the standards)

So let's not waste our time trying to get IETF to lie, okay?

Keith

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jan 2003 14:14:35 -0600

> router can not NAT the 169.254 packets it MUST not forward the

IPv4ll doesn't provide a way to discover routers.   So it has to be the 
router's responsibility to block or NAT ipv4ll addresses, because the 
IPv4ll node doesn't have enough information to do it.

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 15:17:56 -0500

> Stop thinking of "computers" and think of the IP/Ethernet equivalent
> of a USB or CAN or GPIB "network" but with some advantages of range
> and bandwidth scalability.

Indeed, this is what I'm thinking about.  This reminds me of the
original arguments surrouding SCSI-over-IP.  The original idea was that
you didn't need security because even though these were IP devices they
wouldn't be accessed from distant nodes.  I note in reading the
latest iSCSI draft that this has now been turned completely around. 
It turns out to be useful to be able to access SCSI devices from very
distant nodes.

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 16:17:46 -0500

> IPv4ll doesn't provide a way to discover routers.   

no, but DHCP does, and all IPv4LL-capable devices need to understand
enough of DHCP to know whether they should use a v4LL address or a
routable address.  IMHO they should also be able to discover a netmask
and a default route.

v4LL should be for ad hoc networks only.

Keith

---

From: "s. goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 16:36:46 -0500 (EST)

> is going to use with your device.

Sorry I still do not see your point, and example seems pretty vague.
If you want your device to talk to the gloabl Internet then use
DHCP/PPP/BOOTP/manual. But my devices do not give a hoot about
the global Internet and they form dynamic networks, why sould I be
burdened to support DHCP which I am not going to use ?

Subrata

---

From: "s. goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 16:45:34 -0500 (EST)

see inline

> It's also a requirement that the device be able to use DHCP addresses.

I  do not agree with this.

> >   device/stack/application should not use LLv4 addresses.

I my view the above should read "It may be that there could be a mechanism
through which a network adim ..."

> have to implement LLv4 in order to comply with the internet protocol.

Well 23 years is a long time and lot of things have changed. If you
have forgotten 23 years ago there were no Interent per se, no PC,
no cell phone, no PDA, no email, ....  Times have changed and IP should
evolve too.

> So let's not waste our time trying to get IETF to lie, okay?

IETF  has lot of standards which are not exactly popular.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jan 2003 15:54:16 -0600

> all IPv4LL-capable devices need to understand
> routable address.

The draft doesn't say this.   Further, it's irrelevant, because the 
DHCP server may not provide a complete list of routers - indeed, there 
may not *be* a DHCP server.

Look, take this as an exercise: write up a draft that completely 
describes how an IPv4ll client would avoid sending packets through a 
router.   If you can describe an algorithm without any obvious gaping 
holes, and you really think it's implementable, propose it here.   The 
reason I make this statement is that I just now tried, and wasn't able 
to do it.   E.g., let's say you did a DHCPINFORM and got information 
about the local routers.   Now what?   You want to send a packet to 
198.45.127.2.   You're IPv4ll, so you can't do routing, so you ARP for 
it.   If you don't get an answer, you don't send the packet, so that's 
not a problem.   But what if the router is doing proxy ARPs?   Then you 
get an ARP reply from the router, and you have to compare that to the 
entry in your ARP table for the IP address of the router, and not send 
it in that case.   But you don't *have* an entry in your routing table, 
because you're not doing routing, because you're IPv4ll and don't have 
enough information to do routing.   Confused yet?   Now, what about 
routers that are doing proxy ARP but aren't mentioned in the DHCP 
packet?   What about when there is no DHCP packet?

I think what the authors intended here was just to say that if you only 
have an IPv4ll address, you shouldn't try to do IP routing - that is, 
you shouldn't notice that something's off-subnet somehow and try to 
send it to a router.   You should just ARP for it.   And the draft 
should say this, but perhaps in a way that doesn't lead to a thought 
process like the one I described above.   :'}

---

From: Scott Lawrence <[email-masked]>
Date: 27 Jan 2003 17:48:55 -0500

Ted Lemon <[email-masked]> writes:

> You want to send a packet to 198.45.127.2.   You're IPv4ll, so you
> can't do routing, so you ARP for it.   If you don't get an answer, you
> don't send the packet, so that's not a problem.   But what if the router is
> doing proxy ARPs?  

Then either the router is broken for answering, or will be broken if
it does anything other than drop the packet - it can't route it.
Either way it isn't the devices problem.

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 23:04:21 -0500

> burdened to support DHCP which I am not going to use ?

there's a big gap between the global Internet and a single link.
and you don't know which of your devices will need to operate beyond
the local link and which ones won't. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 23:07:00 -0500

> no cell phone, no PDA, no email, ....  Times have changed and IP should

go read RFC 2026 and its requirements for proposed standard status.
and stop insisting that this WG "evolve" IP in a way which not only
violates 2026 but is far beyond this group's charter.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jan 2003 23:27:04 -0500

On Mon, 27 Jan 2003 15:54:16 -0600
Ted Lemon <[email-masked]> wrote:

> The draft doesn't say this. 

the draft is subject to change.  and it needs to change.

Keith

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 27 Jan 2003 22:40:33 -0800

Yes I do know which device needs global, which needs LL, and which needs
both.

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Monday, January 27, 2003 8:04 PM
> To: s. goswami
> Cc: [email-masked]; [email-masked]; [email-masked]
> > DHCP/PPP/BOOTP/manual. But my devices do not give a hoot about the 
> > global Internet and they form dynamic networks, why sould I be 
> there's a big gap between the global Internet and a single 
> link. and you don't know which of your devices will need to 
> operate beyond the local link and which ones won't. 
> 
> Keith
>

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 19:16:02 +0700

Date:        Mon, 27 Jan 2003 10:38:41 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <062901c2c5f0$429be0d0$131010ac@aldebaran>

  | I agree with you but draw slightly different conclusions. I see the
  | rationale in adding the DHCP client as a commercial one: Add a DHCP client
  | and your device will scale (from tiny to huge networks) without any
  | configuration required (at the device). Omit the client and you will have to
  | answer to disappointed customers.

Yes, as I said, nothing can stop manufacturers doing what they want.

Our question is what the IETF should say is acceptable.   In the context
of your comment - do you think it acceptable if the device manufacturer
can answer the disappointed customers by saying "What I did is correct,
see, the IETF says that implementing DHCP clients is optional, if the
device doesn't work for you, there must be something wrong with your
network"  ?

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jan 2003 19:33:08 +0700

Date:        Mon, 27 Jan 2003 12:12:29 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Because there are USEFUL THINGS to do with the TCP/IP protocol suite OTHER 
  | than talking to someone on the far side of the planet. LL can and does 
  | provide a communications path for such.

Of course.  You seem to think I am arguing against the existence of
LL addresses.  I am not.

The point you're missing here however, is that you (as the manufacturer
of a device) cannot possibly know whether the someone I want the device
to talk to is on the same LAN, on an adjacent LAN just the other side
of that nearby router, or on the other side of the world.   You might
find it peculiar to imagine that someone on the other side of the world
should want to communicate with it, and that the owner of the device might
want exactly that (given that they may be the same person), but peculiar
or not, we should not be recommending to anyone that they prevent such things.

Not being able to assign anything but a LL address (which is what this
particular sub-thread was about) means they prevent such things.   That
isn't something we should be endorsing, regardless of whether or not
such things may one day get (inappropriately INMNSHO) get built.

  | I suspect he was implying overriding of the factory value,

no, I think he was trying to give an example of an address that wasn't
manually configured - just picked a bad one.

  | >    If you want to (and can
  | >invent a scheme that will actually work with Internet routing) have IP
  | >addresses configured at the factory, that would be fine too.
  | 
  | That would not be fine.

I assume you mean that it wouldn't work, and I agree (see the
parenthetical remark), but if it could work (somehow I cannot
imagine) then it would be fine.

  | However, if we're talking about a printer or 
  | print server, it may not be fine. A printer may do better having both an LL 
  | address and a non-LL address.

No, it makes no sense.   All you ever *need* to talk IP is one address.
With one (of sufficient scope anyway) you can talk with anyone and
everyone.   Having two (other than in situations where you want to
seem to be two disjoint entities, which isn't the issue here) is of
no benefit whatever.

  | The preference would be to use the non-LL, 
  | but if talking with a device that has no non-LL address, having the ability 
  | to print might be useful (if that's what the owner of the devices wants).

Of course.   But you *do not need* a LL address (in the printer) to make
that work.   I thought that misconception had been beaten to death already.
What you need is for the printer to know about LL addresses and how they work.
But of course, if the printer were to ever have an LL address, that would be
a pre-requisite.

(This also has nothing to do with what the rest of this message, and the
previous one, were about, which related to whether the device should
attempt to obtain the non-LL address in the first place, or whether devices
should be perpared to simply settle for having a LL address and desire nothing
else.)

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 08:43:04 -0500

> Yes I do know which device needs global, which needs LL, and which needs

no you do not, unless you also control the networks to which your devices are
attached.

---

From: Erik Guttman <[email-masked]>
Date: Tue, 28 Jan 2003 15:09:18 +0100 (CET)

By now we have heard from certain contributors enough to know where they
stand.  Those of you who are posting several times a day, **please
restrain yourself.**

Those of you who have not responded to Thomas Narten's plea for input,
please do so. 

Some of you have not expressed your opinion on the matter of whether the
IPv4LL specification has to specify 

  a mechanism whereby a host who *cannot obtain* an address
  configuration parameter (whether from DHCP, manual, etc) MUST
  unconfigure its IPv4LL interface and stop using IPv4LL as its source
  address. 

Whether this mechanism is that a host can discover a DHCP server which
will not hand out an address, or whether the DHCP server will then send
the host a RFC2563 or RFC2563-like message is interesting, but not the
fundamental question.  The question is *Should there should be* an
explicit policy and mechanism for administrative disabling of IPv4LL
configuration included as mandatory to implement in the IPv4LL spec? 

Let's take input on this for another week (till Feb 4) then assess the
positions taken.  This document is currently in the IESG's hands, having
gone through several WG last calls and two IETF last calls.  We leave it
to Thomas and Erik to determine the next step.

Thanks,

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 28 Jan 2003 15:00:31 -0000

> From: "Keith Moore" <[email-masked]>
>

In the embedded world, controlling (or specifying) the network as well as
the devices is not such an uncommon scenario.

Philip

---

From: Markku Savela <[email-masked]>
Date: Tue, 28 Jan 2003 17:13:39 +0200

>   unconfigure its IPv4LL interface and stop using IPv4LL as its source

I don't have direct answer, but let me explain how it is implemented
in the dual IPv4/IPv6 stack which I've been involved with.

- there is configuration flag for LL. When enabled, it will install
  169.254/16 as onlink for the interface and generate LL address for
  itself.

- interface can also have simultaneous any number of other addresses
  and netmasks configured (from manual configuration, DHCP etc).

- if a destination address is LL, then system will use LL source
  address. If destination is global address, system will require
  global source address (LL address won't do -- I suppose this is
  against the LL draft, but as this is actually an IPv6 stack
  supporting scoped addressing, it applies the same source address
  selection rules as for IPv6 addresses)

I cannot see what the big fuss is about, if a node configures itself
for LL? It does not hurt any other nodes. Link is no worse by it, sees
only few ARP's which go unanswered. And if THERE are more than one LL
node, what harm does it do if they manage to communicate with LL's?

And, if a LL node has some applications that get confused by LL, then
again this only hurts the node itself, and I'm perhaps willing to take
my chanches, that there are no such thing.

I don't see any need for 'mechanism to disable', at least not
mandatory.

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 10:21:59 -0500

> > no you do not, unless you also control the networks to which your devices
> > are attached.
> 

You can do whatever you want on your own network that you control.
You don't need to follow IETF's standards if you don't wish to do so,
and you don't need IETF's blessing to do whatever it is you want to do.
You are then responsible for, and the victim or beneficiary of,
whatever mess or marvel you create.

The purpose of IETF's standards is to allow things to interoperate 
when that degree of control does not exist.  If you implement IPv4, you're
supposed to be able to exchange packets with other devices that implement
IPv4.  It defeats IETF's purposes to say that it's okay for some devices 
to implement a special kind of IPv4 that doesn't interoperate with normal
IPv4, or which does so only under some narrow set of conditions.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 28 Jan 2003 10:51:04 -0500

>Of course.  You seem to think I am arguing against the existence of

You did give that impression. I am sorry I misinterpreted your words.

>of that nearby router, or on the other side of the world.

While that's fine, it's NOT an issue for this draft. If I decide to build a 
device that only talks LL, and you don't want such a device, you won't buy 
it. It's a marketplace matter, NOT a standards matter.

>    You might

And we should NOT be dictating how manufacturers design product at that 
level. If a manufacturer wants to build a device that does LL, and does 
MANUAL configuration of IP addresses, but not DHCP, is that really your 
problem, or theirs?

>such things may one day get (inappropriately INMNSHO) get built.

I don't know that we're endorsing it by permitting the particular scenario. 
I guess we just disagree on this point.

>imagine) then it would be fine.

Let's avoid items in the discussion that couldn't possibly work, and stick 
to the specific issues.

>seem to be two disjoint entities, which isn't the issue here) is of

I look forward to seeing running code.

>that work.   I thought that misconception had been beaten to death already.

 From one end, yes, but let's explore it for a moment longer.

>But of course, if the printer were to ever have an LL address, that would be

The laptop will have ONLY a route for 169.254/16. So when it gets an answer 
from 192.168.23.34/24, for example, how does it know to get a packet back? 
If we're saying LL implementations MUST ARP for ALL addresses via the local 
LAN, even those outside 169.254/16, then yes it would work. Is that how 
you're suggesting it work? I'm not sure we've sufficiently said that in the 
draft if it's the case.

Without such a route, the LL-only machine would have no route to where the 
printer is. A host which does have LL-only address and transitions off 
would also need to REMOVE this "default route everything to the local wire" 
route. If that's the intention, then fine. That's not how the stacks I've 
worked with have operated, but it's entirely possible everyone is happy 
with this approach. Looking forward to seeing running code.

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 28 Jan 2003 11:08:01 -0500

> device doesn't work for you, there must be something wrong with your

That won't happen more than once...the customer then says, "This other
vendor does what I want with 40% less sass-mouth, so buh-bye"

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, 28 Jan 2003 11:45:04 -0500

> While that's fine, it's NOT an issue for this draft. If I decide to
> build a device that only talks LL, and you don't want such a device,
> you won't buy it. It's a marketplace matter, NOT a standards matter.

The current draft has problems which prevent implementations from
interoperating with existing IP hosts and networks and which cause
cause implementations to violate policies of existing networks. It is
inconsistent with long-established IETF standardization criteria to say
that those problems are for the marketplace to sort out.  Such
tactics only serve further delay this group's producing a useful
solution for ad hoc networks.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 28 Jan 2003 08:47:39 -0800

>   unconfigure its IPv4LL interface and stop using IPv4LL as its source

As I mentioned in a previous message, this configuration parameter
should really mean that "the hosts on this link have been configured to
not accept packets from an IPv4LL address, so configuring one is
futile."

My opinion is that if we define this option, its configuration should be
explicit, i.e. it should not be a side effect of the mere discovery of a
DHCP server. The default behavior, in the absence of the option, should
be to authorize use of IPv4LL.

The security section of the draft should include a discussion of the
denial of service potential of this option: a rogue DHCP client could
potentially use it to disrupt IPv4LL based operation. However, we should
note that to implement a rogue DHCP client requires access to the local
link, and that an attacker with link access already has several other
means of disrupting IPv4LL operation, for example simulating address
collision or spoofing ARP packets. It is not clear that defining the
DHCP option would make IPv4LL any more insecure than it already is.

It is debatable whether the actual refusal of communication with IPv4LL
should be a side effect of the "no IPv4LL parameter", or whether it
should be explicitly configured in the local hosts, e.g. by programming
their "personal firewall". Given the ease with which DHCP packets can be
forged, I would personally prefer the latter, i.e. that IPv4LL aware
hosts will only refuse to communicate with IPv4LL addresses if
explicitly configured to do so.

> configuration included as mandatory to implement in the IPv4LL spec?

I believe there should be one. If we do not provide this option to
network managers, we are likely to see uglier alternative develop, e.g.
explicit interdiction of IPv4LL by having the DHCP server reply to all
ARP probes for IPv4LL addresses.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 12:14:22 -0500

> My opinion is that if we define this option, its configuration should
> be explicit, i.e. it should not be a side effect of the mere discovery
> of a DHCP server. The default behavior, in the absence of the option,
> should be to authorize use of IPv4LL.

I am fine with having the default being that v4LL is authorized as long
as networks are given a clear way to say "no automatic configuration of
v4LL", and as long as v4LL implementations are expected to honor this as
a matter of standards compliance.  

I'm also fine with hosts having a way to override this by manual
configuration.  (actually I think it's highly desirable that they
be able to do so)

> potentially use it to disrupt IPv4LL based operation. However, we
> should note that to implement a rogue DHCP client requires access to
> the local link, and that an attacker with link access already has
> several other means of disrupting IPv4LL operation, for example
> simulating address collision or spoofing ARP packets. It is not clear
> that defining the DHCP option would make IPv4LL any more insecure than
> it already is.

In addition, the security risks of having v4LL be disabled by a rogue
DHCP client need to be balanced against the security risks of having
v4LL be enabled inappropriately.  Anytime an attacker can cause a host
to be configured in such a way that it does not gain full functionality
from the network, this is a denial of service.  One way to do that is to
cause a host to fail to use v4LL on an ad hoc network.  Another way
to do that is to cause a host to use v4LL when it should be using a
routable address assigned by DHCP.  And there is also the potential for
an attacker to coerce a host into violating network policy by
interfering with DHCP and causing it to configure a v4LL address. Each
of these scenarios needs to be addressed.

> It is debatable whether the actual refusal of communication with
> IPv4LL should be a side effect of the "no IPv4LL parameter", or
> whether it should be explicitly configured in the local hosts, e.g. by
> programming their "personal firewall". Given the ease with which DHCP
> packets can be forged, I would personally prefer the latter, i.e. that
> IPv4LL aware hosts will only refuse to communicate with IPv4LL
> addresses if explicitly configured to do so.

I think it's very useful to distinguish between automatic and/or
default behavior that happens in the absence of explicit configuration,
and what is allowable when a host is explicitly configured.  

> network managers, we are likely to see uglier alternative develop,
> e.g. explicit interdiction of IPv4LL by having the DHCP server reply
> to all ARP probes for IPv4LL addresses.

agree entirely.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2003 12:33:33 -0600

> What I did is correct,
> network

Erm, AFAIK implementing DHCP clients *is* optional.   The manufacturer 
can *already* say this.

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 13:39:53 -0500

> Erm, AFAIK implementing DHCP clients *is* optional.   The manufacturer

Indeed, DHCP is optional.  However if you don't have DHCP, having a
mechanism to explicitly configure an address has always been a practical
necessity.

A device has never been able to simply allocate any address it
wanted and expect to be able to interoperate. This is still the
case even if it uses the v4LL discipline for allocating an address.  

Keith

---

From: "s. goswami" <[email-masked]>
Date: Tue, 28 Jan 2003 14:00:44 -0500 (EST)

see inline

> ARP probes for IPv4LL addresses.

even with a specified way of disabling LL this DoS would work. moreover
links are usually protected (for 802.11 it is TKIP, for 802.3 it is
802.1x etc.). so in light of these protections a rouge host joining
the link is negligible. the administrator (if one exists) of the link
would first enforce these layer 2  mechanisms to make sure no unauthorized
acess to the network has been made.

with a specifed way of turning off LL on a link we have the consequences
of someone using that mechanism as DoS. a better mechanism would be for
each node to make its own decision about whether it wants to
receive/respond to a LL packet or not.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 29 Jan 2003 15:11:11 +1100

Erik Guttman wrote:
> The question is *Should there should be* an

I think a DHCP option (or similar mechanism) is unnecessary.

Text recommending that an IPv4-LL address not be configured only
if an address has been acquired via DHCP would be fine with me.
It happens to co-incide with what most implementations do
already and was suggested less than two weeks ago without any
serious objections from people on the list.

The sample set of messages I have read in the last few days hasn't
turned up any new information that would change my opinion.

- aidan

---

From: Erik Guttman <[email-masked]>
Date: Wed, 29 Jan 2003 09:40:13 +0100 (CET)

Many useful applications of v4LL I have heard of are to allow a
user-administrator to access with a no-console device locally to
manually configure it.  These v4LL devices should not be mimosa that
shut down as soon as they are touched with certain DHCP options or lack
of them. They should be able to continue using their v4LL configuration
at least until they get another address (through DHCP, manual
intervention, etc) or else they will *never* get configured with an
address. 

The goal of giving administrators more control over v4LL devices'
behavior is frustrated by having those devices shut down completely. 

Erik

---

From: Robert Elz <[email-masked]>
Date: Wed, 29 Jan 2003 16:47:58 +0700

Date:        Tue, 28 Jan 2003 10:51:04 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | While that's fine, it's NOT an issue for this draft. If I decide to build a 
  | device that only talks LL, and you don't want such a device, you won't buy 
  | it. It's a marketplace matter, NOT a standards matter.

This is a common argument, but follow it through and the only conclusion
is that nothing is a standards matter.   Why should an implementor put the
IP source address in before the IP destination address in IP headers rather
than the other way around?   If a manufacturer decides to build such a
device it will only talk to other similar devices, but that's (apparently)
OK, if you don't want such a device you don't buy it.

Every standard that exists could be dismissed with such an argument.

If you're of the opinion that there shouldn't be standards, and everyone
should just do whatever they like, then this should be fine with you, but
in that case, I have no idea what you're doing here, as the rest of us
are attempting to actually define a standard.

The idea is that devices interoperate properly when they obey the standard.
On the Internet, using the Internet Protocols, that means that devices can
talk to each other over the Internet.

If you'd prefer to have devices just talk to each other over a LAN, you're
in the wrong place, IEEE define standards for that, the IETF doesn't.

  | And we should NOT be dictating how manufacturers design product at that 
  | level.

No, you're misunderstanding again.   No-one is telling the manufacturer what
it is allowed to do (or not here anyway, that's for legislatures to do, and
we aren't one).

What we're doing is saying "If you build a device according to these rules,
then it will operate correctly on the Internet".   That's our job here,
beginning and end (within the limits of the charter as to what kind of
specific rules this WG gets to define of course).

  | If a manufacturer wants to build a device that does LL, and does 
  | MANUAL configuration of IP addresses, but not DHCP, is that really your 
  | problem, or theirs?

No-one's problem.   I have no problem allowing just manual config.
Manual config is fine (not user friendly perhaps, but with (full)
manual config available, the host is able to interoperate with the
network, assuming it is properly configured).

My problem is with devices that have neither manual config, nor DHCP
(nor anything else similar).   Those devices are the ones that can't
interoperate properly.

  | >No, it makes no sense.   All you ever *need* to talk IP is one address.
  | I look forward to seeing running code.

There's plenty of running code now.   In fact, I don't know of a single
IP stack where this doesn't work (which doesn't mean there aren't any,
there are lots of stacks I haven't ever used).

  |  From one end, yes, but let's explore it for a moment longer.

Fine, though we have done all this before.

  | The laptop will have ONLY a route for 169.254/16. So when it gets an answer 
  | from 192.168.23.34/24, for example, how does it know to get a packet back? 
  | If we're saying LL implementations MUST ARP for ALL addresses via the local 
  | LAN, even those outside 169.254/16, then yes it would work.

yes, of course.   But why "only a route for 169.254/16" - if I was configuring
a node to have a LL address, which means I cannot be configuring a router
(we have no way to get such a thing), I'd always configure 0/0 on the local
link.

I have no idea how I'd make a device with 2 (or more) interfaces worth with
only LL addreses, but I suspect that no-one else does either.

  | Is that how you're suggesting it work?

Yes, of course.

  | I'm not sure we've sufficiently said that in the draft if it's the case.

Agreed.   The draft says "MAY" for doing this.

With your philosophy of "manufacturers do what they like and we buy what
works for us", you should be happy enough with that....   You just but LL
devices which do it "the right way" and don't buy ones that can't talk to
devices with no LL address.   That's exactly what you were recommending
above, right?

Personally, I'd prefer to have that MAY turn into a MUST, I see no reason
at all why it can possibly benefit anyone to have a device with only a LL
address unable to communicate with any other random IP address it sees,
and for interoperability, I'd simply require that devices attempt to work.

Note, it is much simpler (for everyone) to do it this way, than to add
the complication of requiring all the nodes that have non-LL addresses to
acquire a LL address, and add the complexities of choosing which address
to use, etc, and having to deal with all of that baggage.

  | A host which does have LL-only address and transitions off 
  | would also need to REMOVE this "default route everything to the local wire" 
  | route.

yes, fine.   When it is reconfiguring itself, it can do that.

  | If that's the intention, then fine.

Good, we agree.

And now, to attempt to keep the number of messages / day / person lower,
some replies to some other messages I have seen on the list in the past
24 hours or so (a bit less I think).

Apologies if this makes it hard to follow, hard for threading, etc, but
keeping the number of messages down was requested.

I pretty much agree with all of Christian Huitema's recent message
Message-Id: <[email-masked]>
(what a mouthful that is).   There is some emphasis there I might
change slightly, but nothing fundamental (nothing that matters now).

[email-masked] said in  <[email-masked]>:
| Erm, AFAIK implementing DHCP clients *is* optional.   The manufacturer  can
| *already* say this. 

Yes, of course.   But without LL, what we get is manual config, and
that's adequate (not nice, as above, but adequate).   Note that for
manual config we have some rules (1122, 1123) about what needs to be
able to be configured (and what doesn't).   So, I have no problems if
someone makes a PC operating system which doesn't implement DHCP (even
if it defaults to configuring itself a LL address).   Such a device I
can always get at via its console and alter its config to something that
will work.   I wouldn't like such a device, and probably wouldn't buy
it, but if someone attempts to connect such a thing to my net, I can make
it work - it doesn't simply fail to interoperate.

It is the "no configuration, no DHCP, LL addresses are good enough to
work for everyone" kind of device that I want the standard to say
"this is not a standards conforming device".

[email-masked] said in <Pine.SOL.3.96.1030129092949.10152C-100000@field>:
| The goal of giving administrators more control over v4LL devices' behavior is
| frustrated by having those devices shut down completely.  

Huh?   Do you know what you're assuming?    You're assuming here that the
network operator is totally incompetant.   He both wants to talk to the
device, so he can configure it, and he wants it to fail to communicate.

Why would we care?   Are you also going to mandate that devices all be
able to function with no AC connection (power) because the local administrators
might not allow the device to be connected to a power point?

DHCP servers will only be configured to tell a device not to use LL addresses
if the administrator does *not* want to talk to the device using its LL
address to otherwise configure it (or doesn't want to with the device connected
to the net it is plugged into now).

Take an example of a situation that may easily happen.   You have a desk,
and on the desk are two RJ-45 jacks.   One of those is connected to a
"wide open" net, where almost anything can and does happen, all kinds of
of hackers hang about (not by desire, there's just nothing preventing them).
You might think of that as being outside the network firewall - I usually
think if it as being inside the firewall, where all the undregraduate
students are doing whatever they feel like playing at...

The second jack is connected to your nice secure stable network, where
only yourself gets to connect devices, and only you get to use any of
the devices that are connected (this may seem too good to be true, but
real networks can at least approach this).

Now assume you have this new device, unconfigured, that will assign itself
a LL address, so you can connect to it and configure the thing.

And you plug it into the wrong network by mistake...   Now some evil
cretin gets in before you do (you're looking for it on the other net
of course, and not finding it there - takes a couple of minutes to
realise what happened).   During that period, they configure the device
with a network address, access password, ... of their choosing, and
disable LL addresses.    Now you find the cable problem, and plug the
device into your net, and start to try and find it to configure it.   Oops...

On the other hand, if out on the evil network, we had a DHCP server that
would tell the device "no LL addresses for you", and would simply shut itself
off, and remain inert, until you move it to the net it was supposed to be
connected to in the first place.   No-one gets in, no-one locks you out.

This isn't foolproof of course - as an attacker could be running a rogue
DHCP server on the open net, announcing that LL addresses are acceptable.
Rogue DHCP servers are a general problem, and counter measures against
them (which generally amount to detection, and then the application of the
big stick) are needed anyway if the net is to function.   Doing this also
implies some amount of preparation, whereas if the device is just there
with a LL address and some simple minded (unconfigured, so no password)
configuration server running (http, telnet, snmp, whatever) then an
opportunist which just sees the device advertise itself (which it must do
for LL addresses to be usable, or you'd never guess the right one) can
get in there with no preparation.

Is perhaps this one an example that lets people see just why it is that
we (some of us anyway) want to define a method to prevent LL addresses
being used?   (And yes, manual configuration of the device always overrides
everything else).

kre