* Jason Iannone
But the clever budget conscious among us have deployed router links
over provided MPLS based L2 services as critical infrastructure. We
have an invisible WAN. In the absence of L1 PM statistics, how do we
validate service over other networks? 802.3ag and y.1731 attempt to
answe
* David Zimmerman
Hi, all. BFD is well known for what it brings to the table for
improving link failure detection; however, even at a reasonably
athletic 300ms Control rate, you're not going to catch a significant
percentage of brownout situations where you have packet loss but not a
full o
* Carlos Kamtha
Looking for upstream provider where I can locate DNS servers with global
anycast service.
We have our own CIDR to announce and would prefer physical presence starting
with South Asia and Europe.
Commemts and suggestions welcome.
Something like Netnod DNSNODE? We're using the
On 27/03/24 01:04, Brian Knight via NANOG wrote:
What's presently the most commonly used open source toolset for
monitoring AS-to-AS traffic?
I want to see with which ASes I am exchanging the most traffic across
my transits and IX links. I want to look for opportunities to peer so
I can bette
* Rolf Winter
> If you would like to play with reverse traceroute, the easiest option
> is to work with the client and use one of the public server instances
> (https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS).
> If you would be willing to host a public server instance yourself,
* Andrey Khomyakov
> Interesting tidbit is that we actually used to manufacture custom rails for
> our Juniper EX4500 switches so the switch can be actually inserted from the
> back of the rack (you know, where most of your server ports are...) and not
> be blocked by the zero-U PDUs and all th
* Dobbins, Roland
> Scanning is part of the ‘background radiation’ of the Internet, and it’s
> performed by various parties with varying motivations. Of necessity, IPv6
> scanning is likely to be more targeted (were your able to discern any rhyme
> or reason behind the observed scanning patter
A couple of hours after midnight UTC, the control plane policers for
unresolved traffic on a couple of our CE routers started being clogged with
ping-scanning activity from 2620:96:a000::/48, which belongs to «Internet
Measurement Research (SIXMA)» according to ARIN.
Excerpt of this traffic (anony
* Michael Hare
> I'm considering an approach similar to Tore's blog where at some
> point I keep the full RIB but selectively populate the FIB. Tore,
> care to comment on why you decided to filter the RIB as well?
Not «as well», «instead».
In the end I felt that running in production with the R
* Saku Ytti
> On Fri, 5 Jun 2020 at 11:23, Tore Anderson wrote:
>
> > Sure you can, you just ask them. (We did.)
>
> And is it the same now? Some Ytti didn't 'fix' the config last night?
> Or NOS change which doesn't do conditional routes? Or they
&g
* Saku Ytti
> On Fri, 5 Jun 2020 at 10:48, Tore Anderson wrote:
>
> > We started taking defaults from our transits and filtering most of the
> > DFZ over three years ago. No regrets, it's one of the best decisions we
> > ever made. Vastly reduced both convergence
* James Breeden
> I come to NANOG to get feedback from others who may be doing this. We
> have 3 upstream transit providers and PNI and public peers in 2
> locations. It'd obviously be easy to transition to doing partial
> routes for just the peers, etc, but I'm not sure where to draw the
> line o
* Cummings, Chris
> Now that you say that, I think you're right. I am referring specifically to
> the EX4650 and they are the cheesy type where the rear half of the rail stays
> screwed in to the rack and the front half of the rail is attached to the
> switch. I assume it is the same on the QFX
* Chuck Anderson
> The point is that the switches need to be removable without empty
> space above/below, and ideally from the rear side of the rack. By
> having extending/sliding rails, you can lift out or drop in the switch
> after you slide it out. Then you can remove the rails.
>
> With fix
* Luke Guillory
> I've had gear that came with a small rear support shelf that didn't had to
> the height, RGB Networks BNPs for example. I'm pretty sure we've used these
> with the BNPs one on top of the other.
>
> Page 16 in this PDF shows the shelf.
>
> http://www.konturm.ru/catalogy/df/bn
* David Funderburk
> 2 - Do you know of any universal rail kits for 1U, 2U and 3U servers,
> routers, switches that work well? The brand names are nice but expensive.
> Thought I'd explore some cheaper options first. We use a lot of MikroTik, HP,
> Dell and some CISCO with a few other things h
* Baldur Norddahl
> If you join any peering exchanges, full tables will be mandatory. Some
> parties will export prefixes and then expect a more specific prefix received
> from your transit to override a part of the space received via the peering.
That would be a fundamentally flawed expectati
* David Guo via NANOG
> Good News! But we still received several spams from Cogent for our RIPE and
> APNIC ASNs.
If you are an EU/EEA citizen, you may object to their use of your personal
information for marketing purposes (or for any purpose at all), as well as
request erasure.
(Note: these
* Saku Ytti
> Not true. Hash result should indicate discreet flow, more importantly
> discreet flow should not result into two unique hash numbers. Using
> whole TOS byte breaks this promise and thus breaks ECMP.
>
> Platforms allow you to configure which bytes are part of hash
> calculation, wh
* Nick ten Cate
> We also have lots of experience with FS.com switches; however.. One thing we
> noticed really quick is that its better to order 1 and to find the actual
> supplier and order with them directly. FS.com is a reseller; and they will
> switch (no pun intended) supplier almost year
* Art Stephens
> Hope this is not too off topic but can any one advise if a Dell S4048-ON can
> support full ebgp routes?
As others have mentioned, you won't be able to program them all in the
forwarding plane, but the control plane can receive them all just fine (it has
more than enough RAM).
* Mark Milhollan
> On Thu, 11 Apr 2019, Tore Anderson wrote:
>
>> We've been wanting to replace our all of our ad-hoc OOB links with a
>> standardised setup based on LTE connectivity to an embedded
>> login/console server at each PoP. IPv6 would be perfect due to
* Owen DeLong
> What would be the process for a subscriber who wishes to allow inbound
> connections?
>
> If you are simply saying that as a customer of your ISP you simply can’t
> allow inbound IPv6 connections at all, then you are becoming a very poor
> substitute for an ISP IMHO.
I have to
* Jean-Daniel Pauget
> I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
> service
> of the concerned operator doesn't handle IPv6 yet.
>
> as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
> (rfc 4443)
> seem to be ignored or filtere
* Job Snijders
> Given the severity of the bug, there is a strong incentive for people to
> upgrade ASAP.
The buggy code path can also be disabled without upgrading, by building
FRR with the --disable-bgp-vnc configure option, as I understand it.
I've been told that this is the default in Cumul
* Mehmet Akcin
> I am noticing provider A enters market X saying they are tier 1 network but
> they do not have a si ngle peering session in country and they backhaul
> everything back to market Z where they deliver traffic to the peer via high
> latency and low performance method. This is caus
* Harley H
> Curious to hear others' thoughts on this.
> https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca
>
> This paper presents the view that several BGP hijacks performed by China
> Telecom had malicious intent. The incidents are:
> * Canada to Korea - 2016
> * US
* Marty Strong via NANOG
> Routing from ~150 locations, plenty of redundancy.
Any plans to support NSID and/or "hostname.bind" to allow clients to
identify which node is serving their requests? For example:
$ dig @nsb.dnsnode.net. hostname.bind. CH TXT +nsid
[...]
;; OPT PSEUDOSECTION:
; EDNS:
* Martin List-Petersen
> Your best bet: set up a Terredo gateway and facilitate these Xboxes as
> long as you don't give them native IPv6.
This is unlikely to help, as the XB1 doesn't use Teredo relays at all.
The XB1 uses Teredo to facilitate direct p2p communication between IPv4
consoles onl
* craig washington
> Newbie question, what criteria do you look for when you decide that
> you want to peer with someone or if you will accept peering with
> someone from an ISP point of view.
Routing hygiene. I expect the would-be peer to keep the number of
advertised routes that are either 1) no
Hi Aaron,
> What happened was, when I turned up my new 10 gig Telia Internet
> connection a few days ago, I needed to balance out my (4) 10 gig
> internet connections so I chopped up a /17 into (4) /19's. When I
> did this, I was still advertising the /17 to my local caches, but I
> was advertisi
* Saku Ytti
> On 16 January 2017 at 14:36, Tore Anderson wrote:
>
> > Put it another way, my «Internet facing» interfaces are typically
> > 10GEs with a few (kilo)metres of dark fibre that x-connects into my
> > IP-transit providers' routers sitting in nearby r
* Saku Ytti
> Why I said it won't be a problem inside DC, is because low RTT, which
> means small bursts. I'm talking about backend network infra in DC, not
> Internet facing. Anywhere where you'll see large RTT and
> speed/availability step-down you'll need buffers (unless we change TCP
> to pac
Hi Saku,
> > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html
>
> ---
> As described in a prevous post, we’re testing a HPE Altoline 6920 in
> our lab. The Altoline 6920 is, like other switches based on the
> Broadcom Trident II chipset, able to handle up to 720 Gbp
* Mark Tinka
> On 5/Aug/16 15:40, Soon Keat Neo wrote:
>
> > If you are just announcing more specific address space that you've
> > obtained legitimately off their assigned address space, it should
> > be no problem, just obtain an LoA and register it on the different
> > databases and you should
* Baldur Norddahl
> I did not say we were doing internet peering...
Uhm. When you say that you peer with another ISP (and keep in mind what
the "I" in ISP stands for), while giving no further details, then folks
are going to assume that you're talking about a standard eBGP peering
with inet/inet6
* Baldur Norddahl
> What is best practice regarding choosing MTU on transit links?
>
> Until now we have used the default of 1500 bytes. I now have a
> project were we peer directly with another small ISP. However we need
> a backup so we figured a GRE tunnel on a common IP transit carrier
> woul
* Baldur Norddahl
> Den 22. jul. 2016 20.25 skrev "Ca By" :
>
> > Phones, as in 3gpp? If so, each phone alway gets a /64, there is
> > no choice.
> >
> > https://tools.ietf.org/html/rfc6459
>
> Here the cell companies are marketing their 4G LTE as an alternative
> to DSL, Coax and fiber for in
* Mark Tinka
> What I was trying to get to is that, yes, running a single-stack is
> cheaper (depending on what "cheaper" means to you) than running
> dual-stack.
Wholeheartedly agreed.
> That said, running IPv4-only means you put yourself at a disadvantage
> as IPv6 is now where the world is g
* Mark Tinka
> I understand your points - to your comment, my question is around
> whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and
> IPv4.
We've found that it is. IPv6-only greatly reduces complexity compared to
dual stack. This means higher reliability, lower OpEx, shorter r
* Davide Davini
> On 04/06/2016 20:46, Owen DeLong wrote:
> > Get your own /48 and advertise to HE Tunnel via BGP. Problem
> > solved.
>
> Even though that sounds like an awesome idea it does not seem trivial
> to me to obtain your own /48.
Which is a good thing, as every new PI /48 advertise
* Spencer Ryan
> As an addendum to this and what someone said earlier about the
> tunnels not being anonymous: From Netflix's perspective they are. Yes
> HE knows who controls which tunnel, but if Netflix went to HE and
> said "Tell me what user has x/48" HE would say "No". Thus, making
> them
* Mark Andrews
> In message <20160601103707.7de9d...@envy.e5.y.home>, Tore Anderson writes:
> > Or you could simply accept that active sessions are torn down
> > whenever the routing topology changes enough to flip traffic to the
> > anycast prefix to another NAT64 ins
* Baldur Norddahl
> It goes to the USA and back again. They would need NAT64 servers in
> every region and then let the DNS64 service decide which one is close
> to you by encoding the region information in the returned IPv6
> address. Such as 2001:470:64:[region number]::/96.
>
> An anycast solu
* Saku Ytti
> Yes, SLAAC, 4862 clearly does not forbid it, and there is no
> technical reason. But as you state, 2464 does not specify other
> behaviour. Writing new draft which specifies behaviour for arbitrary
> size wouldn't be a challenge, marketing it might be.
FYI: RFC 7421 is an in-depth d
William,
> Don't get me wrong. You can cure this fraud without going to extremes.
> An open peering policy doesn't require you to buy hardware for the
> other guy's convenience. Let him reimburse you or procure the hardware
> you spec out if he wants to peer. Nor do you have to extend your
> netwo
* Ca By
> Selling a service that is considered internet but does not deliver
> full internet access is generally considered properly bad.
>
> I would not do business with either company, since neither of them
> provide a full view.
+1
Both networks are in a position to easily remedy the situat
* Sander Steffann
> > We just need Google to announce that IPv6 enabled sites will get a
> > slight bonus in search rankings. And just like that, there will
> > suddenly be a business reason to implement IPv6.
>
> I already discussed that with them a long time ago, but they weren't
> convinced
* Mark Tinka
> On 27/Aug/15 07:16, Mark Andrews wrote:
>
> >
> > Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> > all of which are better solutions than NAT64. NAT64 + DNS64 which
> > breaks DNSSEC.
>
> Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after
Hi Mark,
* Mark Tinka
> In our deployment, we do not offer customers private IPv4 addresses. I
> suppose we can afford to do this because a) we still have lots of
> public IPv4, b) we are not a mobile carrier. So any of our customers
> with IPv4 will never hit the NAT64 gateway.
>
> When we do
* William Herrin
> On Thu, Aug 20, 2015 at 1:22 PM, Ca By wrote:
> > On Thu, Aug 20, 2015 at 9:36 AM, William Herrin wrote:
> >> Seriously though, if you want to run a v6-only network and still
> >> support access to IPv4 Internet resources, consider 464XLAT or
> >> DS-Lite.
> >
> > NAT64 is a
* Owen DeLong
> > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote:
> > This is only true for dual-stacked networks. I just tried to set up
> > an IPv6-only WiFi network at my house recently, and it was a total
> > fail due to non-implementation of relatively new standards...
> > starting with
* Julien Goodwin
> Juniper have recently (15.1, still not out for all platforms) rebased
> JunOS on a slightly less ancient FreeBSD release, and nothing I have in
> my lab has it released yet, and I can't be bothered to go spelunking in
> the install image for what version of NTP it's running.
* Mike Leber
> I was thinking that when I posted yesterday.
>
> These were announcements from a peer, not customer routes.
>
> We are lowering our max prefix limits on many peers as a result of this.
>
> We are also going towards more prefix filtering on peers beyond bogons
> and martians.
Hi
* Stefan Schlesinger
> > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote:
> >
> > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> > comes dangerously close to your modest proposal.
>
> I wonder why Google hasn't published the patch yet. Leap smear so
* Matthew Huff
> That won't work. Being internally sync'ed isn't good enough for
> FINRA. All the machines must be synced to an external accurate source
> at least once per trading day.
That was why I proposed to ntpdate on your (upstream-free since the
29th) NTP server(s) sometime on the 30th. T
* Matthew Huff
> I saw that, but it says the bits are set "before 23:59" on the day of
> insertion, but I was hoping that I could shut it down later than
> 23:59:59 of the previous day (8pm EST). The reason is FINRA
> regulations. We have to have the time synced once per trading day
> before the o
* Matthew Huff
> Does anyone know what the latest that we can run our NTP servers and
> not distribute the LEAP_SECOND flag to the NTP clients?
From http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions:
Leap Indicator
This is a two-bit code warning of an impending leap second to
* Majdi S. Abbas
> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
> > Leap years and DST ladjustments have never caused us any major
> > issues. It seems these code paths are well tested and work fine.
>
> I've seen quite a few people that for w
* Harlan Stenn
> Matthew Huff writes:
> > A backward step is a known issue and something that people are more
> > comfortable dealing with as it can happen on any machine with a
> > noisy clock crystal.
>
> A clock crystal has to be REALLY bad for ntpd to need to step the
> clock.
>
> > Having
* Marty Strong via NANOG
> It *looks* like GBLX stopped accepting the leak.
If so, it's a partial fix at best, I still see plenty of leaked routes,
both via 3356 and 3549, e.g.:
tore@cr1-osl3> show route 195.24.168.98 all
Jun 12 12:03:54 +0200
inet.0: 544405 destinations, 1591203 routes (5430
I see tons of bogus routes show up with AS4788 in the path, and at
least AS3549 is acceping them.
E.g. for the RIPE NCC (193.0.0.0/21):
[BGP/170] 00:20:29, MED 1000, localpref 150
AS path: 3549 4788 12859 I, validation-state: valid
* Baldur Norddahl
> The high tech solution is stuff like MAP where you move the cost out
> to the CPE. But then you need to control the CPE - if you have that
> then great. You would still want to sell a non-NAT (and MAP is NAT)
> to users that require a public IPv4 address, so you still need to
* Dave Taht
> I am told that well over 50% of all android development comes from
> volunteer developers so rather than kvetching about this it seems
> plausible for an outside effort to get the needed features for
> tethering and using dhcpv6-pd into it. If someone wanted to do the
> work.
https:
* Lorenzo Colitti
> > On the other hand, there exist applications *today* that do require
> > DHCPv6. One such example would be MAP, which IMHO is superior to
> > 464XLAT both for the network operator (statlessness ftw) as well as
> > for the end user (unsolicited inbound packets work, no NAT trav
* Lorenzo Colitti
> Tethering is just one example that we know about today. Another example is
> 464xlat.
You can't do 464XLAT without the network operator's help anyway (unless
you/Google is planning on hosting a public NAT64 service?). If the
network operator actively wants 464XLAT to be used,
* Lorenzo Colitti
> Remember, what I'm trying to do is avoid user-visible regressions
> while getting rid of NAT. Today in IPv4, tethering just works,
> period. No ifs, no buts, no requests to the network. The user turns
> it on, and it works.
*cough*
https://code.google.com/p/android/issues/det
* Mark Tinka
> On 16/Apr/15 07:25, Tore Anderson wrote:
> > We're in a similar situation here; transit prices has come down so
> > much in recent years (while IX fees are indeed stagnant) that I am
> > certain that if I were to cut all peering and buy everything
* Baldur Norddahl
> Transit cost is down but IX cost remains the same. Therefore IX is longer
> cost effective for a small ISP.
>
> As an (non US) example, here in Copenhagen, Denmark we have two internet
> exchanges DIX and Netnod. We also have many major transit providers,
> including Hurrican
Hi Baldur,
* Baldur Norddahl
> On 1 February 2015 at 20:10, Tore Anderson wrote:
>
> > - Tunneling moves the original layer-4 header into another
> > encapsulation layer, so e.g. an ACL attempting to match an IPv6
> > HTTP packet using something like "
very well simultaneously transport IPv6, AppleTalk, and
IPX/SPX across an IPv4-only network - but that doesn't mean that the
network is "quad-stack" - IMHO, it's still single-stack IPv4.
> On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson wrote:
> > If everyone could jus
* Baldur Norddahl
> Single stacking on IPv6 is nice in theory. In practice it just doesn't work
> yet. If you as an ISP tried to force all your customers to be IPv6 single
> stack, you would go bust.
Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies
who have already or are i
* Mel Beckman
>Um, haven't you heard that we are out of IPv4 addresses? The point
> of IPv6 is to expand address space so that the Internet can keep
> growing. Maybe you don't want to grow with it, but most people do.
> Eventually IPv4 will be dropped and the Internet will be IPv6-only.
> Dual
* William Herrin
> nat64/nat46 - allows an IPv6-only host to interact in limited ways
> with IPv4-only hosts. Don't go down this rabbit hole. This will
> probably be useful in the waning days of IPv4 when folks are
> dismantling their IPv4 networks but for now the corner cases will
> drive you nut
* "Roland Dobbins"
> On 12 Jan 2015, at 16:19, Tore Anderson wrote:
>
> > I'd love to use flowspec over D/RTBH, but to me it seems like
> > vapourware.
>
> I meant on your own infrastructure, apologies for the confusion.
Right. So if I first need to ac
* "Roland Dobbins"
> On 11 Jan 2015, at 20:52, Ca By wrote:
>
> > 3. Have RTBH ready for some special case.
>
> S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too).
But are there any transit providers that support flowspec these days?
As I understand it, only GTT used to, but they sto
* Yucong Sun
> My recent inquiry to some network provider reveals that they are
> charging fee for per /24 announced. Obvious that would means they get
> to charge a lot with little to none efforts on their side.
>
> In a world we are charging total bytes transferred instead of bps on
> uplinks,
* Baldur Norddahl
> Why do people assign addresses to point-to-point links at all? You can just
> use a host /128 route to the loopback address of the peer. Saves you the
> hassle of coming up with new addresses for every link.
Why do you need those host routes?
Most IPv6 IGPs work just fine wit
* William Herrin
> On Sun, Apr 27, 2014 at 2:05 AM, Rick Astley wrote:
>> #3 On paid peering:
>> I think this is where people start to disagree but I don't see what should
>> be criminal about paid peering agreements. More specifically, I see serious
>> problems once you outlaw paid peering and t
* William Herrin
> On Sat, Mar 22, 2014 at 8:19 PM, Randy Bush wrote:
>>> don't believe for a moment that v6 to v4 protocol translation is any less
>>> ugly than CGN.
>>
>> it can be stateless
>
> You're smarter than that.
https://tools.ietf.org/html/rfc6145
https://tools.ietf.org/html/draft-ie
* John Levine
> Also, although it is fashionable to say how awful CGN is, the users
> don't seem to mind it at all.
You might just be looking in the wrong places.
Try searching for "playstation nat type 3" or "xbox strict nat".
Tore
* Nick Hilliard
> the level of pain
> associated with continued deployment of ipv4-only services is still nowhere
> near the point that ipv6 can be considered a viable alternative.
This depends on who you're asking; as a blanket statement it's
demonstrably false: For the likes of T-Mobile USA¹ an
* Tore Anderson
> * Baldur Norddahl
>
>> Is assigning a /24 from my own PA space for the purpose of BGP
>> multihoming considered sufficient "need"?
>
> Not with current policies, no
That was then. With current policies: yes.
To elaborate a bit, the RIPE Com
* Owen DeLong
> In answer to Tore's statement, this block does not apply the standard
> justification criteria and I think you would actually be quite hard
> pressed to justify a /24 from this prefix. In most cases, it is
> expected that these would be the IPv4 address pool for the public
> facing
* Mark Andrews
> I understand this but this block changes the status quo. It is a
> policy changer. AFAIK ARIN hasn't done allocations to the /28 level
> like this in the past. This is all new territory.
It's not exactly new. Like I've mentioned earlier in this thread, the
RIPE NCC has granted
* Job Snijders
> On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
>
>> for example there is a small company with /22 IPv4 allocation from
>> RIPE in European region. This company is dual-homed and would like to
>> announce 4x /24 prefixes to both ISPs. Both ISP's update their
>> prefix-l
* Justin M. Streiner
> In the worst case, this would add another 262,144 routes (/10 fully
> assigned, and all assignments are /28s) to the global IPv4 route view.
> Realistically, the number will be a good bit smaller than that, but only
> time will tell for sure exactly how much smaller. Wash/r
* Baldur Norddahl
> Apologies for a RIPE question on NANOG, although I believe this issue
> will soon enough to be relevant for the ARIN region as well.
Relevant perhaps, but as the policies differ, so may the correct answers...
> I had a customer ask if we could provide him with BGP such that h
* Sander Steffann
> But more important: which /10 is set aside for this? It is not listed
> on https://www.arin.net/knowledge/ip_blocks.html
Probably 23.128/10:
arin||ipv4|23.128.0.0|4194304||reserved|
Tore
* Dobbins, Roland
> Once again, nothing in my post said or referred to bandwidth;
The post of mine, to which you replied, did.
Perhaps if you had taken your own advice quoted below when replying to
me, Nick wouldn't have been contextually confused.
Tore
> In future, it might be a good idea to
* James Braunegg
> Of course for any form of Anti DDoS hardware to be functional you
> need to make sure your network can route and pass the traffic so you
> can absorb the bad traffic to give you a chance cleaning the
> traffic.
So in order for an Anti-DDoS appliance to be functional the network
* Richard Hesse
> On Tue, Aug 27, 2013 at 12:14 PM, Joe Abley wrote:
>
>> - response you can expect when you call one day and say "our 10GE is
>> maxed out with inbound traffic from apparently everywhere, it has been
>> going on for an hour, please help"
>>
>
> That was good for a laugh.
>
>
* Owen DeLong
> On Aug 27, 2013, at 07:33 , valdis.kletni...@vt.edu wrote:
>
>> Saku Ytti and Emile Aben have numbers that say otherwise. And there must
>> be a significantly bigger percentage of failures than "pretty close to 0",
>> or Path MTU Discovery wouldn't have a reputation of being next
* David Edelman
> Does anyone have an explanation for the IPv6 hopopt appearing as protocol
> value 0 in http://www.iana.org/assignments/protocol-numbers?
It's defined in RFC 2460, section 4.3. Which is linked to from the
reference column of the page you linked to...
Tore
* Blake Hudson
> One thing not mentioned so far in this discussion is using PPPoE or some
> other tunnel/VPN technology for efficient IP utilization. The result
> could be zero wasted IP addresses without the need to resort to
> non-routable IP addresses in a customer's path (as the pdf suggested)
* Owen DeLong
> Quite the contrary… I personally think that the abysmal rate of IPv6
> adoption among some content providers (Are you listening, Amazon,
> Xbox, BING?) is just plain shameful.
FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting
(Oslo), and the page seems to load o
* Andrew Latham
> If I can walk around a smallish town and point at 5 businesses like
> this its a possible solution. I am not claiming a few /24s will do, I
> am claiming that there are many (for larger values of many) companies
> like this.
There are certainly several thousands or even million
* Chris Grundemann
> Nope, you are correct Geoff. There is a /10 reserved for transition
> technologies (e.g. outside addresses on a CGN) and there is a
> "critical infrastructure" reserve, but no general purpose reserve like
> in RIPE and APNIC.
One interesting thing is that this is dedicated sp
* Mikael Abrahamsson
> On Wed, 24 Apr 2013, Tore Anderson wrote:
>
>>> I have already read the news of blackmarket sales of network
>>> allocations in Europe.
>>
>> Interesting. Do you have a link or some other kind of reference?
>
> <http://www.ripe
* Andrew Latham
> I have sadly witnessed a growing number of businesses with /24s
> moving to colocation/aws networks and not giving up their unused
> network space. I assume this will come into play soon.
A couple of /24s being returned wouldn't make a significant difference
when it comes to IPv
1 - 100 of 163 matches
Mail list logo
