Hi,
sorry - but why would you want to block Teredo / 6to4?
Florian Brandstetter
President & Founder
W // https://www.globalone.io
(https://link.getmailspring.com/link/5edc7c51-257c-47ac-b303-4b5a7f6e9...@getmailspring.com/0?redirect=https%3A%2F%2Fwww.globalone.io&recipient=bmFub2dAbmFub2cub3Jn)
On 10/13/19 8:58 AM, Stephen Satchell wrote:
In trying to research what would constitute "best practice", the papers
I found were outdated, potentially incomplete (particularly with
reference to IPv6), or geared toward other applications. This table
currently does not have exceptions -- some ma
On Sun, Oct 13, 2019 at 8:58 AM Stephen Satchell wrote:
> The following list is what I'm thinking of using for blocking traffic
> between an edge router acting as a firewall and an ISP/upstream. This
> table is limited to address blocks only; TCP/UDP port filtering, and IP
> protocol filtering,
Hi,
On Sun, Oct 13, 2019 at 08:58:17AM -0700, Stephen Satchell wrote:
> The following list is what I'm thinking of using for blocking traffic
> between an edge router acting as a firewall and an ISP/upstream. This
> fe80::/10 LinkLink-local address.
most people allow that
On Sun, 13 Oct 2019 at 19:29, William Herrin wrote:
> The current IPv6 Internet is 2000::/3, not ::/0 and that won't change in the
> foreseeable future. You can tighten your filter to allow just that.
Only do this, if this isn't CLI jockey network now or in the future.
--
++ytti
On 10/13/19 9:08 AM, Florian Brandstetter wrote:
> Hi,
>
> sorry - but why would you want to block Teredo?
I know nothing about Terendo tunneling.
> In computer networking, Teredo is a transition technology that gives
> full IPv6 connectivity for IPv6-capable hosts that are on the IPv4
> Interne
On 10/13/19 9:58 AM, Stephen Satchell wrote:
The Linux rp_filter knob is effective for endpoint servers and
workstations, and I turn it on religiously (easy because it's the
default).
I think it's just as effective on routers as it is on servers and
workstations.
For a firewall router witho
On 10/13/19 3:36 PM, Stephen Satchell wrote:
Are you saying that Terendo should come off the list? Is this useful
between an ISP and an edge firewall fronting an internal network? Would
I see inbound packets with a source address in the 2001::/32 netblock?
If you are running services which ar
On Mon, 14 Oct 2019 at 03:38, Grant Taylor via NANOG wrote:
> I think you should seriously re-consider using rp_filter on a router.
rp_filter is one of the most expensive features in modern routers, you
should only use it, if PPS performance is not important. If PPS
performance is important, ACL
❦ 14 octobre 2019 09:14 +03, Saku Ytti :
>> I think you should seriously re-consider using rp_filter on a router.
>
> rp_filter is one of the most expensive features in modern routers, you
> should only use it, if PPS performance is not important. If PPS
> performance is important, ACL is much fa
On Mon, 14 Oct 2019 at 09:30, Vincent Bernat wrote:
> How much performance impact should we expect with uRPF?
Depends on the platform, but often it's 2nd lookup. So potentially 50%
decrease in performance. Some platforms it means FIB duplication. And
ultimately it doesn't really offer anything o
On Fri, 18 Oct 2019 at 20:15, Lukas Tribus wrote:
> This has the potential to brake things, because it requires symmetry
> and perfect IRR accuracy. Just because the prefix would be rejected by
> BGP does not mean there is not a legitimate announcement for it in the
> DFZ (which is the exact diff
> On 19 Oct 2019, at 04:42, Saku Ytti wrote:
>
> On Fri, 18 Oct 2019 at 20:15, Lukas Tribus wrote:
>
>> This has the potential to brake things, because it requires symmetry
>> and perfect IRR accuracy. Just because the prefix would be rejected by
>> BGP does not mean there is not a legitimat
Hello!
On Tue, Oct 15, 2019 at 12:46 PM Saku Ytti wrote:
>
> On Mon, 14 Oct 2019 at 09:30, Vincent Bernat wrote:
>
> > How much performance impact should we expect with uRPF?
>
> Depends on the platform, but often it's 2nd lookup. So potentially 50%
> decrease in performance. Some platforms it m
Hello,
On Fri, Oct 18, 2019 at 7:40 PM Saku Ytti wrote:
> It's interesting to also think, when is good time to break things.
>
> CustomerA buys transit from ProviderB and ProviderA
>
> CustomerA gets new prefix, but does not appropriately register it.
>
> ProviderB doesn't filter anything, so it
On Fri, 18 Oct 2019 at 23:45, Lukas Tribus wrote:
Hey Lukas,
> I'm saying this breaks valid configurations because even with textbook
> IRR registrations there is a race condition between the IRR
> registration (not a route-object, but a new AS in the AS-MACRO), the
> ACL update and the BGP turn
On Sun, 20 Oct 2019 at 15:22, Lukas Tribus wrote:
> I agree this is something that should to be discussed, but to get
> there it's probably a very long road. Just look at the sorry state of
> BGP filtering itself. And this requires even more precision,
> automation,carefulness and *process change
Hello,
> > Is this deployed like this in a production transit network? How does
> > this network handle a failure like in example 2? How does it
> > downstream customers handle the race conditions like in example 1?
>
> Yes, I've ran BGP prefix-list == firewall filter (same prefix-list
> verbatim
> -Original Message-
> From: NANOG On Behalf Of Lukas Tribus
> Sent: Friday, October 18, 2019 9:45 PM
> To: Saku Ytti
> Cc: nanog@nanog.org
> Subject: Re: Request comment: list of IPs to block outbound
>
> Hello,
>
> On Fri, Oct 18, 2019 at 7:40
On Mon, 21 Oct 2019 at 23:14, wrote:
> The obvious drawback especially for TCAM based systems is the scale, so not
> only we'd need to worry if our FIB can hold 800k prefixes, but also if the
> filter memory can hold the same amount -in addition to whatever additional
> filtering we're doing a
> From: Saku Ytti
> Sent: Tuesday, October 22, 2019 11:54 AM
>
> On Mon, 21 Oct 2019 at 23:14, wrote:
>
> > The obvious drawback especially for TCAM based systems is the scale,
> > so not only we'd need to worry if our FIB can hold 800k prefixes, but
> > also if the filter memory can hold the s
Subject: Re: Request comment: list of IPs to block outbound Date: Sun, Oct 13,
2019 at 09:24:39AM -0700 Quoting William Herrin (b...@herrin.us):
>
> > 100.64.0.0/10 Private network Shared address space[3] for
> > communications be
On 10/22/19 10:54 PM, Måns Nilsson wrote:
I have a hard time finding text that prohibits me from running machines
on 100.64/10 addresses inside my network.
I think you are free to use RFC 6598 — Shared Address Space — in your
network. Though you should be aware of caveats of doing so.
It is
On 10/22/19 10:11 PM, Grant Taylor via NANOG wrote:
> The explicit nature of RFC 6598 is on purpose so that there is no chance
> that it will conflict with RFC 1918. This is important because it means
> that RFC 6598 can /safely/ be used for Carrier Grade NAT by ISPs without
> any fear of conflict
Subject: Re: Request comment: list of IPs to block outbound Date: Tue, Oct 22,
2019 at 11:11:27PM -0600 Quoting Grant Taylor via NANOG (nanog@nanog.org):
> On 10/22/19 10:54 PM, Måns Nilsson wrote:
> > It is just more RFC1918 space, a /10 unwisely spent on stalling IPv6
> > depl
On 2019-10-22 22:38 -0700, Stephen Satchell wrote:
> So, to the reason for the comment request, you are telling me not to
> blackhole 100.64/10 in the edge router downstream from an ISP as a
> general rule, and to accept source addresses from this netblock. Do I
> understand you correctly?
Depen
On 10/23/19 12:16 AM, Måns Nilsson wrote:
I understand the reasoning. I appreciate the need. I just do not agree
with the conclusion to waste a /10 on beating a dead horse. A /24 would
have been more appropriate way of moving the cost of ipv6 non-deployment
to those responsible. (put in RFC tim
On 10/22/19 11:38 PM, Stephen Satchell wrote:
So, to the reason for the comment request, you are telling me not
to blackhole 100.64/10 in the edge router downstream from an ISP as
a general rule, and to accept source addresses from this netblock.
Do I understand you correctly?
It depends.
I
On Wed, 23 Oct 2019 09:09:05 -0600, Grant Taylor via NANOG said:
> > Easing the operation of CGN at scale serves no purpose except stalling
> > necessary change. It is like installing an electric blanket to cure the
> > chill from bed-wetting.
>
> Much like humans can move passenter plains, even an
On 10/23/19 8:18 AM, Grant Taylor via NANOG wrote:
> I suspect things like NetworkManager are somewhat at a disadvantage in
> that they are inherently machine local and don't have visibility beyond
> the directly attached network segments. As such, they can't /safely/
> filter something that may b
30 matches
Mail list logo
