On Mon, 15 Dec 2003 07:37:23 +0100
Anthony G. Atkielski [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Linux could at least stand on the claim that it was implementing
the RFCs as written, and that the interoperability problem was
due to the other end failing to implement the RFCs.
Mark Smith writes:
So what purpose do RFCs serve if they aren't specific enough to be
complied with ?
They can easily be complied with and yet still be general. It's just
that there may be argument as to what constitutes perfect compliance or
lack thereof, and it isn't generally possible to
On Mon, 15 Dec 2003 07:37:23 +0100, Anthony G. Atkielski [EMAIL PROTECTED] said:
Microsoft knows better; apparently Linux developers and/or supporters do
not.
Microsoft knows better than the RFC?
or
Microsoft knows better than to implement RFCs so everybody can benefit?
I'm not sure that
[EMAIL PROTECTED] writes:
Microsoft knows better than the RFC?
No.
Microsoft knows better than to implement RFCs so everybody can benefit?
No.
I'm not sure that either parsing is what you want to be claiming.
Good.
I was saying that Microsoft knows better than to make claims such as you
On Mon, 15 Dec 2003 08:19:15 +0100
Anthony G. Atkielski [EMAIL PROTECTED] wrote:
Mark Smith writes:
So what purpose do RFCs serve if they aren't specific enough to be
complied with ?
They can easily be complied with and yet still be general. It's just
that there may be argument as to
Mark Smith writes:
Are you aware of the reason why certain words are capitalised in RFCs ?
Yes. I don't see the relevance of that here.
Implementations can be measured against the capitalised words in RFCs.
But there are many many ambiguous directives in RFCs, both with and
without
On Sun, 2003-12-14 at 23:34, Anthony G. Atkielski wrote:
jamal writes:
So the Linux decision was infact a very good one. An award of some form
is in order.
Maybe Microsoft will be inspired to do things the same way: it can
change its implementations in order to break 10% of all sites
- Original Message -
From: jamal [EMAIL PROTECTED]
To: Anthony G. Atkielski [EMAIL PROTECTED]
Cc: IETF Discussion [EMAIL PROTECTED]
Sent: Monday, December 15, 2003 6:12 AM
Subject: Re: Re[4]: www.isoc.org unreachable when ECN is used
On Sun, 2003-12-14 at 23:34, Anthony G. Atkielski
On Mon, 15 Dec 2003 10:22:24 +0100, Anthony G. Atkielski [EMAIL PROTECTED] said:
If a host has received an ECN-setup SYN packet, then it MAY send
an ECN-setup SYN-ACK packet. If a host has not received an ECN-setup
SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet.
See?
On 15-dec-03, at 14:03, Spencer Dawkins wrote:
Your definition of broken is a little off. I would think the broken
implementation is the one that misunderstood the definition.
reserved as i have been enlightened privately has been clearly
defined at IETF as:
a) Must be set to zero on
On Thu, 2003-12-11 at 16:05, Sally Floyd wrote:
One might hope that Linux implementors would make a better decision
next time around.
The linux implementation actually helped have a _lot_ of broken
devices fixed. I have ECN turned on always (for the last few years);
i find broken devices once
jamal writes:
So the Linux decision was infact a very good one. An award of some form
is in order.
Maybe Microsoft will be inspired to do things the same way: it can
change its implementations in order to break 10% of all sites around the
world, and when anyone complains, it can say that it
On Mon, 15 Dec 2003 05:34:53 +0100, Anthony G. Atkielski [EMAIL PROTECTED] said:
The main contention seems to be the system with the problem. If it's
Linux, it's not a bug, it's feature. If it's Microsoft, it's not a
feature, it's a bug.
Linux could at least stand on the claim that it was
[EMAIL PROTECTED] writes:
Linux could at least stand on the claim that it was implementing
the RFCs as written, and that the interoperability problem was
due to the other end failing to implement the RFCs.
The RFCs are not specific enough to support such a claim.
Feel free to point at
The IETF ones...
not supporting ECN
read previous e-mails...
Cheers
On Fri, 2003-12-12 at 18:46, Anthony G. Atkielski wrote:
Franck Martin writes:
The problem is that ISOC firewalls are not up to standards.
Whose standards?
Franck Martin
[EMAIL PROTECTED]
SOPAC, Fiji
GPG Key
On Fri, Dec 12, 2003 at 06:23:48AM +0100, Anthony G. Atkielski wrote:
But since ISOC's firewalls have not been updated, you won't be able to
get to their site from Linux.
Nonsense. I'm running Linux, several versions. I can get to the ISOC
site from all of them.
--
Kent Crispin
Franck Martin writes:
The IETF ones...
not supporting ECN
But ECN has not always been a standard. If all RFCs had been
simultaneously written forty years ago, it would be reasonable to speak
of one organization or another not respecting standards because it did
not adhere to a given RFC.
[EMAIL PROTECTED] writes:
Nonsense. I'm running Linux, several versions. I can
get to the ISOC site from all of them.
Then what is preventing others from doing so?
It all depends if ECN is turned on on linux. Some distro do it by default, some don't...
On Fri, 2003-12-12 at 19:03, [EMAIL PROTECTED] wrote:
On Fri, Dec 12, 2003 at 06:23:48AM +0100, Anthony G. Atkielski wrote:
But since ISOC's firewalls have not been updated, you won't be able to
get to
Except that a change from default values can be an excellent
indicator
that you are dealing with a software version different from what you
expected (and possibly incompatible).
I can't remember exactly where I saw the
definition, I've understood reserved fields to mean could change
in
On Fri, 12 Dec 2003, Franck Martin wrote:
The problem is that ISOC firewalls are not up to standards. Can
someone go to knock on ISOC door in Virginia and propose to help
them to solve this particular problem. And take some pictures too,
I'm curious to see what they really
On Thu, Dec 11, 2003 at 01:05:15PM -0800, Sally Floyd wrote:
A work-around for maintaining connectivity in the face of the broken
equipment was described in [Floyd00], and has been specified in RFC
3168 as a procedure that may be included in TCP implementations.
...
Some TCP
Theodore Ts'o writes:
To continue quoting from RFC 3360, there were some good reasons stated
in that document for why reasonable implementors might not choose to
implement the workaround:
* The work-arounds would result in ECN-capable hosts not responding
properly to the first valid
On Fri, 12 Dec 2003 21:01:09 +0100
Anthony G. Atkielski [EMAIL PROTECTED] wrote:
It sounds like ECN is pretty badly designed; I'm glad it wasn't my
idea.
Those are pretty bold statements.
http://www.icir.org/floyd/ecn.html
The above page seems to indicate that there was a lot of thought
John Kristoff writes:
Those are pretty bold statements.
Well, when something pops up in software I use that adds functionality
that I never wanted and breaks things that used to work, bold statements
are in order. If Microsoft had done this, someone would be calling for
a Constitutional
On Fri, Dec 12, 2003 at 09:01:09PM +0100, Anthony G. Atkielski wrote:
The problem is that RFC 3168 postdates all the RFCs that came before it,
and when something needs to be compatible with real-world systems that
are not all instantly and simultaneously upgraded, it needs to behave in
a way
Theodore Ts'o writes:
But in the case of ECN, most of the major sites on the
net have fixed their broken firewalls.
Why is ECN being deployed by default? Does it fix some problem that is
worse than rendering thousands of hosts inaccessible?
On 12-dec-03, at 22:24, Theodore Ts'o wrote:
Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls?
Path MTU disovery was implemented very poorly because implementations
tend expect certain functionality in routers, and usually don't recover
On Fri, 12 Dec 2003 22:19:49 +0100
Anthony G. Atkielski [EMAIL PROTECTED] wrote:
John Kristoff writes:
Those are pretty bold statements.
Well, when something pops up in software I use that adds functionality
that I never wanted and breaks things that used to work, bold statements
are in
Iljitsch;
On 12-dec-03, at 22:24, Theodore Ts'o wrote:
Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls?
Yes, PMTUD was badly designed.
Path MTU disovery was implemented very poorly because implementations
tend expect certain
Mark Smith writes:
I think you might be missing the point. ECN only breaks when used
with previous *bad* implementations of the relevant RFCs.
Perhaps my point isn't clear: ECN implementations prevent communication,
rather than enhance it. I don't see what advantage ECN provides, but it
has
If I have a system that does everything I require, I don't need
improvements.
So your currently requirements are exactly the same as all the other users of the
Internet ? I find it hard to believe that your requirements are exactly the same as
mine, and I'm only one of the other
Mark Smith writes:
So your currently requirements are exactly the same as all the
other users of the Internet?
No, but my situation is similar to theirs. They don't require
improvements if their systems do all they require, either.
I find it hard to believe that your requirements are
Masataka Ohta wrote:
Iljitsch;
On 12-dec-03, at 22:24, Theodore Ts'o wrote:
Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls?
Yes, PMTUD was badly designed.
No disagreement here.
Path MTU disovery was implemented very poorly because
Fred Templin;
It should have been designed into TCP over IPv4 and should have
never set don't fragment bit. TCP should be able to know that
packets are reassembled at the IP layer.
Yes - it would have been great if this was designed into the
architecture way back when. But it wasn't, so it would
Ole J Jacobsen writes:
Yep, works fine for me, Stef. Time to switch providers?
:-)
Time to disable ECN?
$ telnet www.isoc.org 80
Trying 206.131.249.182...
^C
: [EMAIL PROTECTED]; su
Password:
# ndd -set /dev/tcp tcp_ecn_permitted 0
# telnet www.isoc.org 80
The real issue is whether an ECN bit is reserved, or not reserved.
it's not reserved -- the ECN bits are assigned by RFC 3168
i.e. ECN is a proposed standard and the bits that it uses in the IP header
are fully assigned
Scott
[EMAIL PROTECTED] writes:
The problem is that the most common failure mode is *not*
getting an RST back, but getting NOTHING back because
some squirrely firewall between here and there is silently
dropping packets with bits it doesn't understand.
Ah ... that would definitely be a bug with
On Thu, 11 Dec 2003 14:47:03 EST, [EMAIL PROTECTED] (Scott Bradner) said:
The real issue is whether an ECN bit is reserved, or not reserved.
it's not reserved -- the ECN bits are assigned by RFC 3168
i.e. ECN is a proposed standard and the bits that it uses in the IP header
are fully
Yes, but if you're a firewall that stepped into a temporal stasis box
before 3168 was published, you're still thinking that the bits are
reserved,
woe be to new applications through such a firewall
Scott
I cannot believe it !
I raised this thing to ISOC more than a year ago!!! I told them in person at INET in Washington too...
They haven't done a dam thing since...
If you look on the Internet there is a list of organisations not ECN compliant, you will find ISOC entry.
How can such a
From: [EMAIL PROTECTED] (Scott Bradner)
Yes, but if you're a firewall that stepped into a temporal stasis box
before 3168 was published, you're still thinking that the bits are
reserved,
woe be to new applications through such a firewall
Yes, such junk no doubt has worse defects than
Scott Bradner writes:
woe be to new applications through such a firewall
It's important to understand that the Internet is not monolithic, and no
matter what the latest and greatest standards may be, there will always
be parts of the Net that run older software. Expecting the entire Net
to
On Fri, Dec 12, 2003 at 08:22:16AM +1200, Franck Martin wrote:
I cannot believe it !
I raised this thing to ISOC more than a year ago!!! I told them in
person at INET in Washington too...
They haven't done a dam thing since...
If you look on the Internet there is a list of
On Thu, Dec 11, 2003 at 09:06:06PM +0100, Anthony G. Atkielski wrote:
I also don't see why a firewall would drop packets just because reserved
bits are set, although I can see why it might be a configurable option
for the most paranoid users.
There are a lot of really dumb, dumb, dumb firewall
Yes, but if you're a firewall that stepped into a temporal stasis box
before 3168 was published, you're still thinking that the bits are
reserved, and that the Japanese haven't surrendered, and you should
fight on, discarding evil packets that have the reserved bits set
Actually, it has
Theodore Ts'o writes:
There are a lot of really dumb, dumb, dumb firewall authors out there,
that's why
Actually, Sally Floyd's explanation makes a lot more sense.
The dumb authors, I think, are those who built Linux implementations
that doggedly attempt to negotiate ECN and are
This exchange is rather interesting, since it seems to focus on my
system, which failed to get a useful connection at one point in time,
but did get one the next day when I tried it again, without making
any changes.
So, now it is argued that I need to fix my system. It has also been
stated
There are a lot of really dumb, dumb, dumb firewall authors out there,
that's why
Actually, Sally Floyd's explanation makes a lot more sense.
The dumb authors, I think, are those who built Linux implementations
that doggedly attempt to negotiate ECN and are unprepared for cases
where it
On Thu, Dec 11, 2003 at 03:48:44PM -0500, Theodore Ts'o wrote:
Check the archives, this gets raised periodically, and ISOC is simply
perenially unable to fix it. I think I raised some 12-18 months ago,
and there has still gotten no action by ISOC. I think this falls in
the so what else is
On Thu, Dec 11, 2003 at 10:10:44PM +0100, Anthony G. Atkielski wrote:
The dumb authors, I think, are those who built Linux implementations
that doggedly attempt to negotiate ECN and are unprepared for cases
where it does not work, even though it's unreasonable to assume that the
entire world
Mark Smith writes:
Firewalls could be considered to be performing QA for defined
protocol fields. I agree that reserved fields shouldn't be QA'ed for
their default values.
Except that a change from default values can be an excellent indicator
that you are dealing with a software version
Theodore Ts'o writes:
What Linux implemented was specifically what was specified by RFC
3168, no more no less.
What FreeBSD implemented actually works. Which is preferable?
The issue is whether or not intermediate hosts are
justified in dropping packets just because some
bits that were
Back to Reality:
The problem is that ISOC firewalls are not up to standards. Can someone
go to knock on ISOC door in Virginia and propose to help them to solve
this particular problem. And take some pictures too, I'm curious to see
what they really have...
This list is full of propeller heads,
Franck Martin writes:
The problem is that ISOC firewalls are not up to standards.
Whose standards?
55 matches
Mail list logo
