On Thu, Mar 7, 2019 at 8:33 PM Stephen Satchell wrote:
> OK, OK, so I will continue to rate-limit both, to reasonably high limits
> on the order of 250/second. Absent a DoS, it allows network operators
> to use these tools as they should.
>
> My logs show no harm except to attack traffic.
>
>
On 3/7/19 8:10 AM, Saku Ytti wrote:
> So why not disable ICMP Echo and UDP traceroute, those kids using
> network diagnostics don't need them.
>
> For clue constrained audience fear will always be the most compelling
> argument.
OK, OK, so I will continue to rate-limit both, to reasonably high
On Thu, Mar 7, 2019 at 6:06 PM wrote:
> Sure I get it it's a very valid and a noble point,
> But what you're asking is let it break (yes potentially -it's just
> probability until it happens) for 1000s of subs just so that one kiddo has a
> working niche feature, I can already see what board
Hey Saku,
> From: Saku Ytti
> Sent: Thursday, March 7, 2019 3:29 PM
>
> On Thu, Mar 7, 2019 at 5:19 PM wrote:
>
> > From past experience my assumptions would be more along the lines of if
> it's not mainstream there's a higher likelihood that it might trigger
> exceptions
> in code.
>
> My
On Thu, Mar 7, 2019 at 5:19 PM wrote:
> From past experience my assumptions would be more along the lines of if it's
> not mainstream there's a higher likelihood that it might trigger exceptions
> in code.
My point is, let it break. Don't pre-emptively drop things that you
don't know to be
> From: Saku Ytti
> Sent: Tuesday, March 5, 2019 3:00 PM
>
> On Tue, Mar 5, 2019 at 4:54 PM wrote:
>
> > Let me play a devil's advocate here, the above statement begs a question
> then, how do you know all that is harmful would you test for every possible
> extension and hw/sw permutation?
> >
On 6/Mar/19 08:38, Fernando Gont wrote:
>
> RFC4821 seems to signal that the IETF has given up in making ICMP-based
> PMTUD work, and aims at a (mostly) ICMP-free PMTUD.
As much as I hate to admit it, I think this is a more realistic approach.
Mark.
On 6/Mar/19 08:29, Mark Andrews wrote:
> Make a big enough stink and it will get fixed. People just don’t make enough
> of
> a stink. Use social media. None of the companies with broken firewalls
> really
> want their idiotic practices pointed out in public. Start doing so every time
>
On 6/3/19 03:29, Mark Andrews wrote:
>
>
>> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote:
>>
>> On 6/3/19 01:09, Mark Andrews wrote:
>>>
>>>
On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
On 3/3/19 18:04, Mark Andrews wrote:
> There are lots of IDIOTS out there that BLOCK
> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote:
>
> On 6/3/19 01:09, Mark Andrews wrote:
>>
>>
>>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
>>>
>>> On 3/3/19 18:04, Mark Andrews wrote:
There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
getting
On 6/3/19 01:09, Mark Andrews wrote:
>
>
>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
>>
>> On 3/3/19 18:04, Mark Andrews wrote:
>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>>> getting
>>> back to the TCP servers. There are also IDIOTS that deploy load
> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
>
> On 3/3/19 18:04, Mark Andrews wrote:
>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>> getting
>> back to the TCP servers. There are also IDIOTS that deploy load balancers
>> that
>> DO NOT LOOK INSIDE ICMP
On Tue, Mar 5, 2019 at 07:15 Rich Kulawiec wrote:
> On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote:
> > ICMP is NOT optional.
>
> I've pointed folks at this for years:
>
> ICMP Packet Filtering v1.2
> http://www.cymru.com/Documents/icmp-messages.html
>
> ---rsk
>
On 3/3/19 20:16, Mark Andrews wrote:
>
>
>> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote:
>>
>> On 3/3/19 1:04 PM, Mark Andrews wrote:
>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>>> getting
>>> back to the TCP servers.
>>
>> For those of us who are in the
On 3/3/19 18:04, Mark Andrews wrote:
> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
> getting
> back to the TCP servers. There are also IDIOTS that deploy load balancers
> that
> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
> back
On 3/3/19 16:57, Jeroen Massar wrote:
> On 2019-03-03 20:13, Mark Tinka wrote:
>>
>>
>> On 3/Mar/19 18:05, Jeroen Massar wrote:
>>
>>> IPv6 requires a minimum MTU of 1280.
>>>
>>> If you cannot transport it, then the transport (the tunnel in this case)
>>> needs to handle the fragmentation of
On Tue, Mar 5, 2019 at 4:54 PM wrote:
> Let me play a devil's advocate here, the above statement begs a question
> then, how do you know all that is harmful would you test for every possible
> extension and hw/sw permutation?
> So there would be 3 sets (though lines might be blurred) known
> From: NANOG On Behalf Of Saku Ytti
>
> Hey Rich,
>
> > I've pointed folks at this for years:
> > ICMP Packet Filtering v1.2
> > http://www.cymru.com/Documents/icmp-messages.html
>
>
> To me, the correct pattern is here is to deny things you know to be harmful
> and can
Hey Rich,
> I've pointed folks at this for years:
> ICMP Packet Filtering v1.2
> http://www.cymru.com/Documents/icmp-messages.html
To me this seems anti-pattern. It seems it was written on basis of
'what we know we allow, what we don't know we deny'. With assumption
that ICMP
On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote:
> ICMP is NOT optional.
I've pointed folks at this for years:
ICMP Packet Filtering v1.2
http://www.cymru.com/Documents/icmp-messages.html
---rsk
On 2019-03-03 20:13, Mark Tinka wrote:
>
>
> On 3/Mar/19 18:05, Jeroen Massar wrote:
>
>> IPv6 requires a minimum MTU of 1280.
>>
>> If you cannot transport it, then the transport (the tunnel in this case)
>> needs to handle the fragmentation of packets of 1280 down to whatever does
>> fit in
On 2019-03-03 11:31, Mark Tinka wrote:
[..]
> Across the 6-in-4 tunnel, the tested MTU is 1,232 for IPv6.
IPv6 requires a minimum MTU of 1280.
If you cannot transport it, then the transport (the tunnel in this case) needs
to handle the fragmentation of packets of 1280 down to whatever does fit
On Mon, Mar 4, 2019 at 10:02 AM Mark Tinka wrote:
> > Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do
> > have a very specific and motivated reason to block some types.
> > I would even go as far as "allow all icmp from any to any" (and if possible
> > as the first
On 4/Mar/19 09:12, Radu-Adrian Feurdean wrote:
> Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do
> have a very specific and motivated reason to block some types.
> I would even go as far as "allow all icmp from any to any" (and if possible
> as the first firewall
On 4/Mar/19 03:17, Harald Koch wrote:
>
> (Can I join the choir too? :)
But of course :-)...
Mark.
On Sun, Mar 3, 2019, at 22:05, Mark Andrews wrote:
> admins who don’t know how IP is supposed to work.
You do realise that in "corporate world" that's more than 80% of network admins
? Some of them even make it to "audit" companies, so they can screw a company
with clueful admins with their
On Sun, Mar 3, 2019, at 17:35, Stephen Satchell wrote:
>
> Yes, some admins don't have fine-enough grain tools to block or throttle
> specific types of ICMP, but that's the fault of the vendors, not the admins.
We call these tunable parameters "nerd knobs".
I used to create those knobs for
> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote:
>
> On 3/3/19 1:04 PM, Mark Andrews wrote:
>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>> getting
>> back to the TCP servers.
>
> For those of us who are in the dark, "PTB" appears to refer to "Packet
> Too
On 3/3/19 1:04 PM, Mark Andrews wrote:
> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
> getting
> back to the TCP servers.
For those of us who are in the dark, "PTB" appears to refer to "Packet
Too Big" responses in ICMPv6.
Yes, some admins don't have fine-enough
On 3/Mar/19 23:04, Mark Andrews wrote:
> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
> getting
> back to the TCP servers. There are also IDIOTS that deploy load balancers
> that
> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
>
There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting
back to the TCP servers. There are also IDIOTS that deploy load balancers that
DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
back end. There are also IDOITS that rate limit PTB
On 3/Mar/19 21:57, Jeroen Massar wrote:
> The transport (tunnel) CAN support that kind of fragmentation.
>
> (e.g. the tunnel could chop up a 1280 byte packet into two packets and the
> remote then join them together; that is a "ethernet" level thing).
If you have a working example between a
On 3/Mar/19 18:05, Jeroen Massar wrote:
> IPv6 requires a minimum MTU of 1280.
>
> If you cannot transport it, then the transport (the tunnel in this case)
> needs to handle the fragmentation of packets of 1280 down to whatever does
> fit in the tunnel.
As you know, IPv6 does not support
Hi all.
Just an update on this... it did turn out to be an MTU issue which I've
been working on since last year, November. The trick was finding the
right combination of settings between my Mikrotik home router and one of
our Cisco ASR1006 edge routers in my backbone that terminates the 6-in-4
John Von Essen writes:
> I recently go a Linksys home wifi router, by default it enables ipv6
> on the LAN. If there is no native IPv6 on the WAN side (which is my
> case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.
Could this be a 6RD tunnel requested by your ISP using
On 12/Nov/18 20:34, Mikael Abrahamsson wrote:
>
>
> Are you doing TCP MSS adjust/clamping? If you don't, try that and see
> if it helps. This might be a PMTUD issue.
>
> Otherwise if possible, try lowering the MTU sent in RA to the one you
> have on your tunnel (this depends on if this is
Which just shows content providers and tunnel end point problems.
* load balancers that don’t properly handle ICMP{v6}
* stupid firewalls that block PTB
* tunnel end points that don’t generate PTB for EVERY oversize packet
(you wouldn’t drop TCP ACKS and PTBs are just as important)
PMTD
I recently go a Linksys home wifi router, by default it enables ipv6 on
the LAN. If there is no native IPv6 on the WAN side (which is my case
since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.
For the first few weeks of using the router, I had no idea alot of my
traffic was
Not to beat a dead horse, but could the problem be so simple? I have
tons of dual-stacked machines that have updated forever without issue,
so I assume they update via IPV4.
That being said, I've not packet sniffed any of the update stuff in a
while but if the DNS is any indication then
On Mon, 12 Nov 2018, Mark Tinka wrote:
I do run 6-in-4 from my backbone to my house as my FTTH provider does
not do IPv6.
I can't imagine this to specifically be the issue, as all other IPv6
traffic is fine, but at this point, I'm open to suggestion.
Are you doing TCP MSS adjust/clamping? If
On 12/Nov/18 18:18, Clinton Work wrote:
> I saw this issue randomly on Windows PCs due to IPV6 TCP checksum
> offloading.
>
> Try the following on the problem Windows machine:
> - Open the Device Manager -> Network Adapters -> Network Interface
> (Ethernet NIC):
> - Under the Network Adapter
On 11/Nov/18 20:35, Jared Mauch wrote:
> Let me know if you see anything related to Akamai.
Will do.
> Looking at these threads I don’t see anything really obvious and some are
> much older posts.
Agreed - but those posts were never really solved, and the issue
description and behaviour
On 11/Nov/18 18:51, Lavanauts wrote:
> I’m on native IPv6 via Spectrum and have no problems with Windows
> Updates. Could this be a tunneling issue?
I do run 6-in-4 from my backbone to my house as my FTTH provider does
not do IPv6.
I can't imagine this to specifically be the issue, as all
I saw this issue randomly on Windows PCs due to IPV6 TCP checksum
offloading.
Try the following on the problem Windows machine:
- Open the Device Manager -> Network Adapters -> Network Interface
(Ethernet NIC):- Under the Network Adapter -> Advanced Tab, disable these
options
if present:TCP
> On Nov 11, 2018, at 8:45 AM, Mark Tinka wrote:
>
>
>
> On 11/Nov/18 14:02, Chris Knipe wrote:
>
>> Also no problems here with IPv6 and Windows Updates...
>
> The issue is affecting (and has affected) quite a few folk:
>
>
Hi,
Le 11/11/2018 à 13:00, nanog-requ...@nanog.org a écrit :
> [...]
> Date: Sun, 11 Nov 2018 11:29:43 +0200
> From: Mark Tinka
> Hi all.
> Anyone ever figured out why Windows updates fail when the computer has
> an IPv6 connection?
Weird .. We have PC running Windows 10 pro (20+) in my
I’m on native IPv6 via Spectrum and have no problems with Windows Updates.
Could this be a tunneling issue?
Tony
> On Nov 10, 2018, at 23:29, Mark Tinka wrote:
>
> Hi all.
>
> Anyone ever figured out why Windows updates fail when the computer has an
> IPv6 connection?
>
> Google has
On 11/Nov/18 14:02, Chris Knipe wrote:
> Also no problems here with IPv6 and Windows Updates...
The issue is affecting (and has affected) quite a few folk:
Also no problems here with IPv6 and Windows Updates...
On Sun, Nov 11, 2018 at 1:42 PM Daniel Corbe wrote:
> at 4:29 AM, Mark Tinka wrote:
>
> > Hi all.
> >
> > Anyone ever figured out why Windows updates fail when the computer has
> an
> > IPv6 connection?
> >
> > Google has tickets and
at 4:29 AM, Mark Tinka wrote:
Hi all.
Anyone ever figured out why Windows updates fail when the computer has an
IPv6 connection?
Google has tickets and tickets of this to and outside of Microsoft since
2013, with no real solution or answer as to what the problem actually is.
In
Hi all.
Anyone ever figured out why Windows updates fail when the computer has
an IPv6 connection?
Google has tickets and tickets of this to and outside of Microsoft since
2013, with no real solution or answer as to what the problem actually
is. In essence, many of the solutions out there point
51 matches
Mail list logo
