> This is all great and wonderful, except for one thing - the RIR allocation
> boundaries were never really meant to be used as "official" filtering prefix
> length limits. I certainly support Verio's right to filter on whichever
> boundaries make business sense to them. However, there is no deny
> I think you may have misread my comment. ARIN ALLOWS the issuance of /24s to
> multihomed enterprises. The recent policy decision was made to allow
> upstreams to do this sort of allocation, without having to receive any other
> justification, other than multihomed status. This could seem to be
> See section 3.2.1.8c of RFC 1122:
>
> processing). This recorded route will be reversed and
> used to form a return source route for reply datagrams
> (see discussion of IP Options in Section 4). When a
>
> --Steve Bellovin,
> > Has anybody mentioned the benefits of ISIS as an IGP to them.
>
> Link-state protocols are evil, and when they break, they *really* break.
> I still do not see a compeling argument for not using BGP as your IGP.
>
> Alex
iBGP is only one half of an IGP. It is the "where to go" half.
You st
> Running two routing protocols is too much of a hassle. I think I would
> rather use static routes, and synchronize routers using rsync, diff, and
> patch. Our NOC has several 286s running Xenix that could act as servers
> for this.
>
> This would eliminate the hassle of running OSPF, ISIS, o
> Which is exactly what you are doing when you inject nailed routes into bgp.
>
> So, why do you need IGP such as OSPF again?
>
> Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
complex and prone
> > > Which is exactly what you are doing when you inject nailed routes into bgp.
> > >
> > > So, why do you need IGP such as OSPF again?
> > >
> > > Alex
> >
> > To carry the bgp next-hops around the network? You could add in statics
> > for every next-hop on every router, but this kind of co
> As far as BGP would have done the same thing: would you mind desciring a
> configuration of BGP where deletion of a network statement in one router
> would cause unreachability across paths that do not *realy* on that network
> statement?
Since you have replaced ospf/isis/rip or any other dyna
> On Thu, Sep 05, 2002 at 01:36:27PM -0400, Derek Samford wrote:
> > Shane,
> > There is a practice on that (At least here.). Generally we
> > provide a Class C to our customers at no additional charge, but we have
>
> Why in this day and age, 9 years after the invention of CIDR, are
> Shane:
>
> I think an important question would be what level of service are they
> buying. Including 255 address with a T3 would be very reasonable, less so
> with a T1, not very reasonable with DSL, and ridiculous with a dial-up
> account.
How is usage need in any way related to circuit siz
> Here is my reply to Joe
>
> Your solution is good. In general, anyone worried about this kind of invasion of
>privacy
> should arrange to run their own root servers. The more the merrier. This is not
>neccessarily
> about having multiple roots with colliding TLDs, but about security from
>
> So why doesn't c.root-servers.net provider or its peers implement this
> "simple" solution? Its not a rhetorical question. If it was so simple,
> I assume they would have done it already. PSI wrote one of the original
> peering agreements that almost everyone else copied. If it was a
> conc
> On Wed, Oct 30, 2002 at 03:44:12PM +, [EMAIL PROTECTED] wrote:
>
> > Therefore, would it be a reasonable suggestion to ask router vendors to
> > source address filtering in as an option[1] on the interface and then move
> > it to being the default setting[2] after a period of time?
>
> Can
> On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
> RPF checking can only go so far. You would need RPF checking down to the
> host level and I haven't heard anyone discuss that yet.
Is this a reason not to do what we can now?
> -Hank
Let's start with getting it going in the right direction, at l
> On Wed, 30 Oct 2002, Charles D Hammonds wrote:
>
> > analogy games are fun, but it boils down to this... If I know the real
> > source of an attack, I can stop it within minutes. I'm sure that my
> > customers appreciate that fact. Noone will ever completely stop attacks, the
> > point is to mi
> On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > What about the other large isps? What would it take for you to do
> > something? Chris is gracious enough to show up and participate, at
> > least even if it does mean he has to wear nomex.
>
> I'm in favor of source address filtering at the edges
> Hi,
>
> This is a long shot, but I'm hoping someone can help me out here...
>
> I was wondering if it would be possible to purchase an entire Class C
> address range for use in Germany. I have a Infrastructure company based
> in south africa that is looking to connect some 80 sites throughout
> > I'm opposed to some of the suggestions where to put source address
> > filters, especially placing them in "non-edge" locations. E.g. requiring
> > address filters at US border crossings is a *bad* idea, worthy of an
> > official visit from the bad idea fairy.
>
> What is bad about filtering
> ---> so its a hardware limitation?bigger cores needed
The best place to filter is the edge of one's network, in the strictest
manner possible. While possible to filter in the core of one's network,
you lose the majority of the usefulness of RPF (no strict checking, can
only check fo
> Ok, so I'll respond to one more of the messages I missed yesterday.
>
> On Mon, 4 Nov 2002, Matt Buford wrote:
> > On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > > The only equipment I'm heard here which has serious issues related to
> > > feature availability is the 12000 (which was never a p
> > Sounds like you're trying to either shoot yourself in the foot, or design a
> > new too-clever-by-half way of building a VPN.
>
> It is called a one-way ip over satellite link to places like Australia, New
> Zeland or Middle East. So it is not like we are talking about little bit of
> traffic
> One of my clients is currently a victim of an over-zealous ISP
> recklessly trying to implement rpf.
Assuming the provider is doing the right thing by filtering routing
announcements, and assuming the customer has done the right thing
by informing their provider of the blocks they _might_ ann
> fine now? u can put "loose"...its NO USE!! thats what i said..there will
> always be a route to the sourceall u may drop is 10.x/192.168 and
> 172/16-31..that too if ur network isnt internally using it
>
> and if u end up putting "loose" an OSPF router ull drop valid traffic if ur
>
> fine now? u can put "loose"...its NO USE!! thats what i said..there will
> always be a route to the sourceall u may drop is 10.x/192.168 and
> 172/16-31..that too if ur network isnt internally using it
Oh, and if this ends up being the case, what's wrong with that? Less RFC1918
crap
Anyone else notice that you now need javascript in order to even
view TAC Cases? Anyone else annoyed by this crippling of
something Cisco actually did reasonably well?
Anyone not care what cisco does to CCO because you're still mourning
the loss of CIO?
What's next, requirement for flash to view
> Looked just like a regular SYN flood to the target IP. Not sure why they
> picked source addresses that were so obviously bogus though.
>
> Can anyone think of a reason why this sort of traffic should be routed at
> all? Does anyone actually drop hosts on to addresses ending in x.x.x.0?
x.x
> I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP
> directories for unallocated IP space at the largest aggregate level. I'd
> also like to see them all dump the quirky and antiquated whois protocol
> and move to LDAP as the standard way of querying their directories. The
> Hello Everyone,
>
> I appreciate all of the discussion regarding this issue. Nothing has
> changed. This is getting worse. We spoke to one network on Friday that
> said they had cleared the problem, yet our users still can't go there.
>
> For those of you that feel this is not anyone's prob
> > I think we can all agree that whoever's responsibility it is, the
> > current system is broken. You can't actually count on people to read
> > this list.
>
> Absolutely right!
> And all of this discussion that you have sparked on the list will actually
> help solve the problem. Unfortunatel
> Hello,
> Currently APNIC's policy means that if an organization can fully use a
> /26 (since 25% of /24=/26 and to satisfy the multihoming requirement the
> organization will need to have a prefix advertised by two or more ISPs) it
> can get a multihoming assignment from APNIC.
If RIRs begin
> Here is one reason for some to care :
>
> If you want to do interdomain multicast, and your
> address space is not announced globally (say because you have a /24 that
> is
> not from the swamp), you are likely to be black-holed
> due to RPF failures (as your unicast and multicast routing is li
> I am not getting through to speed.planet.nl in English, can anyone give
> me
> a decent translation of in Dutch (The Netherlands):
>
> "Here are our logs, indicating your host is attempting to access
> formmail on our web servers. We have been seeing at least 1,000 attempts
> a day
> for weeks
> This message explains an upcoming change in certain behavior of the
> com and net authoritative name servers related to internationalized
> domain names (IDNs).
>
> VeriSign Global Registry Services (VGRS) has been a longtime advocate
> of IDNs. Our IDN Test Bed has been active for over two ye
> But this worm required external access to an internal server (SQL Servers
> are not front-end ones); even with a bad or no patch management system, this
> simply wouldn't happen on a properly configured network. Whoever got
> slammered, has more problems than just this worm. Even with no firewal
> Not to sound to pro-MS, but if they are going to sue, they should be able to
> sue ALL software makers. And what does that do to open source? Apache,
> MySQL, OpenSSH, etc have all had their problems. Should we sue the nail gun
> vendor because some moron shoots himself in the head with it?
How many folks are watching the multicast stream vs the unicast stream?
Those watching the multicast stream really won't notice issues due to
number of viewers.
Perhaps the continuing degradation of the unicast stream is a bit of
social engineering to get folks to move to multicast? If so, good f
223.255.255.0/24 has historically been designated as a special-use network
as it is the numerically highest Class C network. It is listed in
RFC3330 as Reserved but open for possible future allocation.
Now that 222/7 has been allocated to APNIC, the question comes up as to
whether it is retaining
> I can imagine there is some reason why this was originally reserved thats
> probably not valid any more..
It definately is not valid unless someone is living in the stone ages.
The network corresponds to the numerically highest Class C network,
and is reserved for a potential future classful s
> You forgot the other one - expense. AFAIK all of the registries have fees
> or require you to be a customer. If there is no operational value for me
> why would I want to spend the money? I realize most of you work for
> companies that consider a million dollars chump change but that is not t
This discussion falls into a pattern we've seen before:
1) Operators doing the right thing experience a problem created by
operators doing the wrong thing.
2) It is not possible to isolate the pain to only the operators
doing the wrong thing.
3) The only way to solve the problem is to raise the l
> Its not quite that simple folks. The reason this particular
> block is reserved has some real technical merit, while the 69/8
> muddle is strictly due to ISP negligence.
>
> RFC 3330 got it wrong. Anyone remember the "Martian List"
> from the 1970-1990's? Trying
> Be careful on charging for it...
>
> I know of cases where adult-websites/spammers (who have more money than
> they know what to do with) will buy 8 class-C's and when one gets
> blacklisted, they move onto the next... by the time they're on the 8th,
> the 1st is available again...
>
> If you
> If someone can identify what you are actually seeing, I'll check into
> it.
> If you are experiencing drops or slow traces, only through the core,
> there is an issue with excessive de-prioritization of ICMP control
> message with a particular router type (vendcor) in the core. End to end
> data
> I think your getting confused?
>
> The restriction is on subnets using classful addresses, you shouldnt use all
> zeros and all ones subnet for a given subnetted classful network.
>
> In the examples below, 192.0.0.0 and 192.0.255.0 are valid Class C networks..
> however if you then go class
> On Thu, Mar 20, 2003 at 03:26:35PM -0500, [EMAIL PROTECTED] wrote:
> >
> > > If someone can identify what you are actually seeing, I'll check into
> > > it.
> > > If you are experiencing drops or slow traces, only through the core,
> > > there is an issue with excessive de-prioritization of ICM
> On Fri, Mar 21, 2003 at 12:11:47PM -0500, [EMAIL PROTECTED] wrote:
>
> > Would you agree, as I've suggested, that there is no inherent
> > technical limitation to using 223.255.255.0/24?
>
> FWIW, I still see 'classful behavior' with WindowsXP (all recent
> service packs and such like) and als
> Sorry to populate the list with traffic like this...
>
> Extended IP access list 120
> deny ip 216.156.98.0 0.0.0.255 any (31607418 matches)
> permit ip any any (43284187 matches)
>
> (this is under 2 hours)
>
> Which is a very, very bad thing.
>
> Can someone from XO, please contact
> I'm tasked with coming up with an IP plan for an very large lab
> network. I want to maximize route table manageability and
> router/firewall log readability. I was thinking of building this
> lab with the following address space:
>
> 1.0.0.0 /8
> 10.0.0.0 /8
> 100.0.0.0 /8
I encourage my comp
> On Fri, 30 May 2003 [EMAIL PROTECTED] wrote:
>
> >
> > > I'm tasked with coming up with an IP plan for an very large lab
> > > network. I want to maximize route table manageability and
> > > router/firewall log readability. I was thinking of building this
> > > lab with the following address sp
> Hello!
>
> I've been asked to draw the attention of Network administrators to the
> recent hijacking of various large blocks of ARIN IP-space: particularly
> six /16 blocks allocated to the London-based Trafalgar House Group.
>
> Trafalgar House Group (THG):
> Trafalgar House Group TRAF (NET-
> Some of you *might* remember a rant I posted here several years ago
> about getting our first allocation from ARIN...many here suggested that
> I call ARIN and get clarification on the allocation (ie, they gave me a
> /20 when I offered to renumber out of a /20 plus a smattering of other
> block
> On Sat, 12 Apr 2003, Steve Gibbard wrote:
> > There aren't really technical issues with this beyond what you'd have to
> > deal with with normal IP space. If you're running BGP, you'll have to
> > announce the space and get filters updated to allow it, but you have to do
> > that with a block o
> A few years ago I had an issue with a few of the larger carriers rejecting
> my routes (from a natural Class B space) because their prefix length was too
> short (at one point I simply had the /16 divided into two /17's and this
> still got rejected in some places). I can't remember which carri
> Mike wrote:
> >
> > We're receiving multiple complaints about problems reaching anything
> > @bt. Is anyone else experiencing this?
>
> GrrrThree days later, BT is now telling their customers that
> somehow, this is our fault. I find it rather odd that everyone in the
> world can reach
> Is this really an issue? So long as they're not advertising the space I
> see no issue with routing traffic through a 10. network as transit. If
> you have no reason to reach their router directly (and after Cisco's last
> exploit, I'd think no one would want anyone to reach their router direc
> Needs is a tough call. Plenty of networks block ICMP at the border and
> could very well be using 1918 addressing in between and you'd have no
> idea.
>
> --
> David Temkin
Wholesale blocking of ICMP is another sign of incompetence. Either way
a network using RFC1918 inappropriately, filteri
> I'm all for raising the bar on attackers and having end networks implement
> proper source filtering, but even with that 1000 nt machines pinging 2
> packet per second is still enough to destroy a T1 customer, and likely
> with 1500 byte packets a T3 customer as well. You can't stop this without
> >> Filtering the bogons does help, and everyone should perform anti-spoofing
> >> in the appropriate places. It isn't, however, a silver bullet.
> > it's necessary but not sufficient.
>
> anti-spoofing is useful, but vastly insufficient, and hence not necessary
>
> randy
anti-spoofing elimin
> I would have though people would have learned by now that
> there is no technical solution to spam. You can go ahead
> with all these wonderfully expensive
> authentication/filtration/insertantispambuzzword systems until
> the cows come home and you will +_still_+ recieve spam.
>
> Regards,
> Filtering the bogons does help, and everyone should perform anti-spoofing
> in the appropriate places. It isn't, however, a silver bullet.
> >>> it's necessary but not sufficient.
> >> anti-spoofing is useful, but vastly insufficient, and hence not necessary
> > anti-spoofing eliminat
> On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
> >
> > > I'm all for raising the bar on attackers and having end networks implement
> > > proper source filtering, but even with that 1000 nt machines pinging 2
> > > packet per second is still enough to destroy a T1 customer,
> it all comes down to filtering, filtering, filtering.
>
> announcement filtering, anti-spoof filtering, peer filtering.
>
> If you're not doing this, you *SHOULD* be. I know it's hard
> to do these things in the current business environment. Those of
> you that can, please
> On Mon, 4 Aug 2003 [EMAIL PROTECTED] wrote:
>
> >
> > > On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
> > > >
> > > > > I'm all for raising the bar on attackers and having end networks implement
> > > > > proper source filtering, but even with that 1000 nt machines pinging
> We have seen that many people *posting* do not have the best of intentions;
> I can assure you that there are lurkers on Nanog (surprise, surprise) who
> are not nearly as naive and well-intentioned as J. O. would hope. In fact,
> I know that there are subscribers from various print media, vario
> I sympathize with the customer. There is no reason he should pay for
> traffic he did not request and does not want. If unwanted traffic raises
> your cost of providing the service for which you are paid (providing wanted
> traffic) then you should raise your rates.
Then why should _I_
> be fixed -- and I assure you, above all else, money talks...
While money talks, it often says the stupidest things, unfortunately.
Or maybe it is merely the folks with the most money.
> [multiple response]
>
> Christopher L. Morrow wrote:
>
> > I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there
> > was some lesson learned from this, no?
>
> I don't buy it, Chris. Are you saying that a large backbone provider
> can't maintain up-to-date bogon filters?
> keep in mind its not destination addresses that are the problem here, BUT
> if it was, on an experiment (not a very smart one) we routed 0/1 to a lab
> system inside 701 once in 2001 (as I recall, so before
> nimda/code-red/blaster) and recieved +600kpps of garbage traffic as a
> result. Trying
> Don't confuse the source and destination. This traffic is packets with an
> unused DESTINATION address.
Ok, you got me there. I do wonder, however, how much is responses
to traffic that began life as an unused source.
There is still the point that the catch-all route is causing more
hauling of
> Here is one solution - replace all of your root.cache files with:
1) it doesn't solve the problem of the .com and .net registry handing out
addresses
2) It creates whole new sets of problems
Please continue to go off and skulk in a corner
> This is just another example of a virtual monopoly doing whatever them
> damn well please because THEY CAN.
>
> Sorry to sound like a broken record, but we in the Inclusive Namespace
> have been saying this all along.
>
> How about a world with 1000's of TLDs all operated by different peo
> On Wed, 17 Sep 2003, [ISO-8859-1] Mathias Körber wrote:
>
> > > If we take a step back, we could say that the whole Verisign incident
> > > demonstrated pretty clearly that the fundamental DNS premise of having no
> > > more than one root in the namespace is seriously wrong. This is the
> > >
> Hello all,
>
> Was doing some upgrades on a UBR7246 (to a VXR), and I got to thinking
> about short sighted design considerations. I was curious if any of you
> had some pet peeves from a design perspective to rant about. I'll start
> with a couple.
try cisco-nsp. Single vendor stuff is
> On Wed, 17 Sep 2003 [EMAIL PROTECTED] wrote:
> > MAC addresses are not without authority delegation. The IEEE is the ultimate
> > authority in said case.
> >
> > Any solution which requires uniqueness also requires a singular ultimate
> > authority.
>
> Even MACs aren't entirely unique. Some
> On Wed, 17 Sep 2003 [EMAIL PROTECTED] wrote:
>
> > > If the goal were unique identification, MAC addresses would do just fine.
> > > No need for DNS.
> >
> > MAC addresses are not without authority delegation. The IEEE is the ultimate
> > authority in said case.
>
> Yep... But have you seen a
> Declan McCullagh wrote:
>
> >On Sat, Sep 20, 2003 at 11:34:17AM -0700, ken emery wrote:
> >
> >
> >>I think you haven't "gotten it". I'm getting the message from you that
> >>the changes made to the com and net gTLD's are fait accompli. From the
> >>
> >>
> >
> >That's the exact message
> --Fba/0zbH8Xs+Fj9o
> Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
> Content-Disposition: inline
>
>
> --wac7ysb48OaltWcw
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
>
> Two recent e-mails made me tak
> It would be great to add sending messages encoded in HTML is prohibited.
My apologies for the self-followup. As several people have emailed pointing
out that the original AUP email was not html (of which I'm aware since my
client doesn't do MIME, I was merely following up to the original messag
> AFAIK, it's been that way since Win95. I recall a certain
> vendor's dodgy ISDN router * * * on Windows traceroute, but
> working fine under *ix... for whatever reason, said router didn't
> like the ICMP traceroute, but returned unreachables in response
> to UDP when TTL expired.
>
>
> Eddy
> IMHO, I think we should create a route-set obj like call it... RS-DEAGGREGATES and
> list all the major irresponsible providers's specific /24's in it...
>
> So some ASes who wish to not accept deaggregated specifics using RPSL can update
> their AS import policy to not import RS-DEAGGREGATES
80 matches
Mail list logo
