Subject: RE: IESG draft-cheshire-ipv4-acd-02.txt

From: "Christian Huitema" <[email-masked]>
Date: Fri, 13 Dec 2002 13:00:13 -0800

> I don't see how "not impos[ing] v4LL by default, on hosts or network
> that don't want to use it" will change the scope of security issues.
> This won't limit the use of IPv4LL addresses to just ad hoc networks.
> IPv4LL is useful on all IPv4 networks especially for initially
> configuring a device and for devices that simply don't need global
> addresses.

I very much doubt that. We already have IPv6 link local, which provides
you with a solid "on link" solution, without having to rely on short
random numbers and error-prone collision detection. The classic argument
against relying on IPv6 is that the infrastructure is not ready; but in
the case of link-local, there is no infrastructure. So, if you want new
features, you can just use IPv6.

The real argument for IPv4 link-local cannot be to provide hosts with
new features -- we have IPv6 for that. The only argument is some form of
compatibility with legacy IPv4 only devices. But if you focus on legacy,
then you don't want to deal with stuff that the legacy cannot handle
well, e.g. having multiple addresses per interface, or having multiple
subnets on the same link. (Or, for that matter, playing game with the
TTL value.)

-- Christian Huitema

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 13 Dec 2002 14:57:58 -0800

> features, you can just use IPv6.

The amount of work required to support IPv4LL on a device that already 
implements IPv4 is trivial compared to the amount of work required to 
support IPv6. On the other hand, the IPv6 APIs give developers scope 
IDs so link-local can be supported on more than one interface without 
the nightmare of a link-local address being ambiguous on a multi-homed 
host.

> subnets on the same link. (Or, for that matter, playing game with the

IPv6LL is great. Unfortunately, IPv6 stacks are not that common. IPv4LL 
gives us a solution with just a little work while people go through the 
huge effort required to write an IPv6 stack or while they wait for IPv6 
support in the embedded OS of their choice. In addition, many IPv4 
application will work with IPv4LL addresses without modification, 
despite arguments to the contrary from Keith Moore. To take advantage 
of IPv6LL, an application must be rewritten.

The IPv6 APIs have the notion of a scope id. This is important for 
IPv6LL addresses. Unfortunately, there doesn't appear to be a good way 
to discover an IPv6LL address with it's scope id. IPv6LL addresses 
probably shouldn't appear in unicast DNS packets. Most service 
discovery protocols resolve services in to URLs which usually don't 
contain scope ids. This leaves us with the option of manually entering 
IPv6LL addresses, which isn't much fun. Until this is addressed, IPv6LL 
addresses probably won't be as useful as they ought to be, IMHO.

-josh

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 19:06:09 -0500

> IPv6LL is great. Unfortunately, IPv6 stacks are not that common. 

every major OS vendor except Palm is shipping them.

>IPv4LL gives us a solution with just a little work 

just a little work for the IPv4 stack.  LOTS of work to keep v4LL 
from causing problems for applicaitions and networks.  but of 
course that's "somebody else's problem".

> In addition, many IPv4
> despite arguments to the contrary from Keith Moore. 

you're misstating my argument.  just because "many" apps will work
doesn't mean that v4LL won't cause lots of problems.

> To take advantage

and to avoid having v4LL cause problems, many applications need at
least the same amount of rewriting.

> probably shouldn't appear in unicast DNS packets. 

for that matter, neither should v4LL addresses.

another nice thing about v6LL's is that v6 folks don't pretend they're
suitable for all or even most applications.  

Keith

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Sat, 14 Dec 2002 11:30:56 -0600

> every major OS vendor except Palm is shipping them.

  Really?  My new HP printer and LinkSys wireless AP have IPv6 in them?

  These are the devices I want to see zeroconf on.

  And IPv6 may be simpler in the bigger picture, but IPv4 is already there.

   -j

-- 
                     Jay A. Kreibich | Integration & Software Eng.
                        [email-masked] | Campus IT & Edu. Svcs.
          <http://www.uiuc.edu/~jak> | University of Illinois at U/C

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Dec 2002 12:39:11 -0500

>   Really?  My new HP printer and LinkSys wireless AP have IPv6 in them?

admittedly I don't know about v6 support in popular embedded device kernels.
but I'd be surprised if these kernels supported v4LL either.
 
>   And IPv6 may be simpler in the bigger picture, but IPv4 is already there.

that's the same kind of argument that the IPP folks gave for insisting on
layering everything over HTTP - and it turned out to be a huge mess.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 14 Dec 2002 12:43:50 -0500

> layering everything over HTTP - and it turned out to be a huge mess.

Gee...and I thought I was doing so well printing with it.

john

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

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Sat, 14 Dec 2002 11:54:05 -0600

> but I'd be surprised if these kernels supported v4LL either.

  I doubt it either, but to get out the next firmware update that does,
  which upgrade (IP4LL or IPv6) requires more work, time, money, effort,
  flash space, etc.?  It isn't like you can swap the IPv4 stack out for
  an IPv6 stack-- it will need to support both.  People build, sell,
  buy and use products in the real world.

> layering everything over HTTP - and it turned out to be a huge mess.

  Most of IPv4 is a huge mess.  It is UGLY.  But it is already there.
  
  And when IPv6 comes and makes its mark it will all go away.  The question 
  is not "will IPv4LL replace IPv6LL", it is only a question of holding 
  off until IPv6 becomes common place and saves the world "in two or 
  three years", just like the IPv6 people have been telling us for the 
  last 5 years.

  While far from 100% true, there is a great deal of truth in the old
  saying "A good solution today is better then the ideal solution tomorrow."

   -j

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Dec 2002 12:57:49 -0500

>   flash space, etc.?  

I honestly don't know - it's not at all clear that just because an existing
stack supports vanilla IPv4 that addition of v4LL is a slam-dunk.   

Keith

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Sat, 14 Dec 2002 12:03:46 -0600

> stack supports vanilla IPv4 that addition of v4LL is a slam-dunk.   

  Fair enough.  I agree that until a few more products go through this
  development cycle we won't have a really solid idea.  Desktop systems
  and embedded devices are very different beasts.

  That said, if I was a business manager, I know where I would put my
  money and development team's efforts.

   -j

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Dec 2002 13:08:12 -0500

>   money and development team's efforts.

well, most business managers would probably believe that the standard
solution is the one most likely to be worth investing in.

the question for IETF is different - it's which solution is the best
one to ask people to invest in?  

Keith

---

From: Alex Karahalios <[email-masked]>
Date: Sat, 14 Dec 2002 11:11:53 -0700

Hi Keith,

Just as an example. I am finishing an embedded controller project which 
implements v4LL (and mDNS). The code size for LL is 412 bytes with 28 
bytes used for initialization. Implementation time took about 1 week.  
LL is actually not that useful in my case without mDNS - but that is 
another topic ;)

Alex Karahalios

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 14 Dec 2002 13:36:58 -0500

> solution is the one most likely to be worth investing in.

Actually, that's an incorrect assumption. It's more along the lines of which
solution will serve customers best now, and for a little while longer. If
there is a standard available, and the business can use the standard easily,
they will. But if there is customer demand now, and the standard is still in
argument stage, then they'll cross their fingers, use what they have and
make money, hoping they can upgrade later.

john

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Dec 2002 13:42:33 -0500

> LL is actually not that useful in my case without mDNS 

indeed - and mDNS seems a lot less likely to be standardized than v4LL.

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 14 Dec 2002 14:43:14 -0500

> indeed - and mDNS seems a lot less likely to be standardized than v4LL.

That's pretty sad, since I'll put even money that we'll never see a v4LL
standard. Yet another really useful idea in the roundfile.

I really think that in the end, the vendors will create a defacto standard
that will get formalized. Zeroconf is too much of a no-brainer to sit on
ones hands for the years it will take for the standards to be finished.

john

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

---

From: "Bill Rees" <[email-masked]>
Date: Sat, 14 Dec 2002 17:57:03 -0800

----- Original Message -----
From: "John C. Welch" <[email-masked]>
> ones hands for the years it will take for the standards to be finished.

Ahhh, this is the heart of the matter.  The arguments everyone pushes seems
to really revolve around whether zeroconf is a good idea (along with mDNS)
as presently defined/specified.  Security issues, v4LL versus v6LL, mDNS or
not, all revolve around whether or not auto-dynamic configuration with the,
emphasis on automatic (i.e. without interactive intervention), is a good
idea or not.

bill

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 14 Dec 2002 22:49:20 -0500

> emphasis on automatic (i.e. without interactive intervention), is a good

To the people who just want to use computers it is. They don't want to care
how it works. They don't have to with their playstations, so why should they
with their home computers? As the people who *do* know how and why the
things work, we have a responsibility to make sure that the people who don't
need to know can just get work done. I'm not in the business of supplying
monkey work for IT, and I hate doing consulting on this kind of mindless
configuration idiocy. If we aren't going to get it in gear, then get out of
the way so that someone who WILL make this easy can do so.

john

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

---

From: Aidan Williams <[email-masked]>
Date: Tue, 17 Dec 2002 10:32:55 +1100

> indeed - and mDNS seems a lot less likely to be standardized than v4LL.

The presence or abscence of a standard with the IETF imprimatur may
not have much to do with whether people build products using these
protocols.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Dec 2002 18:52:53 -0500

> not have much to do with whether people build products using these

sometimes it does; sometimes it doesn't.  but IETF's imprimatur wouldn't
mean anything if IETF didn't insist that its (quite reasonable) technical 
criteria for standardization were followed.

repeated attempts to try to get IETF to endorse bad practices (whether 
or not they're in shipping code) are just wasting time.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Tue, 17 Dec 2002 11:05:37 +1100

Keith Moore wrote:
> repeated attempts to try to get IETF to endorse bad practices
 > (whether or not they're in shipping code) are just wasting time.
> 

Inability of participants in a standards forum to reach a
compromise is also a waste of everyone's time.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Dec 2002 19:15:00 -0500

> compromise is also a waste of everyone's time.

indeed.  but when when that inability is caused by a refusal of 
some participants to even consider making changes to the protocol 
to address known and well-documented technical problems (some
of which were identified even before the group was formed)
accusations of "wasting time" by those parties ring hollow.

I suspect we agree that wasting time benefits nobody.

Keith

---

From: Alex Karahalios <[email-masked]>
Date: Mon, 16 Dec 2002 17:29:18 -0700

Hi Keith,

Exactly what protocol changed are you referring to? It seems that I 
have lost track with all these other  "discussions" exactly what you 
were suggesting needed changing. I mean this sincerely because this 
effects me directly in my LL implementation.

Thanks,

Alex Karahalios

On Monday, December 16, 2002, at 05:15  PM, Keith Moore wrote:

> but when when that inability is caused by a refusal of

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Dec 2002 19:47:18 -0500

> effects me directly in my LL implementation.

I suppose we should ask Stuart what he thinks is holding things up,
since he and I may have different ideas about that also
(we seem to have different ideas about everything else)

As for the changes that I think are necessary, my intention is to
take the review I did of the protocol and publish it as an Internet-draft.
If I try to summarize them off the top of my head I'll probably leave 
something out.  But from memory, the main thing I thought was needed 
was a standard way for the network to be able to disable hosts' use of v4LL.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 16 Dec 2002 19:48:53 -0500

> I suspect we agree that wasting time benefits nobody.

Oh I dunno...this has been a fascinating insight that has answered a lot of
questions on how the IETF does, or as the case may be, doesn't get things
done, and why.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 16 Dec 2002 17:25:14 -0800

> was a standard way for the network to be able to disable hosts' use of 

You still haven't, in my opinion, presented a good argument for this. 
Should the network also have a way to disable AppleTalk? What about 
DHCP? Or maybe IPX and IPv6 while we're at it? You claim that IPv4LL 
exposes clients, even those not self-assigning IPv4LL addresses, to 
increased security threats. When asked about specific threats you just 
blew off the question by asking if I really expected you to list them 
again, as if they were so obvious I should all be aware of the threats 
already.

I'll ask again, what are the specific threats introduced by nodes on 
the network using IPv4LL addresses?

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Dec 2002 23:09:50 -0500

> Should the network also have a way to disable AppleTalk? 

AppleTalk is not an IETF standard, thus not in scope for IETF.
And AFAIK it doesn't affect apps that aren't written with AppleTalk
in mind, so some of the issues with v4LL don't apply to AppleTalk.

> What about DHCP? 

It's easy for a network to disable DHCP - just turn the server off.

> Or maybe IPX and IPv6 while we're at it? 

Again, IPX isn't an IETF protocol; and IPv6 doesn't have the same 
set of issues as retro-fitting LL into IPv4.  That's not to say that
there are no issues associated with running IPv6 on a network, but 
the ipv6 working group and its predecessors have generally been willing 
to discuss those issues and look for workarounds, rather than pretending 
that they don't exist.

> You claim that IPv4LL exposes clients, even those not self-assigning 
> IPv4LL addresses, to increased security threats. 

The threats to hosts (not just "clients") that don't use v4LL exist when 
other hosts on the network can be compromised because they are using 
v4LLs; the compromised hosts can then be used as a platform from which 
to mount additional attacks on non-LL-aware hosts.   Networks can also
be attacked in this manner (e.g. broadcast pings).  

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 17 Dec 2002 01:19:26 -0500

> in mind, so some of the issues with v4LL don't apply to AppleTalk.

Dodge the point...

> It's easy for a network to disable DHCP - just turn the server off.

No...that disables the ability to USE the DHCP server. You would still have
clients trying to connect.

> to discuss those issues and look for workarounds, rather than pretending

Maybe they decided that getting something accomplished besides arguing was
important. But then, since IPv6 is about as widely used as SNA, it doesn't
really matter right now.

> be attacked in this manner (e.g. broadcast pings).

That's vague enough to apply to every IPv4 system on every network
everywhere in a not-off condition.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 16 Dec 2002 23:09:27 -0800

> It's easy for a network to disable DHCP - just turn the server off.

Anyone can run a DHCP server. There isn't a way for the network to 
disable DHCP servers or to keep clients from using DHCP.

> be attacked in this manner (e.g. broadcast pings).

This is true of any host, whether it's using an IPv4LL address or an 
address acquired through some other means. Is there something about 
this scenario that makes nodes with IPv4LL addresses more susceptible?

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Dec 2002 08:36:11 -0500

> disable DHCP servers or to keep clients from using DHCP.

hosts don't ship with DHCP servers installed and enabled by default.  
the occasional rogue DHCP server can be identified and tracked down.

by contrast, a network with one or two hosts running v4LL is not
likely to cause many problems (and they can probably be tracked
down also and the v4LL turned off if there's a way to do that),
but a network full of hosts running v4LL because they shipped
that way is a different question.
 
> > The threats to hosts (not just "clients") that don't use v4LL exist
> > when other hosts on the network can be compromised because they are using

v4LL can provide alternate access paths to hosts which are not 
protected by firewalls.  this is particularly true with wireless
interfaces. 

(there is also a risk that v4LL addresses will be trusted more than
other v4 addresses, and thus attacks via v4LL will be easier than
attacks via v4 routable addresses.  but this is not a protocol 
problem, it's a perception problem, and the only thing that can be 
done about it is to document the problem and try to educate implementors
and administrators.)

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 17 Dec 2002 09:44:52 -0500

> the occasional rogue DHCP server can be identified and tracked down.

Enabled? No. Installed? Well, many unix/linux distros do ship with this
capability. However, manually having to detect and track down a rogue DHCP
server is not any more secure than a random LL box, and in fact is LESS
secure, because DHCP can allow *any* machine to not only get on the network,
but also then act as a bridge to the Internet with ease. So I find it rather
odd that you support DHCP, considering it's obvious shipping security flaws.

> that way is a different question.

A network full of machines running DHCP servers is just as bad. And before
you say "That's not how they ship", I have an XP laptop that will prove you
wrong...internet connection sharing is a default option. And you have yet to
show specifically how v4LL will be a security hole *greater* than any other
v4 machine beyond the standard vague warnings of doom.

> protected by firewalls.  this is particularly true with wireless

Um...that's true of wireless interfaces WITHOUT v4LL. Wireless has problems
with this far and above LL. As well, on most modern Uis, Internet connection
sharing is either a wizard default, (XP) or takes about three seconds to set
up, (OS X), and now, you're a rogue DHCP server. So v4 !LL provides even
MORE paths to do the damage you are talking about. Again, provide specific
cases that can be dealt with, or stop with the Chicken Little.

> done about it is to document the problem and try to educate implementors

Nonsense. Any IP address that belongs on the network is equally trusted, and
it's FAR more likely that non LL addresses will be trusted. LL makes for a
pretty sad staging point for attacks, when you can tap wireless so easily
and get a non-LL trusted address. LL doesn't automatically mean that you are
connected to the non-LL net in a given network. That requires bridging. And
since you can set up bridging for DHCP with *exactly* as much effort as you
can with LL, and DHCP will give a *far* better staging point for attacks
than LL, it would seem that you really need to deal with the default DHCP
option security issues more than LL.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 17 Dec 2002 09:42:28 -0800

> the occasional rogue DHCP server can be identified and tracked down.

Hosts do ship with DHCP servers installed, and they are very easy to 
enable.

Most hosts also ship with DHCP clients and the DHCP clients are often 
enabled by default.

> that way is a different question.

You have made it clear that you're concerned that IPv4LL will wreck 
havoc on your network. Is your fear justification for a requirement 
that there be some way to disable IPv4LL on all hosts on a network? How 
can a host verify that the person that really owns the network is the 
person trying to disable IPv4LL? What's to keep some evil ISP from 
disabling it so I have to pay the ISP for extra addresses or drop in a 
NAT? IPv4LL should work when nothing else does, why should we add a way 
to break it intentionally. One that may be difficult for someone 
without a lot of savvy to track down?

> protected by firewalls.  this is particularly true with wireless

I don't follow. IPv4LL addresses only have a scope of the local link. 
Firewalls usually block traffic between the outside world and the local 
link. The check for TTL 255 which I seem to recall you opposing, would 
allow hosts to verify that IPv4LL traffic is not originating from off 
of the local link. Yes, a malicious host could setup a tunnel and not 
decrement the TTL. The same malicious host could create a similar 
tunnel through the firewall for non-IPv4LL addresses. Ultimately, to 
get to the host from somewhere off the local link, the traffic will 
have to pass through the firewall.

I don't see how IPv4LL makes wireless any less secure either.

Are there some specific examples perhaps?

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Dec 2002 13:01:11 -0500

> Hosts do ship with DHCP servers installed, and they are very easy to

yes, but this has to be done manually.   if you want to make it so
that LL has to be enabled manually I would have no problems with it. 
 
> Most hosts also ship with DHCP clients and the DHCP clients are often

having DHCP clients be enabled by default mostly makes them vulnerable
to attacks from rogue DHCP servers.  

> havoc on your network. 

no, I'm concerned that v4LL will cause problems for numerous networks
and applications.  these concerns are not "fears" as you try to dismiss
them, they were supported by extensive analysis. 

the burden in on the working group to show that this proposal meets
the requirements of RFC 2026.    so far it has refused to do so.

> link. 

what planet are you from anyway?  this is complete garbage.  
you're wasting my time.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 17 Dec 2002 13:10:10 -0500

> that LL has to be enabled manually I would have no problems with it.

Incorrect. The Windows XP port wizard will enable a DHCP server without
explicitly telling you this as the default action when you have wireless and
wired connections enabled.

> to attacks from rogue DHCP servers.

Which is a huge security risk, because then the clients assume they are
talking to a trusted host. The only authentication used is MAC address
lists, and a chimpanzee can figure out how to fake that. Heck, I have an
Asante router that will do this at the click of a button. Seems to me that
DHCP, and not LL is the real security risk here.
 
> them, they were supported by extensive analysis.

To quote a really bad movie, "Show me the money". Give this list one single
example of a v4LL - unique security hole that can ONLY be fixed by disabling
v4LL. So far, you haven't done this, and seem to be raising these endless,
and from what can be seen, baseless accusations in what can reasonably seen
as an effort to torpedo the standard entirely, or make it just as hard to
use as DHCP, thereby making it redundant, and ensuring that nothing will
happen to improve this situation until IPv6 is ubiquitous, sometime after
2010.

> the requirements of RFC 2026.    so far it has refused to do so.

By your standards, DHCP is far worse.

> what planet are you from anyway?  this is complete garbage.

No Keith. You're wasting our time, and unless you can come up with specific,
technically verifiable facts, I'm going to ask that you lay off this entire
windmill-tilt of yours, so the people interested in getting work done can do
so.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 17 Dec 2002 10:20:41 -0800

> what planet are you from anyway?  this is complete garbage.

Is there a reason that you have to resort to insulting me instead of 
sticking to a technical argument?

My point is that a firewalls main function is to insulate a network. 
Whether the protected network has subnets on different links or not is 
irrelevant.

-josh

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 17 Dec 2002 13:38:38 -0500

> Whether the protected network has subnets on different links or not is

I'll bet you lunch at MacWorld that his next reply to you calls you a
corporate tool, and says that you shouldn't be listened to because you are
only parroting the desires of your evil corporate masters. ;-)

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, 17 Dec 2002 13:59:03 -0500

> sticking to a technical argument?

I've been making technical arguments for months.  I'm fed up with
having to respond to completely bogus assertions like

>> Firewalls usually block traffic between the outside world and the
>> local link.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 17 Dec 2002 14:11:32 -0500

>>> Firewalls usually block traffic between the outside world and the

Whoa...there's nothing completely bogus about it. One of the reasons you get
a firewall is to keep your stuff away from their stuff. You've haven't shown
one single verifiable v4LL - unique problem yet. You've insinutated, and
predicted, but you have yet to show us proof, and if the problem is *that*
great and immediate, then you should be able to do so easily.

Your inability to do this points to your arguments having little
non-emotional substance.

john

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

---

From: Alf Watt <[email-masked]>
Date: Tue, 17 Dec 2002 21:05:25 -0800

> the requirements of RFC 2026.    so far it has refused to do so.

Interestingly, RFC 2026 <http://www.ietf.org/rfc/rfc2026.txt> contains
mention of deployment into 'disruption sensitive environments' as well as
instructions for dealing with disputes of this nature. Unfortunately it
doesn't cover disruption of standards forum environments. See sections 4.1.2
and 6.5 for the complete text, here are two relevant quotes:

4.1.2  Draft Standard

    ...

   A Draft Standard is normally considered to be a final specification,
   and changes are likely to be made only to solve specific problems
   encountered.  In most circumstances, it is reasonable for vendors to
   deploy implementations of Draft Standards into a disruption sensitive
   environment.

6.5.1 Working Group Disputes

   An individual (whether a participant in the relevant Working Group or
   not) may disagree with a Working Group recommendation based on his or
   her belief that either (a) his or her own views have not been
   adequately considered by the Working Group, or (b) the Working Group
   has made an incorrect technical choice which places the quality
   and/or integrity of the Working Group's product(s) in significant
   jeopardy.  The first issue is a difficulty with Working Group
   process;  the latter is an assertion of technical error.  These two
   types of disagreement are quite different, but both are handled by
   the same process of review.

   A person who disagrees with a Working Group recommendation shall
   always first discuss the matter with the Working Group's chair(s),
   who may involve other members of the Working Group (or the Working
   Group as a whole) in the discussion.

   If the disagreement cannot be resolved in this way, any of the
   parties involved may bring it to the attention of the Area
   Director(s) for the area in which the Working Group is chartered.
   The Area Director(s) shall attempt to resolve the dispute.

   If the disagreement cannot be resolved by the Area Director(s) any of
   the parties involved may then appeal to the IESG as a whole.  The
   IESG shall then review the situation and attempt to resolve it in a
   manner of its own choosing.

As someone who is regularly using ipv4LL addresses, mDNS and other standards
provided this working group and has not observed a serious threat in
practice or theory. Carefully consider whether your analysis warrants the
vehemence we've observed or if a review of your thinking about the problem
is in order.

Best,
Alf

---

From: Alf Watt <[email-masked]>
Date: Fri, 20 Dec 2002 10:46:12 -0800

There are a couple of corrections I should make to the sentence below, at
the suggestion of a careful reader:

"As someone who regularly uses ipV4LL addresses and mDNS, which I hope this
working group will adopt as standards, I have not observed a serious threat
in practice or theory."

Best,
Alf

On 12/17/02 9:05 PM, "Alf Watt" <[email-masked]> wrote:

> provided this working group and has not observed a serious threat in practice
> or theory.