Randy Bush <[EMAIL PROTECTED]> writes:
> back office software
> ip and dns management software
> provisioning tools
> cpe
> measurement and monitoring and billing
>
> and, of course, backbone and aggregation equipment that can actually
> handle real ipv6 traffic flows with acls and chocolate syru
On 7-May-2008, at 17:07:06, Deepak Jain wrote:
> Many non-SP IT folks think they understand TCP, grudgingly accept
> UDP for DNS from external sources and think everything else is
> bollocks. Many *might* have a fit if they saw Microsoft accepting
> ICMPs because that seems inconsistent with
Nathan Anderson/FSR wrote:
> Nevertheless, the person I have been in contact with is naturally not
> the final decision-maker on this issue and is going to continue to pass
> the issue on up the chain of command for me. So although this issue is
> not over and I do not have a final verdict fr
Tomas L. Byrnes wrote:
> As far as who Iljitsch is, everyone misspeaks from time to time. Even
> those of us who have been at this for nearly 3 decades.
I was simply LOLing at the fact that you found it necessary to give him
a link to the NetHeaven article is all. ;-)
--
Nathan Anderson
First
Iljitsch van Beijnum wrote:
> The problem is in the direction from M$ to you, so you can't fix that
> from your end. I wonder if they've installed SP3 on their servers...
Ah, you are right. I re-read the section on black-hole detection in
http://technet.microsoft.com/en-us/library/bb878081.aspx
Sorry if I misunderstood what you were saying. I thought you said that
they couldn't have their cake and eat it too, as in protect against Ping
of death, AND do PMTUD.
As for those flames, well, that was a long time ago, in a valley not too
far from here ;-).
Can we have the 'net before the endle
On 7 mei 2008, at 23:20, Tomas L. Byrnes wrote:
> I was responding to his post that blocking or disabling PMTUD was the
> way to avoid the ping of death, which is False, nothing more, nothing
> less.
I never said that disabling PMTUD will get rid of the ping of death,
what I said was that if yo
This issue is now resolved for the time being. It went on for 2+ hours.
Sorry for the noise.
Regards,
Steve
S. Ryan wroteth on 5/7/2008 2:05 PM:
> I've called Charter and they deny they have an issue. I'm looking to
> speak to a Charter engineer who can specifically help with issues in the
I was responding to his post that blocking or disabling PMTUD was the
way to avoid the ping of death, which is False, nothing more, nothing
less.
As far as who Iljitsch is, everyone misspeaks from time to time. Even
those of us who have been at this for nearly 3 decades.
> -Original Messa
On 7 mei 2008, at 23:08, Nathan Anderson/FSR wrote:
> How so? Iljitsch is suggesting that ICMP blockers originate packets
> without DF set if they are going to block the ICMP messages that PMTUD
> needs in order to work in the first place. That's what (I think) he
> means by "disabling path MTU
Kevin Oberman wrote:
>> I agree with Iljitsch that it happens frequently, but I think I am
>> justified in expecting more than that from Microsoft. Anything less
>> would be unprofessional.
>
> And you would consider an organization that threatens someone who
> complains publicly about its obv
Tomas L. Byrnes wrote:
> Some Edumacation on the topic is here:
You do know who it is that you are responding to, right? :)
http://www.oreillynet.com/pub/au/970
--
Nathan Anderson
First Step Internet, LLC
[EMAIL PROTECTED]
___
NANOG mailing list
NAN
Tomas L. Byrnes wrote:
> The remedy you have below is NOT the only one, and is, in fact, a
> non-sequitur in this case.
How so? Iljitsch is suggesting that ICMP blockers originate packets
without DF set if they are going to block the ICMP messages that PMTUD
needs in order to work in the firs
I've called Charter and they deny they have an issue. I'm looking to
speak to a Charter engineer who can specifically help with issues in the
Southern Oregon service area.
Multiple customers cannot check mail on 110 or use port 25 or 587.
Looks like a loop:
traceroute to 204.16.46.136 (204.16
Tomas L. Byrnes wrote:
> I'm not sure what the issue is here.
>
> Just about every modern firewall I've used has an option to enable PMTU
> on interfaces, while blocking all other ICMP.
>
> Is MS not running something manufactured in the last 10 years at their
> perimeter?
Not sure, but you ac
Some Edumacation on the topic is here:
http://www.netheaven.com/pmtu.html
> -Original Message-
> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 07, 2008 1:35 PM
> To: Michael Sinatra
> Cc: [EMAIL PROTECTED]
> Subject: Re: [NANOG] Microsoft.com PMTUD black h
The remedy you have below is NOT the only one, and is, in fact, a
non-sequitur in this case.
PMTUD uses the DF (for Don't_Fragment) bit, and works by getting an ICMP
Fragmentation needed response from the hop on the path where the packet
is too large, not a fragmentation and forward, so the union
On 7 mei 2008, at 21:46, Michael Sinatra wrote:
>> MS does in fact block _all_ ICMP
>> at the edge of their network, that they are aware that this will in
>> fact
>> break PMTUD, and that they have no current plans to change this
>> practice
>> which they have implemented in the interest of se
Nathan Anderson/FSR wrote:
> Here is a brief update on the situation:
>
> I have been in contact with someone at Microsoft's service operations
> center, who has confirmed for me that MS does in fact block _all_ ICMP
> at the edge of their network, that they are aware that this will in fact
> b
I'm not sure what the issue is here.
Just about every modern firewall I've used has an option to enable PMTU
on interfaces, while blocking all other ICMP.
Is MS not running something manufactured in the last 10 years at their
perimeter?
> -Original Message-
> From: Nathan Anderson/FSR
[EMAIL PROTECTED] wrote:
> The usual case where you get screwed over is when the router trying to toss
> the ICMP FRAG NEEDED is *behind* the ICMP-munching firewall. And in case (2),
> you still can't assume that path MTU == local MTU, because your local MTU is
> likely 1500, and the fragging rou
Here is a brief update on the situation:
I have been in contact with someone at Microsoft's service operations
center, who has confirmed for me that MS does in fact block _all_ ICMP
at the edge of their network, that they are aware that this will in fact
break PMTUD, and that they have no curre
Iljitsch van Beijnum wrote:
> No. This would add significant delay because you'd have to give the
> other side enough time to respond to the large packet (also sending a
> large packet on something like GPRS/EDGE is a waste of bandwidth and
> battery power) while if there is ICMP filtering, the
Thus spake "Nathan Anderson/FSR" <[EMAIL PROTECTED]>
> A member of Microsoft's GNS network escalations team saw my
> postings on NANOG about this issue and took offense at my use
> of this forum to raise this issue with them, and criticized me as
> being unprofessional and lacking in business acume
All;
I am having a bit of difficulty resolving a Google matter. I am
hoping to get pointed in the right direction by someone from Google.
Thanks
--
NOTICE: This email message is for the sole use of the intended recipient(
Glen Turner wrote:
> Amazing. A fine case study of a person in customer contact undoing the
> work of millions of dollars in PR. Whatever you say about Steve Ballmer
> he's a great sales person at heart. He must despair at some of his staff.
>
The rest of us however, despair at having to support
On Tue, May 06, 2008 at 06:12:42PM -0700, Nathan Anderson/FSR wrote:
> A member of Microsoft's GNS network escalations team saw my postings on
> NANOG about this issue and took offense at my use of this forum to raise
> this issue with them, and criticized me as being unprofessional and
> lackin
I will be out of the office starting 05/07/2008 and will not return until
05/12/2008.
___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:
> Many years ago I had occasion to terminate dial-up service over L2TP
> from modem pools operated by a service provider who shall remain
> nameless to protect the guilty. This service had the unfortunate
> tendency to drap all packets larger
On 07/05/2008, at 4:42 PM, Glen Turner wrote:
> Amazing. A fine case study of a person in customer contact undoing the
> work of millions of dollars in PR.
I wouldn't worry too much about it, Glen. My observation is that the
millions of dollars in PR isn't working very well either :-)
- mark
Nathan Anderson/FSR wrote:
> A member of Microsoft's GNS network escalations team saw my postings on
> NANOG about this issue and took offense at my use of this forum to raise
> this issue with them, and criticized me as being unprofessional and
> lacking in business acumen.
Hang on a tick. Are
31 matches
Mail list logo
