> In the UK two of the largest ISPs - BT Internet and Freeserve - have
> ECN-blocking
> firewalls. So does theregister.co.uk for that matter. If I enable ECN
> I lose
> the ability to send emails to a huge percentage of the people on the
> mailing lists
> that run on my machine.
>
> These ISPs
> > So, no reason for a firewall author to check these bits.
>
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.
If you care about such things you run pure proxy. A packet fil
> > RFC793, where is lists the unused flag bits as "reserved".
> > That is pretty clear to me. It just has to say that
> > they are reserved, and that is what it does.
> >
>
> Is the definition of "reserved" defined anywhere? In a lot of specs,
> "reserved" means MBZ.
>
> Note, that I'm not a
Chris Meadors wrote:
>
> On Fri, 26 Jan 2001, Daniel Chemko wrote:
>
> > Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
> > microsoft.com...
>
> It's down, ha ha, Microsoft is down! I'm joking of course. But you don't
> know how many times my techs have told m
"Randal, Phil" wrote:
>
> James Sutherland wrote:
>
> > Except you can't retry without ECN, because DaveM wants to do
> > a Microsoft and force ECN on everyone, whether they like it
> > or not. If ECN is so wonderful, why doesn't anybody actually
> > WANT to use it anyway?
>
> And there's the r
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
>
> We are not talking about attacks here, we are t
Dax Kelson wrote:
> Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
>
> > Does ECN provide perceived benefits to the node using it?
>
> Why are you even making suggestions when you haven't even read the RFC?
>
> It seems that knowing what ECN is would be prerequisite to engaging in
> dis
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
> We are not talking about attacks here, we are tal
On Sat, 27 Jan 2001, Gregory Maxwell wrote:
> On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
> > On Sat, 27 Jan 2001, David Schwartz wrote:
> >
> > >
> > > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > > policy management. In such a situation
On Sun, Jan 28, 2001 at 02:10:25AM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote:
> > It's this kind of ignorance that makes the internet a less secure and stable
> > place.
>
> You have obviously absolutely no idea what you are talking about. Perio
> On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > > Firewalling should be implemented on the hosts, perhaps with
> > > centralized
> > > policy management. In such a situation, there would be no
> > > reason to filter
> > > on funny IP options.
> > That's madness. If you hav
Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
> Does ECN provide perceived benefits to the node using it?
Why are you even making suggestions when you haven't even read the RFC?
It seems that knowing what ECN is would be prerequisite to engaging in
discussion about it.
Dax
-
To unsub
In message <[EMAIL PROTECTED]> you write:
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.
If they were `insanely paranoid' they wouldn't just be doing packet
filtering. The
On Sat, 27 Jan 2001, Frank v Waveren wrote:
> Why? Why not just zero them, and get both security and compatibility...
>
the problem is that you don't know what they mean, just zeroing them may
break things (how will the sender know that you zeroed them).
David Lang
-
To unsubscribe from this
On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
> On Sat, 27 Jan 2001, David Schwartz wrote:
>
> >
> > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > policy management. In such a situation, there would be no reason to filter
> > > on funny IP o
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
>
> That's madness. If you have to implement y
On Sat, 27 Jan 2001, David Schwartz wrote:
>
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
>
> That's madness. If you have to implement your firewalling o
> Firewalling should be implemented on the hosts, perhaps with centralized
> policy management. In such a situation, there would be no reason to filter
> on funny IP options.
That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to run
On Sat, Jan 27, 2001 at 08:58:51PM +0100, Jamie Lokier wrote:
[snip]
> > I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
> > on 'hide nat'ed connections. This causes unreasonable stalls for users on
> > SACK enabled clients. Not cool.
>
> If both SACK and SACK_PERMITTED
Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
>
> Eeek! NO NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that wouldn't have worked that way..
>
> I think
On Sat, Jan 27, 2001 at 02:20:32PM -0500, Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
> Eeek! NO NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that would
On Sat, Jan 27, 2001 at 07:18:09PM +0100, Frank v Waveren wrote:
> On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
> > Practice being really, really paranoid. Think: You're designing a
> > firewall; you've got some reserved bits, currently unused; any future code
> > that uses them
In article <[EMAIL PROTECTED]> you wrote:
>> Think of yourself as a firewall author now. You come across this, and
>> go, "these bits aren't used now; this means noone should be setting
>> them. I have no guarantee that anything in the future isn't going to use
>> these bits for something that i
On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
> Practice being really, really paranoid. Think: You're designing a
> firewall; you've got some reserved bits, currently unused; any future code
> that uses them could behave in completely arbitrary and insecure ways,
> for all you kno
H. Peter Anvin wrote:
> "David S. Miller" wrote:
> >
> > H. Peter Anvin writes:
> > > Last I communicated with them, I looked for a reference like that in the
> > > standards RFCs so I could quote chapter and verse at the Hotmail people,
> > > but I couldn't find it.
> >
> > RFC793, where is
On Fri, Jan 26, 2001 at 04:59:13PM -0500, Michael H. Warfield wrote:
> No... Microsoft learned, just two days ago, something that has
> been part of best practices for over 15 years. Do NOT put all of your
> DNS servers on the same network! The technical error may have triggered
> the mel
> Hotmails failing machines, for example, send RST packets back when
> they see ECN. Ignoring valid TCP RST frames is unacceptable and
> Linux will not do that as long as I am maintaining it.
Whadda word!
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
god...
-
To uns
> Every single connection to ECN-broken sites would work as normal - it
> would just take an extra few seconds. Instead of "Hotmail doesn't
> work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
> use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
I thin
> "David" == David Wagner <[EMAIL PROTECTED]> writes:
David> Practice being really, really paranoid. Think: You're
David> designing a firewall; you've got some reserved bits,
David> currently unused; any future code that uses them could
David> behave in completely arbitrary a
Helge Hafting wrote:
>So, no reason for a firewall author to check these bits.
You don't think like a firewall designer! :-)
Practice being really, really paranoid. Think: You're designing a
firewall; you've got some reserved bits, currently unused; any future code
that uses them could behave
>> We may be right, "they" may be wrong, but in the real world
>> arrogance rarely wins anyone friends.
>
> So you also turn of PMTU and just set the MTU to 200 bytes
> because broken firewalls may drop ICMP ?
Nah, you don't need to go that low. Try 1200 or 1400 instead.
-
To unsubscribe from t
Dominik Kubla wrote:
>
> On Fri, Jan 26, 2001 at 04:27:07PM +0100, Jamie Lokier wrote:
> ...
> > Yeah, Apache and Samba establish _outgoing_ connections with fixed
> > source ports Not!
>
> Oops! Of course. Brain-damage on my part. Now where is that dammned
> brown paper bag...
>
ftpd and
On Fri, Jan 26, 2001 at 01:52:26PM -0800, Stuart Lynne wrote:
> In article <[EMAIL PROTECTED]>,
> James Sutherland <[EMAIL PROTECTED]> wrote:
> >On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> >Except you can't retry without ECN, because DaveM wants to do a Microsoft
> >and force ECN on everyone
In article <[EMAIL PROTECTED]>,
James Sutherland <[EMAIL PROTECTED]> wrote:
>On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
>Except you can't retry without ECN, because DaveM wants to do a Microsoft
>and force ECN on everyone, whether they like it or not. If ECN is so
No, he just wants them to i
"Randal, Phil" wrote:
> James Sutherland wrote:
>
> > Except you can't retry without ECN, because DaveM wants to do
> > a Microsoft and force ECN on everyone, whether they like it
> > or not. If ECN is so wonderful, why doesn't anybody actually
> > WANT to use it anyway?
>
> And there's the rub.
On Fri, 26 Jan 2001 15:29:51 +, James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.
Who's forcing? You have to *SPECIFICALLY* enable it in the config,
ignoring the notice in the help text
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in the
On Fri, 26 Jan 2001, Daniel Chemko wrote:
> Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
> microsoft.com...
It's down, ha ha, Microsoft is down! I'm joking of course. But you don't
know how many times my techs have told me that. It's either that, or
something
Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
microsoft.com...
James Sutherland wrote:
> On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
>
> > On 2001-01-26T16:04:03,
> >"Randal, Phil" <[EMAIL PROTECTED]> said:
> >
> > > We may be right, "they" may be wrong,
On Fri, Jan 26, 2001 at 06:37:12PM +, Henning P. Schmiedehausen wrote:
...
> Cisco: If I buy a _new_ PIIX oder LDIR today, do I get an ECN capable
> IOS or not? If not, will my CCNA know about this and upgrade my Box
> before deploying?
That cisco box is called PIX -- PIIX sounds like som
[EMAIL PROTECTED] (Tony Hoyle) writes:
> These ISPs will *not* change simply because 1% of Linux users
> complain at them. They have been contacted about this and they know
> of the problem. I doubt they care.
Trust me, they care. Every Admin cares. They have, however, to convice
their superio
[EMAIL PROTECTED] (Chris Ricker) writes:
>> If ECN is so wonderful, why doesn't anybody actually WANT to use it
>> anyway?
>Lots of people do. Lots of other people (such as, in this case, hotmail)
>will never upgrade their software until the groundswell of complaints is
>more expensive than the
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in the
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled, would be
> > acceptable.
>
> Using a different source port number, even.
> As David pointed out, it is "reserved for future use - you must set
> these bits to zero and not use it _for your own purposes_. For non-rfc
> use of these bits _will_ break something the day we start using them
> for something useful.
>
> So, no reason for a firewall author to check these bi
"Adam J. Richter" wrote:
>
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in the RFC "must be zer
I am surprised that anyone is seriously considering denying
service to sites that do not implement an _experimental_ facility
and have firewalls that try to play things safe by dropping packets
which have 1's in bit positions that in the RFC "must be zero."
If Microsoft were to do
At Fri, 26 Jan 2001 15:08:21 + (GMT),
James Sutherland <[EMAIL PROTECTED]> wrote:
>
> On Fri, 26 Jan 2001, David S. Miller wrote:
> > James Sutherland writes:
> > > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > > RST packet as "go away and never ever send tra
In article <[EMAIL PROTECTED]>,
Randal, Phil <[EMAIL PROTECTED]> wrote:
>Because if we do try to force it, the response which will come
>back won't be "Linux is wonderful, it conforms to the standards".
>It will be "Linux sucks, we can't connect to xyz.com with it (or
>we can't connect because to
Lars Marowsky-Bree wrote:
>
> So you also turn of PMTU and just set the MTU to 200 bytes because broken
> firewalls may drop ICMP ?
That doesn't affect huge numbers of websites.
In the UK two of the largest ISPs - BT Internet and Freeserve - have
ECN-blocking
firewalls. So does theregister.co.
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T16:04:03,
>"Randal, Phil" <[EMAIL PROTECTED]> said:
>
> > We may be right, "they" may be wrong, but in the real world
> > arrogance rarely wins anyone friends.
>
> So you also turn of PMTU and just set the MTU to 200 bytes becau
On 2001-01-26T16:04:03,
"Randal, Phil" <[EMAIL PROTECTED]> said:
> We may be right, "they" may be wrong, but in the real world
> arrogance rarely wins anyone friends.
So you also turn of PMTU and just set the MTU to 200 bytes because broken
firewalls may drop ICMP ?
Sincerely,
Lars Marow
Jamie Lokier wrote:
>
> Lars Marowsky-Bree wrote:
> > First, you are ignoring a TCP_RST, which means "stop trying".
>
> That's why we stop when we receive the second TCP RST.
> It's just like dropping due to congestion, which is of course perfectly
> safe in moderation.
>
No, you can't issue m
James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do
> a Microsoft and force ECN on everyone, whether they like it
> or not. If ECN is so wonderful, why doesn't anybody actually
> WANT to use it anyway?
And there's the rub. Whether ECN is wonderful or not, at
On Fri, 26 Jan 2001, James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.
Don't be absurd. It's a compile-time option that nobody, not even Dave
Miller, is forcing you to compile into your k
Lars Marowsky-Bree wrote:
> If connect() suddenly did two connection attempts instead of one, just how
> many timeouts might that break?
Timeouts are already broken by applications that repeatedly call
connect(). You'd get better timeout behaviour by letting the kernel
enforce backoff.
> > Why?
Dominik Kubla wrote:
>
> > Applications tend not to. Do we care about those that do?
>
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...
They dont connect but listen on these specified ports.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T15:08:21,
>James Sutherland <[EMAIL PROTECTED]> said:
>
> > Obviously. The connection is now dead. However, trying to make a new
> > connection with different settings is perfectly reasonable.
>
> No.
>
> If connect() suddenly
Dominik Kubla wrote:
> On Fri, Jan 26, 2001 at 04:03:42PM +0100, Jamie Lokier wrote:
> ...
> > Applications tend not to. Do we care about those that do?
>
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...
Yeah, Apache and Samba establish _outgoing_ connections with fix
David S. Miller wrote:
> > Does ECN provide perceived benefits to the node using it?
>
> Yes, endpoints and intermediate routers can tell the TCP sender about
> congestion instead of TCP having to guess about it based upon observed
> packet drop.
>
> It is a major enhancement to performance ove
Jamie Lokier writes:
> Does ECN provide perceived benefits to the node using it?
Yes, endpoints and intermediate routers can tell the TCP sender about
congestion instead of TCP having to guess about it based upon observed
packet drop.
It is a major enhancement to performance over any WAN.
The
On 2001-01-26T15:08:21,
James Sutherland <[EMAIL PROTECTED]> said:
> Obviously. The connection is now dead. However, trying to make a new
> connection with different settings is perfectly reasonable.
No.
If connect() suddenly did two connection attempts instead of one, just how
many timeouts
On Fri, 26 Jan 2001, David S. Miller wrote:
> James Sutherland writes:
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled,
Lars Marowsky-Bree wrote:
> First, you are ignoring a TCP_RST, which means "stop trying".
That's why we stop when we receive the second TCP RST.
It's just like dropping due to congestion, which is of course perfectly
safe in moderation.
> You would have to retry a connection with a new source p
David S. Miller wrote:
> People must fix their firewalls, there is no other way to
> fix the problem and get ECN properly deployed. I'm ceasing
> conversation on this thread from this point forward.
I suggest the ISPs fix their firewalls to strip ECN coming from their
Linux clients, providing a
Lars Marowsky-Bree writes:
> That would mean that the people worried about this should write a
> wrapper-library for the connect() call, and maybe add a no_ecn flag to a
> socket, and leave the kernel alone.
I'm not adding a no_ecn option for sockets. See my response
to Matti Aarnio earlier
On 2001-01-26T06:39:36,
"David S. Miller" <[EMAIL PROTECTED]> said:
> The RST frame does not indicate why it happened, so you may not intuit
> the reason, "retry" the connection, or anything else like that. It
> means connection failed, and we must return error from connect().
>
> Nothing el
On 2001-01-26T13:44:53,
James Sutherland <[EMAIL PROTECTED]> said:
> > > A delayed retry without ECN might be a good compromise...
> > _NO!_
> Why? As it stands, I have ECN disabled. It's staying disabled until I know
> it won't degrade my Net access.
First, you are ignoring a TCP_RST, wh
Jamie Lokier writes:
> Ignore only _one_ RST frame (the first one)
Hmmm... let me say it for the hundreth time.
Valid RST frames cannot be ignored under any circumstances.
It is a full failure, period.
The RST frame does not indicate why it happened, so you may not intuit
the reason, "retry"
David S. Miller wrote:
> The connection failed, RST means connection reset. RST means all
> state is corrupt and this connection must die. It cannot be
> interpreted in any other way.
Therefore build a new connection, using a new source port if necessary.
-- Jamie
-
To unsubscribe from this li
David S. Miller wrote:
> > Every single connection to ECN-broken sites would work as normal - it
> > would just take an extra few seconds. Instead of "Hotmail doesn't
> > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
> > use Yahoo". A few million of those, and sudd
"Jeremy M. Dolan" <[EMAIL PROTECTED]> writes:
> RFC1812 Requirements for IP Version 4 Routers
RFC 1812 mandates routing of IP packets with reserved flags, but not
for TCP packets.
> RFC2979 Behavior of and Requirements for Internet Firewalls
>
> The last one seems i
James Sutherland wrote:
> I was not suggesting ignoring these. OTOH, there is no reason to treat an
> RST packet as "go away and never ever send traffic to this host again" -
> i.e. trying another TCP connection, this time with ECN disabled, would be
> acceptable.
Using a different source port nu
James Sutherland writes:
> I was not suggesting ignoring these. OTOH, there is no reason to treat an
> RST packet as "go away and never ever send traffic to this host again" -
> i.e. trying another TCP connection, this time with ECN disabled, would be
> acceptable.
The connection failed, RST
On Fri, 26 Jan 2001, David S. Miller wrote:
>
> James Sutherland writes:
> > A delayed retry without ECN might be a good compromise...
> >
> > Every single connection to ECN-broken sites would work as normal - it
> > would just take an extra few seconds. Instead of "Hotmail doesn't
> > wor
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T11:40:36,
>James Sutherland <[EMAIL PROTECTED]> said:
>
> > A delayed retry without ECN might be a good compromise...
>
> _NO!_
Why? As it stands, I have ECN disabled. It's staying disabled until I know
it won't degrade my
James Sutherland writes:
> A delayed retry without ECN might be a good compromise...
>
> Every single connection to ECN-broken sites would work as normal - it
> would just take an extra few seconds. Instead of "Hotmail doesn't
> work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo i
On 2001-01-26T11:40:36,
James Sutherland <[EMAIL PROTECTED]> said:
> A delayed retry without ECN might be a good compromise...
_NO!_
Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
-
To unsubscribe from this lis
On Fri, 26 Jan 2001, David S. Miller wrote:
>
> Matti Aarnio writes:
> > But could you nevertheless consider supplying a socket option for it ?
> > By all means default it per sysctl, but allow clearing/setting by
> > program too.
>
> No, because then people will do the wrong thing.
>
Matti Aarnio writes:
> But could you nevertheless consider supplying a socket option for it ?
> By all means default it per sysctl, but allow clearing/setting by
> program too.
No, because then people will do the wrong thing.
They will create intricate "ECN black lists" and make
their
On Thu, Jan 25, 2001 at 05:30:29PM -0800, David S. Miller wrote:
...
> Thirdly, it was widely discussed by the ECN reserachers on how to
> "detect ECN blackholes" sort to speak. All such schemes suggested
> we unusable, it is not doable without impacting performance _and_
> violating existing RFC
"H. Peter Anvin" wrote:
>
> "David S. Miller" wrote:
> >
> > It says "reserved for future use, must be zero".
> >
> > I think the descrepency (and thus what the firewalls are doing) comes
> > from the ambiguous "must be zero". I cannot fathom the RFC authors
> > meaning this to be anything other
In article <[EMAIL PROTECTED]> you wrote:
> RFC793, where is lists the unused flag bits as "reserved".
> That is pretty clear to me. It just has to say that
> they are reserved, and that is what it does.
Actually I read somehwre "must be 0", but I am afraid dont know where anymore.
anyway, it do
On Thu, 25 Jan 2001 18:10:21 +, David S. Miller wrote:
> It says "reserved for future use, must be zero".
While I've not checked the context yet, this seems to be terrible
wording. The context doesn't direct this towards hosts constructing
packets? What is the 'It' you refer to, the TCP RFC?
> "David" == David S Miller <[EMAIL PROTECTED]> writes:
David> It says "reserved for future use, must be zero".
Poor choice of wording.
If I was implementing this, I would assume that any packet with a
non-zero value is illegal by this RFC, and act accordingly.
I would assume that this
On Thu, Jan 25, 2001, David S. Miller <[EMAIL PROTECTED]> wrote:
>
> H. Peter Anvin writes:
> > > RFC793, where is lists the unused flag bits as "reserved".
> > > That is pretty clear to me. It just has to say that
> > > they are reserved, and that is what it does.
> > >
> >
> > Is the d
"David S. Miller" wrote:
>
> It says "reserved for future use, must be zero".
>
> I think the descrepency (and thus what the firewalls are doing) comes
> from the ambiguous "must be zero". I cannot fathom the RFC authors
> meaning this to be anything other than "must be set to zero by current
>
H. Peter Anvin writes:
> > RFC793, where is lists the unused flag bits as "reserved".
> > That is pretty clear to me. It just has to say that
> > they are reserved, and that is what it does.
> >
>
> Is the definition of "reserved" defined anywhere? In a lot of specs,
> "reserved" means
"David S. Miller" wrote:
>
> H. Peter Anvin writes:
> > Last I communicated with them, I looked for a reference like that in the
> > standards RFCs so I could quote chapter and verse at the Hotmail people,
> > but I couldn't find it.
>
> RFC793, where is lists the unused flag bits as "reserve
H. Peter Anvin writes:
> Last I communicated with them, I looked for a reference like that in the
> standards RFCs so I could quote chapter and verse at the Hotmail people,
> but I couldn't find it.
RFC793, where is lists the unused flag bits as "reserved".
That is pretty clear to me. It just
"David S. Miller" wrote:
>
> Secondly, the RFCs are pretty clear that the bits in question used for
> ECN are _reserved_ and to be ignored by implementations. That means
> to not be interpreted, and more importantly not used to discard
> packets.
>
Last I communicated with them, I looked for a
H. Peter Anvin writes:
> I do think they have a point, though; ECN is listed as an
> experimental standard at IETF, and I do think that it's not exactly
> fair to *require* everyone to use it until it is standards-track.
> It would be another thing if Linux could turn it off on a
> per-conne
Hi,
At 01:06 AM 25/01/2001 -0800, David S. Miller wrote:
>Juri Haberland writes:
> > Forget it. I mailed them and this is the answer:
> >
> > "As ECN is not a widely used internet standard, and as Cisco does not
> > have a stable OS for their routers that accepts ECN, anyone attempting
> > t
Followup to: <[EMAIL PROTECTED]>
By author:Jeremy Hansen <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perha
In article <[EMAIL PROTECTED]> you wrote:
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perhaps they should look into supporting it, or
> should I not waste my breath
Juri Haberland writes:
> Forget it. I mailed them and this is the answer:
>
> "As ECN is not a widely used internet standard, and as Cisco does not
> have a stable OS for their routers that accepts ECN, anyone attempting
> to access our site through a gateway or from a computer that uses EC
Jeremy Hansen wrote:
>
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perhaps they should look into supporting it, or
> should I not waste my breath and echo 0 > /pro
97 matches
Mail list logo
