Re: 240/4
On 18 Oct 2007, at 09:34, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Okay, this has descended to a point where we need some fact injection. You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4. step awy from the crack pipe... Joe's facts were excellent. I read his email and thought "wow, this will kill this thread for sure" why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK so, as using these IPs publically isnt feasible why bother privately. you may as well use RFC1918 or IPv6. the latter whilst not without issues is at least being rolled out as part of a series of standards that are 10+yrs old i am really struggling with some of the logic being given here. more specifically the omissions in that logic are glaring. not attempt to engineer a solution that will work for everybody .. not our reponsibility to fix every problem out there .. I believe that people are not that stupid. .. We do not have a good reason to deny them that possibility. .. This is easy for vendors to fix. .. It is a trivial amount of work for the IETF to release the address space .. removing the 240/4 blockages could also be considered a trivial level of effort. .. those of us who do not want or need 240/4 addresses can ignore it. .. The cost is effectively zero in the first case, .. why should anyone try and convert them to the one true Internet architecture? i think you are somewhat deluded. Steve
Re: more-specifics via IX
On 17 Oct 2007, at 20:55, Bradley Urberg Carlson wrote: Thanks for the suggestions. On Oct 17, 2007, at 6:06 PM, Stephen Wilcox wrote: well.. the problem of course is that you pull in the traffic from the aggregate transit prefix which costs you $$$ but then you offload it to the customer via a peering link for which you are not being paid A bigger problem is that my IX peer pays less to my customer for transit. If my customer notices that transit traffic has been going around him, he may be grumpy. I prefer happy customers. Okay but: 1. Your customer/customer's customer is the one doing the broken routing here not you.. if he wants to be grumpy you should point him in the direction of the guy who is announcing the bad routes in the first place! 2. If I'm following this, your peer pays your customer? So you are peering with your customer's customer? If that was me I would either depeer them or tell them that you have an issue and need it resolving urgently or you my depeer them. You're not the bad guy here ;) its a pain but you cant stop the customer from doing it.. you can however filter your customers prefix at the IX (an ASN filter would be easiest) In this case, the IX peer had let their transit provider (my customer) source the routes, then later advertised their own routes at the IX using their own ASN (so inconsistent source-as, and my as- path filter missed them). I don't think they were trying to steal bandwidth; just sloppy networking. wow, i think i need a diagram!! :P i don't like sloppy networking, i would depeer anyone who i find is not up to my standards on what makes a 'peer'. this doesnt happen very often but if we want to educate people you can try talking and if that fails take action. I can either build a big import filter, dropping routes offered to me at the IX that are subnets of routes advertised to me by my transit customers (doesn't scale); or just audit customer routes versus peer routes periodically, looking for "bandwidth stealers". It sounds like that is the usual approach. not really, its pretty unusual. now that i understand the picture better tho i think you dont want to be filtering.. 90% of people won't peer with downstreams to avoid this kind of issue.. either you need to do that too or you need to make them fix it (if your peering is valuable to them they will do it) don't forget they are getting a free lunch here, and that is unacceptable. if they are intentionally stealing your bandwidth then that is a major problem, if its an accident then you really should take action and insist they fix it. immediately and temporarily dropping the peering would be a good option Steve
Re: more-specifics via IX
On 15 Oct 2007, at 03:49, Iljitsch van Beijnum wrote: On 15-okt-2007, at 7:09, Bradley Urberg Carlson wrote: There is a customer's customer who is advertising more-specifics at the IX (and using a different source AS, to boot). I can think of a couple ways to prevent hearing these, but thought I should ask for suggestions first. What exactly is the problem? well.. the problem of course is that you pull in the traffic from the aggregate transit prefix which costs you $$$ but then you offload it to the customer via a peering link for which you are not being paid its a pain but you cant stop the customer from doing it.. you can however filter your customers prefix at the IX (an ASN filter would be easiest) if you think it is malicious, you may want to hit them with something official (IANAL) Steve
Re: 240/4
On 16 Oct 2007, at 09:42, Randy Bush wrote: my first thought on how to use it revolved around the idea that the devices inside my site are more diverse than those on the transit internet. therefore, if i can use 240/4 internally, certainly we will all be able to transit it. where this died was the realization that, if i want to transit 240/4, i am expecting all the devices in *your* network to be able to handle 240/4, which is not reasonable. so i guess i come down on the private use side of the how-to-use decision. i would be interested in hearing counter-arguments. yup, this was my conclusion when i had a debate on this a while back think of all the OS protocol stacks out there that may or may not work (you can test it now, try a trace from your windows/linux/bsd/ osx box and see the different results) then even if all vendors start releasing fixed stacks, imagine how many non-upgradable network devices ($20 dsl routers, nat devices etc) are out there that wont work unfortunately i think this is a non-started for all except private deployments the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone. Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote: >How does akamai handle traffic congestion so seamlessly? Perhaps we should >look at existing setups implemented by companies such as akamai for >guidelines regarding how to resolve this kind of issue... and if you are a Content Delivery Network wishing to use a cache deployment architecture you should do just that ... but for networks with big backbones as per this discussion we need to do something else Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Fri, Aug 17, 2007 at 10:54:47AM +0100, Sam Stickland wrote: > > Ted Hardie wrote: > >Fred Baker writes: > > > > > >>Hence, moving a file into a campus doesn't mean that the campus has the > >>file and will stop bothering you. I'm pushing an agenda in the open > >>source world to add some concept of locality, with the purpose of moving > >>traffic off ISP networks when I can. I think the user will be just as > >>happy or happier, and folks pushing large optics will certainly be. > >> > > > >As I mentioned to Fred in a bar once, there is at least one case where you > >have > >to be a bit careful with how you push locality. In the wired campus case, > >he's certainly > >right: if you have the file topologically close to other potentially > >interested users, > >delivering it from that "nearer" source is a win for pretty much everyone. > >This is partly the case because the local wired network is unlikely to be > >resource > >constrained, especially in comparison to the upstream network links. > > > >In some wireless cases, though, it can be a bad thing. Imagine for a > >moment that > >Fred and I are using a p2p protocol while stuck in an airport. We're both > >looking > >for the same file. The p2p network pushes it first to Fred and then > >directs me to get > >it from him. If he and I are doing this while we're both connected to the > >same resource-constrained base station, we may actually be worse off, as > >the > >same base station has to allocate data channels for two high data traffic > >flows while it passes from him to me. If I/the second user gets the file > >from outside the pool of devices connected to that base station, in other > >words, the base station , I, and its other users may well be better off. > > > > > A similar (and far more common) issue exists in the UK where ISPs are > buying their DSL 'last mile' connectivity via a BT central pipe. > Essentially in this setup BT owns all the exchange equipment and the > connectivity back to a central hand-off location - implemented as a L2TP > VPDN. When the DSL customers connects, their realm is used to route > their connection over the VPDN to the ISP. The physical hand-off point > between BT and the ISP is what BT term a BT Central Pipe, which is many > orders of magnitude more expensive than IP transit. > > In this scenario it's more expensive for the ISP to have a customer > retrieve the file from another customer on their network, then it is to > go off net for the file. Hey Sam, thats an excellent point made.. Altho I dont think its unique to UK/BT .. since last mile is recognised as most places as the big cost (in the UK its around 100x the cost of the backbone roughly) .. here anything traversing the last mile is not desirable, especially if it does it twice. Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, Aug 16, 2007 at 10:55:34AM +0100, Alexander Harrowell wrote: >An "Internet variable speed limit" is a nice idea, but there are some >serious trust issues; applications have to trust the network implicitly >not to issue gratuitous slow down messages, and certainly not to use them >for evil purposes (not that I want to start a network neutrality >flamewar...but what with the AT&T/Pearl Jam row, it's not hard to see >rightsholders/telcos/government/alien space bats leaning on your upstream >to spoil your access to content X). > >Further, you're going to need *very good* filtration; necessary to verify >the source of any such packets closely due to the major DOS potential. >Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who >peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets >with a faked source address taken from the IX's netblock...and everything >starts moving Very Slowly. Especially if the suggestion upthread that the >slowdown ought to be implemented 1-2 AS away from the problem is >implemented, which would require forwarding the slowdowns between >networks. > >It has some similarities with the Chinese firewall's use of quick TCP RSTs >to keep users from seeing Bad Things; in that you could tell your machine >to ignore'em. There's a sort of tragedy of the commons problem - if >everyone agrees to listen to the slowdown requests, it will work, but all >you need is a significant minority of the irresponsible, and there'll be >no gain in listening to them. sounds a lot like MEDs - something you have to trust an unknown upstream to send you, of dubious origin, making unknown changes to performance on your network and also like MEDs, whilst it may work for some it wont for others.. a DSL provider may try to control input but a CDN will want to ignore them to maximise throughput and revenue Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Wed, Aug 15, 2007 at 12:58:48PM -0700, Tony Li wrote: > > On Aug 15, 2007, at 9:12 AM, Stephen Wilcox wrote: > > >>Remember the end-to-end principle. IP backbones don't fail with > >>extreme > >>congestion, IP applications fail with extreme congestion. > > > >Hmm I'm not sure about that... a 100% full link dropping packets > >causes many problems: > >[...] > >L3: BGP sessions drop, OSPF hellos are lost.. routing fails > >L2: STP packets dropped.. switching fails > > > It should be noted that well designed equipment will prioritize > control data both on xmit and receive so that under extreme > congestion situations, these symptoms do not occur. Hi Tony, s/will/should/ The various bits of kit I've played with have tended not to cope under a massively maxed out circuit (I dont mean just full, I mean trying to get double the capacity into a link). This includes Cisco and Foundry kit.. not sure with other vendors such as Extreme or Juniper. Often the congestion/flaps causes high CPU, which also can cause failure of protocols on the control plane. Also, if you have something like router-switch-router it may be that the intermediate device looks after its control plane (ie STP) but for example sees BGP as just another TCP stream which it cannot differentiate. Whilst it may be that control plane priority, cpu protection are features now available.. they have not always been and I'm fairly sure are not available across all platforms and software now. And as we know, the majority of the Internet does not run the latest high end kit and software.. Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
Hey Sean,
On Wed, Aug 15, 2007 at 11:35:43AM -0400, Sean Donelan wrote:
> On Wed, 15 Aug 2007, Stephen Wilcox wrote:
> >(Check slide 4) - the simple fact was that with something like 7 of 9
> >cables down the redundancy is useless .. even if operators maintained
> >N+1 redundancy which is unlikely for many operators that would imply
> >50% of capacity was actually used with 50% spare.. however we see
> >around 78% of capacity is lost. There was simply to much traffic and
> >not enough capacity.. IP backbones fail pretty badly when faced with
> >extreme congestion.
>
> Remember the end-to-end principle. IP backbones don't fail with extreme
> congestion, IP applications fail with extreme congestion.
Hmm I'm not sure about that... a 100% full link dropping packets causes many
problems:
L7: Applications stop working, humans get angry
L4: TCP/UDP drops cause retransmits, connection drops, retries etc
L3: BGP sessions drop, OSPF hellos are lost.. routing fails
L2: STP packets dropped.. switching fails
I believe any or all of the above could occur on a backbone which has just
failed massively and now has 20% capacity available such as occurred in SE Asia
> Should IP applications respond to extreme congestion conditions better?
alert('Connection dropped')
"Ping timed out"
kinda icky but its not the applications job to manage the network
> Or should IP backbones have methods to predictably control which IP
> applications receive the remaining IP bandwidth? Similar to the telephone
> network special information tone -- All Circuits are Busy. Maybe we've
> found a new use for ICMP Source Quench.
yes and no.. for a private network perhaps, but for the Internet backbone where
all traffic is important (right?), differentiation is difficult unless applied
at the edge and you have major failure and congestion i dont see what you can
do that will have any reasonable effect. perhaps you are a government
contractor and you reserve some capacity for them and drop everything else but
what is really out there as a solution?
FYI I have seen telephone networks fail badly under extreme congestion. CO's
have small CPUs that dont do a whole lot - setup calls, send busy signals ..
once a call is in place it doesnt occupy CPU time as the path is locked in
place elsewhere. however, if something occurs to cause a serious amount of busy
ccts then CPU usage goes thro the roof and you can cause cascade failures of
whole COs
telcos look to solutions such as call gapping to intervene when they anticipate
major congestion, and not rely on the network to handle it
> Even if the IP protocols recover "as designed," does human impatience mean
> there is a maximum recovery timeout period before humans start making the
> problem worse?
i'm not sure they were designed to do this.. the arpanet wasnt intended to be
massively congested.. the redundant links were in place to cope with loss of a
node and usage was manageable.
Steve
Re: inter-domain link recovery
On Wed, Aug 15, 2007 at 12:06:36PM +0800, Chengchen Hu wrote: > I find that the link recovery is sometimes very slow when failure occures > between different ASes. The outage may last hours. In such cases, it seems > that the automatic recovery of BGP-like protocol fails and the repair is took > over manually. > > We should still remember the taiwan earthquake in Dec. 2006 which damaged > almost all the submarine cables. The network condition was quit terrible in > the following a few days. One may need minutes to load a web page in US from > Asia. However, two main cables luckly escaped damage. Furthermore, we > actually have more routing paths, e.g., from Asia and Europe over the > trans-Russia networks of Rostelecom and TransTeleCom. With these redundent > path, the condition should not be that horrible. Please see the presentation I made at AMSIX in May (original version by Todd at Renesys): http://www.thedogsbollocks.co.uk/tech/0705quakes/AMSIXMay07-Quakes.ppt BGP failover worked fine, much of the instability occurs after the cable cuts as operators found their networks congested and tried to manually change to new uncongested routes. (Check slide 4) - the simple fact was that with something like 7 of 9 cables down the redundancy is useless .. even if operators maintained N+1 redundancy which is unlikely for many operators that would imply 50% of capacity was actually used with 50% spare.. however we see around 78% of capacity is lost. There was simply to much traffic and not enough capacity.. IP backbones fail pretty badly when faced with extreme congestion. > And here is what I'd like to disscuss with you, especially the network > operators, > 1. Why BGP-like protocol failed to recover the path sometimes? Is it mainly > because the policy setting by the ISP and network operators? No, BGP was fine.. this was a congestion issue - ultimately caused by lack of resiliency in cable routes in and out of the region. > 2. What is the actions a network operator will take when such failures > occures? Is it the case like that, 1)to find (a) alternative path(s); > 2)negotiate with other ISP if need; 3)modify the policy and reroute the > traffic. Which actions may be time consuming? Yes, and as the data shows this only made a bad situation worse.. any routes that may have had capacity were soon overwhelmed. > 3. There may be more than one alternative paths and what is the criterion for > the network operator to finally select one or some of them? Pick one that works? But in this case no such option was available. > 4. what infomation is required for a network operator to find the new route? In the case of a BGP change presumably the operator checks that the new path appears to function without latency or delay (a traceroute would be a basic way to check). In terms of a real fix, it cant be done with BGP, you would need to find unused Layer1 capacity and plug in a new cable. Slides 28-31 show that this occurred with Asian networks picking up Westward paths to Europe but it took some manual intervention, time, and money. I think the real question given the facts around this is whether South East Asia will look to protect against a future failure by providing new routes that circumvent single points of failure such as the Luzon straights at Taiwan. But that costs a lot of money .. so the futures not hopeful! Steve
Re: weight vs. volume (95th percentile vs transfer in M/Gbytes)
Hi Jim, well transfer is equivalent to an ordinary average if you want to bring it back into something you can compare.. (so divide by number of seconds in a month and multiply by 8 to get to bits per second) Average pricing should give you better rates as you can do some crazy bursting followed by periods of nothing and pay a fairly low fee that might for a 95%ile push the measured level up.. of course that tends to mean that the prices are a little higher. I usually assume that peak (which for most traffic is equivalent to 95%) is about 3x the average. Ultimately tho these are different techniques and you should bear in mind the above and then apply it to your own situation to work out whether this would represent a cheap or expensive solution. If you do the conversion to average tho this should be easy to read off your current RRD graphs to work out a price comparison :) Steve On Wed, Aug 08, 2007 at 11:03:11AM -0400, Jim Mercer wrote: > > > over the years, i've grown quite accustomed to feeling out pricing of > bandwidth > based on 95th percentile peak utilization with various minimums and potential > tiers. > > i've always sorta viewed pricing by "bytes transferred" to be a consumer thing > that my uncle might pay when hosting his webpages showing his matchbox > collection. > > now i'm faced with a jurisdiction where the only providers (all 2 of them) > will > only give pricing in "bytes transferred". > > they are not interested in giving me pricing based on 95th percentile, and > as such i'm having a tough time budgetting for some of my applications. > (pisses me off because i'm sure _they_ are paying by 995th percentile) > > with 95th percentile, i could always trottle down the applications or figure > out what my estimated `overage might be. > > has anyone got a formula for comparing 95th percentile billing with bytes > transferred? > > -- > Jim Mercer[EMAIL PROTECTED]+971 55 410-5633 > "I'm Prime Minister of Canada, I live here and I'm going to take a leak." >- Lester Pearson in 1967, during a meeting between himself and > President Lyndon Johnson, whose Secret Service detail had taken over > Pearson's cottage retreat. At one point, a Johnson guard asked > Pearson, "Who are you and where are you going?"
Re: 40Gbit private peer
Hi Peter, Whilst I think there are some merits to for example the 40G to your mother's place via a new technology I'm not entirely sure what this represents. We know 40G interfaces exist and that any pair of interfaces will come up at 40G. Indeed you could have bonded 16x10G and claimed 160Gb peering. But with nothing behind them, you may as well add IPv8 and IPv9 and ipx as firsts too. :) Steve On Thu, Aug 02, 2007 at 06:44:32PM +0200, Peter Lothberg wrote: > > > SUnet (AS1653) and STUPI (AS1880) want to announce that > we have brought up what we believe is the first private > peer at 40G between two independent networks. > > It speaks IPv4, IPv6 both unicast and multicast. > > -Peter > > > > RP/0/RP0/CPU0:HFR1-F#sh int pos 0/3/0/0 > POS0/3/0/0 is up, line protocol is up > Interface state transitions: 2 > Hardware is Packet over SONET/SDH > Description: OC768 Private Peering to Sunet <[EMAIL PROTECTED]> > Internet address is 193.11.20.146/30 > MTU 4474 bytes, BW 39813120 Kbit > reliability 255/255, txload 0/255, rxload 0/255 > Encapsulation HDLC, crc 32, controller loopback not set, keepalive set (10 > sec) > Last clearing of "show interface" counters 1d00h > 30 second input rate 77849000 bits/sec, 7236 packets/sec > 30 second output rate 17464000 bits/sec, 5023 packets/sec > 115627177 packets input, 155140727534 bytes, 0 total input drops > 0 drops for unrecognized upper-level protocol > Received 0 runts, 0 giants, 0 throttles, 0 parity > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 78946374 packets output, 34499886901 bytes, 0 total output drops > 0 output errors, 0 underruns, 0 applique, 0 resets > 0 output buffer failures, 0 output buffers swapped out > > RP/0/RP0/CPU0:HFR1-F#sh controllers soNET 0/3/0/0 > Port SONET0/3/0/0: > > Status: Up > > Loopback: None > > SECTION > LOF = 0 LOS= 0BIP(B1) = 0 > LINE > AIS = 0 RDI= 0 FEBE = 0 BIP(B2) = 0 > PATH > AIS = 0 RDI= 0 FEBE = 0 BIP(B3) = 0 > LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 > PLM = 0 TIM= 0 > Detected Alarms: None > Asserted Alarms: None > Mask for Detected->Asserted: None > Detected Alerts: None > Reported Alerts: None > Mask for Detected->Reported: None > Alarm reporting enabled for: SLOS SLOF SF_BER PLOP > Alert reporting enabled for: B1-TCA B2-TCA B3-TCA > > Framing: SONET > SPE Scrambling: Enabled > C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling Derived > S1S0(tx): 0x0 S1S0(rx): 0x0 / Framing Derived > > PATH TRACE BUFFER : STABLE > Remote hostname : c1sth-re1 so-7/0/0 > Remote interface: > Remote IP addr : > > APS > No APS Group Configured > Protect Channel 0 DISABLED > Rx(K1/K2) : 0x00/0x00 > Tx(K1/K2) : 0x00/0x00 > Remote Rx(K1/K2): 1/Remote Tx(K1/K2): 1/ > > > BER thresholds: SF = 10e-3 SD = 10e-6 > TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 > > Optics type: VSR2000-3R2 (2km) > Clock source: internal (actual) internal (configured) > > Optical Power Monitoring (accuracy: +/- 1dB) > Rx power = 1.3796 mW, 1.4 dBm > Tx power = 1.7380 mW, 2.4 dBm > Tx laser current bias = 58.3 mA
Re: An Internet IPv6 Transition Plan
On Tue, Jul 31, 2007 at 10:12:28PM +0200, Peter Dambier wrote: > > Scott Francis wrote: > >On 7/29/07, Peter Dambier <[EMAIL PROTECTED]> wrote: > > > > > >>Ways have been found to drill holes into NAT-routers and firewalls, > >>but they are working only as long as it is only you who wants to break > >>out of the NAT. As soon as the mainstream has only left rfc 1918 addresses > >>p2p will stop. > > > > > >really? > > > >http://samy.pl/chownat/ > > > >NAT stops nothing. The concept in the above script (which has been > >around for several years) would be trivial for any P2P software to > >implement if it detects it is behind a NAT; in fact, this method may > >well be in use already. > > > I have read that is what skype is doing and probably some troyans. > > Still you have to "talk" to your NAT-router and the other party has > to talk to their NAT-router to make those two NAT-routers talk to > each other. When those two router cannot see each other because > they too are living behind NAT then you have got a problem. > > I guess you can solve it but the number of ports is limited and > things get a lot trickier. When you try to get out of the big NAT > (china) then the number of available ports versus the number of > users who want to get out - is the limit. Firstly, all p2p nets use some process to register with the network. It is simple to imagine a way to ensure these superpeers are publically addressed and let them coordinate the NATted hosts. Secondly, there is no big NAT in china. And even if there was, very large private networks should flourish for p2p sharing amongst each other. I think you're trying to demonstrate NAT to be a security mechanism and its long been known that that is not the case. Steve
Re: An Internet IPv6 Transition Plan
On Sun, Jul 29, 2007 at 10:50:10AM +0200, Peter Dambier wrote: > > Petri Helenius wrote: > > > >Stephen Wilcox wrote: > > > >>Now, if you suddenly charge $2.50/mo to have a public IP or $15/mo for > >>a /28 it does become a consideration to the customer as to if they > >>_REALLY_ need it > >> > > > >Where would this money go to? you could subsidise all those v6 rollouts everyone is talking about ;p seriously, figuring out what to do with some spare money shouldnt be a big concern.. if we dont pool it centrally under collective authority then what pete says below will happen: > To ip-squatters. > > Get your allocation now and turn it into gold tommorow. > > p2p people will be happy if they can get rid of their tunnels. > With rfc 1918 addresses for all there will be no more > filesharing, voip, spam and troyans. really? because p2p doesnt work behind NAT, and computers behind NAT dont get infected? this is the Internet today and NAT has no effect on the above. Steve
Re: An Internet IPv6 Transition Plan
On Thu, Jul 26, 2007 at 01:25:51PM -0400, John Curran wrote: > At 2:01 PM +0100 7/26/07, Stephen Wilcox wrote: > >well, the empirical data which is confirmed here is saying that those 10% > >are burning most of the v4 addresses and we are not seeing them rollout v6 > >whether they 'need to' or not > > Wow... you mean that they're not announcing general IPv6 > availability two years before they have to? I'm so surprised. ;-) they need to be announcing availability well in advance of a forced need to transition and based on the projected timescales 2 yrs in advance has already passed them by > >so you sound right in theory, but in practice your data doesnt show that is > >occuring and it also suggests those 10% are actively supporting 'the wall' > >approach. > > The number of major backbone operators looking into IPv6 is already > quite high, and will likely approach 100%. The alternative is carriers > having to explain to the analyst community that they lack a business > plan for new data customer growth once large IPv4 blocks are no longer > generally available. ah yes of course.. looking into, producing reports. but where are they at really? : - how many of those have obtained address space sufficient to cover their customer base already? - how many of those networks have made the trivial step of announcing their v6 blocks in BGP? - how many of them have already got native v6 running in their backbones and on their services (mail, dns etc).. fundemental advance prerequisites to any complicated end user deployment i think the number with one of the above is a reasonable percentage, with two of the above is small and three of the above.. are there any? Steve
Re: An Internet IPv6 Transition Plan
On Thu, Jul 26, 2007 at 06:21:59AM -0400, John Curran wrote: > At 11:18 AM +0100 7/26/07, Stephen Wilcox wrote: > > > >um, so thats consistent with what i said.. in fact it implies only a very > >small number of organisations need to pay close attention and those are the > >ones best suited to implementing policy changes to ensure their users > >continue to have a good service > > > >this means 90% of orgs can probably wait and see what the 10% do first.. > > Completely incorrect. In order that we can continue to have > reasonable routing growth during new customer add, those > 10% need to move to IPv6. While you don't have to move > your entire infrastructure to IPv6, you need to add IPv6 to > the public-facing servers that you'd like to still be Internet > connected. well, the empirical data which is confirmed here is saying that those 10% are burning most of the v4 addresses and we are not seeing them rollout v6 whether they 'need to' or not so you sound right in theory, but in practice your data doesnt show that is occuring and it also suggests those 10% are actively supporting 'the wall' approach. Steve
Re: Why do we use facilities with EPO's?
On Wed, Jul 25, 2007 at 07:47:48PM -0400, David Lesher wrote: > I've never designed or looked into a EPO installation; but I'm > astonished such does not use a Normally-Closed pushbutton in a > fail-to-off circuit. > > Similarly... > > If you have electric locks on your exit doors; every installation > I have seen has a couple of such aspects: > > a) You must have an exit override. If an electric strike, an > interior knob is good. If a [Locknetics-style] mag-lock, you > need an exit button. That button SHALL be a NC pushbutton in > series with the magnet. [In other words... No, you can't have > the pushbutton connected back to some controller box on the 3rd > floor where it generates an interupt that will drop the lock > power... or it's supposed to...] Sorry I've seen a few that dont have an exit override. > b) When the building fire drop is pulled, you SHALL drop the lock > power to the mag locks. I've seen at least one that does not do this. > And while local fire codes vary widely; given those were in the > rules for a USG SCIF I worked in; I somehow doubt you'll be able > to get more lenient treatment based on the import of the data > center's operation. That depends on a bunch of criteria.. override buttons and failure when power goes out create significant security risks. If you are a bank or have very secure data then you might consider these to be ways in which an intruder might compromise your security. >From what I've seen tho, when you remove the ability to exit in this way then >you also find you have a lot of control procedures imposed to avoid >unnecessary risk to employees or visitors. Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 06:15:23PM -0500, Iljitsch van Beijnum wrote: > On 25-jul-2007, at 6:30, Stephen Wilcox wrote: > > >I think the combined effect of these things means > >- we will not be running into a wall at any time > >- availability of IPs will slowly decrease over time (as cost > >slowly increases) > > I have to disagree here. 10% of the requests are for 90% of the 170 - > 200 million IPv4 addresses given out per year. These are going to > large broadband ISPs in blocks of a quarter million or (much) larger, > upto /8. At some point, the RIRs will be out of large enough blocks > to satisfy these requests. Nothing to be done about that. um, so thats consistent with what i said.. in fact it implies only a very small number of organisations need to pay close attention and those are the ones best suited to implementing policy changes to ensure their users continue to have a good service this means 90% of orgs can probably wait and see what the 10% do first.. Steve
Re: ASN Name of the week
On Wed, Jul 25, 2007 at 04:20:25PM +0100, Carlos Friacas wrote: > > On Wed, 25 Jul 2007, Tuc at T-B-O-H.NET wrote: > > >>Hi, > >> > >>ASNV6, no clue... but 32-bit ASN are already prepared, at least in > >>the registry world. > >> > > It was just a joke, since the AS is getting high up there > >in the 2 byte range (2/3's of the available ones down I think) and > >was implying that moving to 4 byte would be as fast/efficient/complete > >as going to IPV6 (Not...) > > That's actually something funny.. > We'll probably run out of v4 addresses sooner than 2 byte ASN, however, > globally it seems more pieces of the puzzle are in place for the latter > "revolution". I doubt most routers are 4 byte ASN aware, but the difference is no 'revolution' is required as 4 byte is designed to cross silently across any 2 byte only routers without needing any upgrade by nature of BGPv4s flexibility Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 08:18:30AM -0400, John Curran wrote: > At 1:15 PM +0100 7/25/07, Stephen Wilcox wrote: > > > >> At present, there's a few years for these folks to switch to IPv6 for > >> their growth. It requires cooperation from the Internet, in that we > >> all need to recognize that there will be IPv6 customers out there soon, > >> and even if you don't plan on having those, please make your public > >> facing servers IPv6 reachable in the next few years. > > > >I'm not sure there is time for v6 to be ready before companies find > >different ways to manage this. There are many things that need to happen to > >enable v6 and I dont think any of them are happening in a big way. Whether > >the large CDNs deploy v6, if v6 can be purchased in volume as transit are > >likely to be the major factors.. > > Steve - > >Are you unable to make your public facing servers IPv6-reachable? Well, I wear a few hats these days :) but.. I think the short answer is yes, I'm unable. Most stuff I am involved in is modern enough that the servers have a v6 stack so that could be enabled. But the apps themselves are not all v6 so they would either need to be upgraded or fixed. We would of course need to configure these and ensure all dependncies are v6 capable, particularly if we're sending address info back to customers we dont want to switch them in and out of v4/v6. Then the network gear tends to be v6 enabled in the core and not at the edges where older gear has been redeployed. And a lot of the gear that claims to be v6 doesnt handle hardware switching properly so that needs investigating and would be an issue. Then we'd need to make sure all security and policies are uniform and working equally across v6. Assuming we sort it tho then we need to bring up v6 transit, more v6 peers and drop any v4 tunnels as they cant be expected to handle production load. I guess theres abstraction to fix too - my CMS, monitoring, allocation, much of which is automated and all of which relies on storing address info would all need to be rewritten to allow v6 addresses on hosts, interfaces, customers etc So fix all that and yes we could have v6 servers, but you also said reachable and according to my BGPv6 table theres very little reachable out there right now - about 700 prefixes when compared to 25000 v4 ASNs that should each be visible. So you can break this into two elements - stuff I control and stuff I dont. For the stuff I control I think the summary is that I'd need to build an ISP from scratch essentially (if not in terms of capex purchases then certainly in terms of design and implementation). And the stuff I dont control, well.. I cant do much about that. Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 12:21:04PM +0100, [EMAIL PROTECTED] wrote: > > > > Lack of IPv4 addresses will put the brakes on growth of the > > Internet > > > which will have a major impact on revenue growth. Before long stock > > > market analysts are going to be asking tough questions, and > > CEOs are > > > suddenly going to see the IPv6 light. > > > > What exactly will cease to grow tho? The 4 billion IPs that > > have always been around will continue to be. I think you > > overestimate the effects.. > > I think you misunderstand the dictionary definition of growth. Yes, the > IPv4 addresses, and much of the network infrastructure using them, will > continue to be. But growth is about expansion, adding more, increasing > the size and scope of the network. Few businesses are satisfied with > collecting the same monthly recurring revenue from the same customer > base. They either want to grow the customer base or grow the monthly > revenue per customer. In the Internet business the main engine of > revenue growth is growing the customer base by growing the network and > adding more customers. I dont think paypal's growth is tied to how many IPs they have... I think it relates to how many hits www.paypal.com receives and what their products look like. IP availability is unlikely to ever have more than the briefest mention in the boardroom and probably only in response to a news article quoting the end of the internet being imminent. > > And as I've been saying > > for a while and Randy put in his presentation, supply and > > demand will simply cause the cost of having public IPs to go > > up from zero to something tiny - enough to see IPs being put > > back into the pool to those who really need them. > > And when your Internet supplier tells you that there will be a $10 per > month increase in fees to cover the increase cost of IPv4 addresses, > will you be happy? Will you start shopping for an IPv6 Internet > supplier? When IPv6 Internet access is cheaper due to IPv4 address > costs, then ISPs face a wholesale loss of their customer base. Of > course, most business managers are smart enough to see this coming and > resist paying for IPv4 addresses in the first place. I'll sell you v6 today for 1/4 of the price of v4. Providing you understand theres not a lot out there. I agree on your cost comparison, but consider what investment and costs are needed to be able to get to that point. > this model of business. When the IPv4 shortage begins to bite, then you > will see enormous amounts of money and effort put into IPv6 conversions > (and new IPv6 startups who intend to unseat Google, Yahoo, etc.). You will just see redeployment of existing budgets.. why would you pay more to see the same webpage be delivered just because of some techno mumbo jumbo Any investor would be crazy to invest in a v6 competitor to Google.. enter a mature market using a new technology that 99% of the planet cant get to? The only folks getting into v6 are the ones controlling the v4 market with enough spare R&D cash currently. Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 07:50:05AM -0400, John Curran wrote: > At 12:30 PM +0100 7/25/07, Stephen Wilcox wrote: > >Hi John, > > I fully agree on that.. but I am disagreeing as to the timescales. > > > >There is some opinion that when IANA hands out the last of its IP blocks > >things will change overnight, and I dont see any reason for that to be the > >case. I think there are a lot of IPs currently allocated to ISPs but as yet > >unassigned to customers, and I think there will be a lot of policy changes > >to make more efficient use of the space that is already out there - I > >specifically think that will come from ISPs reusing IPs and setting costs > >that ensure they continually have IPs available to customers willing to pay > >for them. > > In the ARIN region, we've got major ISP's coming back > every 6 months with high utilization rates seeking their > next block to allow customer growth. While I'm certain > that some internal recovery is possible, there's a realistic > limit of how long any ISP can make their air supply last. > > >I think the combined effect of these things means > >- we will not be running into a wall at any time > >- availability of IPs will slowly decrease over time (as cost slowly > >increases) > >- adoption of NAT and v6 will be an ongoing trend with no sudden increase > > Unless the policy changes you suggest somehow dramatically > change the current usage rate, we're going to have a very > serious rate of change when the IANA/RIR pool hits zero. > That sort of defines "hitting a wall", by my definition. Well, you already say you have major ISPs submitting requests every 6 months, and I guess that is your high water mark so everyone else should be longer (at lease here under RIPE you are supposed to be allocated space for 2 yrs at a time). So, we have IANA out of space at eof 2009.. that will then take the RIRs 12 to 24 mo to allocate that out before there is any impact on ISPs. Once that occurs we still have your 6mo-2yr+ period that ISPs have in their allocated and unused pool to be giving to customers. Add all that together and you have 18mo-4yrs of 'greyness', no overnight wall. And I'm saying each of the events plus that grey period will cause evolution in the market place to occur such that there are no walls or catastraphies from a continuity or economical point of view. > Please propose the magical policy changes asap... we need to > get them through the public process and adopted in record time > to have any affect on the usage rate. Well, thats a different story. Inflating the price of IPs would have been a good thing but I think that horse has already bolted now. > >This means no end of the world as we know it, and no overnight adoption of > >new technology.. just business as usual in an evolving environment. > > Note: I'm not advocating an "overnight" technology deployment; > just advising those folks who presently rely on continuous availability > of new address blocks from the RIR's that we're going to see a change. Indeed they will, but it wont happen to everyone at the same time (as they all have months or years of IPs left) and they have plenty of time to figure out how to adapt their products and business models. > At present, there's a few years for these folks to switch to IPv6 for > their growth. It requires cooperation from the Internet, in that we > all need to recognize that there will be IPv6 customers out there soon, > and even if you don't plan on having those, please make your public > facing servers IPv6 reachable in the next few years. I'm not sure there is time for v6 to be ready before companies find different ways to manage this. There are many things that need to happen to enable v6 and I dont think any of them are happening in a big way. Whether the large CDNs deploy v6, if v6 can be purchased in volume as transit are likely to be the major factors.. Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 07:52:19PM +0800, Adrian Chadd wrote: > On Wed, Jul 25, 2007, Stephen Wilcox wrote: > > > > Lack of IPv4 addresses will put the brakes on growth of the Internet > > > which will have a major impact on revenue growth. Before long stock > > > market analysts are going to be asking tough questions, and CEOs are > > > suddenly going to see the IPv6 light. > > > > What exactly will cease to grow tho? The 4 billion IPs that have always > > been around will continue to be. I think you overestimate the effects.. > > > > All the existing big businesses can operate with what they already have, > > Google and Yahoo are not going to face any sort of crisis for the > > foreseeable future. And as I've been saying for a while and Randy put in > > his presentation, supply and demand will simply cause the cost of having > > public IPs to go up from zero to something tiny - enough to see IPs being > > put back into the pool to those who really need them. > > I'm not sure what your definition of "really tiny" is, but out here > IPs are a dollar or two each a year from APNIC. I'm sure ARIN's IP > charges aren't $0.00. RIPE is a couple thousands Euros to be an LIR which gets you all the IPs you need.. $1/yr is like 8c/month - well into the realm of being sunk into the cost when you provide a hosting service or DSL line. Its close enough to zero to be lost in the overheads of any business operation. Now, if you suddenly charge $2.50/mo to have a public IP or $15/mo for a /28 it does become a consideration to the customer as to if they _REALLY_ need it Steve
Re: An Internet IPv6 Transition Plan
On Wed, Jul 25, 2007 at 07:14:49AM -0400, John Curran wrote: > At 11:52 AM +0100 7/25/07, Stephen Wilcox wrote: > >On Tue, Jul 24, 2007 at 09:34:01PM +0100, [EMAIL PROTECTED] wrote: > >> > >> > However, what I'm trying to understand is why the motivation > >> > to rapidly go from v4 to v6 only? What are the factors I'm > >> > missing in operating v4/v6 combined for some time? > >> > >> Growth. > >> > >> Lack of IPv4 addresses will put the brakes on growth of the Internet > >> which will have a major impact on revenue growth. Before long stock > >> market analysts are going to be asking tough questions, and CEOs are > >> suddenly going to see the IPv6 light. > > > >What exactly will cease to grow tho? The 4 billion IPs that have always been > >around will continue to be. I think you overestimate the effects.. > > > >All the existing big businesses can operate with what they already have, > >Google and Yahoo are not going to face any sort of crisis for the > >foreseeable future. And as I've been saying for a while and Randy put in his > >presentation, supply and demand will simply cause the cost of having public > >IPs to go up from zero to something tiny - enough to see IPs being put back > >into the pool to those who really need them. > > Steve - > >Putting them back into circulation doesn't work unless >its done in very large chucks to major ISPs. If this isn't >the model followed, then we will see a lot more routes >for the equivalent number of new customers. People >complaining about the ability to carry both IPv6 and >IPv4 routing need to think carefully about how long >we'll actually last if the ISP's are injecting thousands >of unaggregatable routes from recovered address space >each day. > >Additionally, the run rate for IPv4 usage approximates >10 /8 equivalents per year and increasing. Even given >great legacy recovery, you've only gained a few more >years and then still have to face the problem. Hi John, I fully agree on that.. but I am disagreeing as to the timescales. There is some opinion that when IANA hands out the last of its IP blocks things will change overnight, and I dont see any reason for that to be the case. I think there are a lot of IPs currently allocated to ISPs but as yet unassigned to customers, and I think there will be a lot of policy changes to make more efficient use of the space that is already out there - I specifically think that will come from ISPs reusing IPs and setting costs that ensure they continually have IPs available to customers willing to pay for them. I think the combined effect of these things means - we will not be running into a wall at any time - availability of IPs will slowly decrease over time (as cost slowly increases) - adoption of NAT and v6 will be an ongoing trend with no sudden increase This means no end of the world as we know it, and no overnight adoption of new technology.. just business as usual in an evolving environment. Steve
Re: San Francisco Power Outage
On Tue, Jul 24, 2007 at 11:57:37PM +, Paul Vixie wrote: > > [EMAIL PROTECTED] (Seth Mattinen) writes: > > > I have a question: does anyone seriously accept "oh, power trouble" as a > > reason your servers went offline? Where's the generators? UPS? Testing > > said combination of UPS and generators? What if it was important? I > > honestly find it hard to believe anyone runs a facility like that and > > people actually *pay* for it. > > > > If you do accept this is a good reason for failure, why? > > sometimes the problem is in the redundancy gear itself. PAIX lost power > twice during its first five years of operation, and both times it was due > to faulty GFI in the UPS+redundancy gear. which had passed testing during > construction and subsequently, but eventually some component just wore out. I had an issue with exactly that 7 or 8 years ago at Via Networks.. the switchover gear shorted and died horrifically leading to an outage that lasted well through the night (something like 16hours in total). Being on a Friday evening it was difficult to get people on site promptly. The lesson learned was 'the big switch' .. a huge thing that took the weight of two adults to move it, but did mean that should something similar occur we could transfer the whole building power manually directly to the generator. I doubt such a beast would scale to the power loads on a large datacentre tho, but then they are generally not on a single grid/UPS feed. Steve
Re: An Internet IPv6 Transition Plan
On Tue, Jul 24, 2007 at 09:34:01PM +0100, [EMAIL PROTECTED] wrote: > > > However, what I'm trying to understand is why the motivation > > to rapidly go from v4 to v6 only? What are the factors I'm > > missing in operating v4/v6 combined for some time? > > Growth. > > Lack of IPv4 addresses will put the brakes on growth of the Internet > which will have a major impact on revenue growth. Before long stock > market analysts are going to be asking tough questions, and CEOs are > suddenly going to see the IPv6 light. What exactly will cease to grow tho? The 4 billion IPs that have always been around will continue to be. I think you overestimate the effects.. All the existing big businesses can operate with what they already have, Google and Yahoo are not going to face any sort of crisis for the foreseeable future. And as I've been saying for a while and Randy put in his presentation, supply and demand will simply cause the cost of having public IPs to go up from zero to something tiny - enough to see IPs being put back into the pool to those who really need them. Steve
Re: How should ISPs notify customers about Bots (Was Re: DNS Hijacking
On Tue, Jul 24, 2007 at 12:00:40PM -0500, Joe Greco wrote: > > > Yes there are a few bots around still using IRC but a lot of them have > > moved to other, better things (and there's fun "headless" bots too, > > hardcoded with instructions and let loose so there's no C&C, no > > centralized domain or dynamic dns for takedown.. you want to make a > > change? just release another bot into the wild). > > Hardly unexpected. The continuing evolution is likely to be pretty > scary. Disposables are nice, but the trouble and slowness in seeding > makes them less valuable. I'm expecting that we'll see > compartmentalized bots, where each bot has a small number of neighbors, > a pseudo-scripting command language, extensible communication ABI to > facilitate the latest in detection avoidance, and some basic logic to > seed/pick neighbors that aren't local. Build in some strong > encryption, have them each repeat the encrypted orders to their > neighbors, and you have a structure that would be exceedingly > difficult to deal with. > > Considering how long ago that sort of model was proposed, it is actually > remarkable that it doesn't seem to have been perfected by now, and that > we're still blocking IRC. Thats because there is a huge world out there of badly protected hosts just waiting to become bots and a fairly basic set of tactics being deployed to prevent them. ie until globally it is somewhat more difficult to build a botnet there is no need to develop complicated solutions. the simpler ones are proven, easy to roll out, easy to modify. its just supply and demand... Steve
Re: How should ISPs notify customers about Bots (Was Re: DNS Hijacking
On Mon, Jul 23, 2007 at 02:48:05PM -0500, Joe Greco wrote: > > > On 7/23/07, Joe Greco <[EMAIL PROTECTED]> wrote: > > > All right, here we go. Please explain the nature of the bot on my freshly > > > installed (last night) FreeBSD 6.2R box. > > > > %age of freshly installed freebsd 6.2R boxes v/s random windows boxes > > on cox cable? > > That's fairly irrelevant. The fact is that this isn't targetting infected > boxes, it's targetting everyone. its relevant because you specified freebsd and hence it becomes necessary to consider what % of users have freebsd boxes and how many of those are infected > > Like anything else, its a numbers game. > > All of computing is a numbers game. That doesn't make it right to go around > breaking random services just because it might fix some random problem. "right" .. whats that then? you're buying a product, you have T&Cs, you are protected by consumer law.. what moral of society is being breached for it not to be "right"? and neither the services are random or the problem. they are quite specific and the solution has been calculated to be the path of least resistance for the whole. you sound a lot like a consumer more than a network operator.. i'm not saying i would like what cox do if i were a consumer of theirs but they are dealing with an issue on their subscription service and they dont seem to be doing anything particularly radical do you have a better suggestion for them? incidentally, if you are a consumer and a tech-savvy one, why dont you just circumvent the restriction? Steve
Re: DNS Hijacking by Cox
On Sun, Jul 22, 2007 at 02:56:13PM -0700, Andrew Matthews wrote: > > It looks like cox is hijacking dns for irc servers. > isn't there a law against hijacking dns? What can i do to persue this? no, its their network and they play by their rules.. the law would prevent them from inserting data into 3rd party servers or from masquerading as someone they are not or other marketing unfairness (such as serving their site in place of their competitors). if you are a cox customer you might want to have a reasoned discussion with them and find out more details and whether you can reach a resolution. if they dont play ball tho you ultimately would have to vote with your $$ and switch.. Steve
Re: TCP congestion
On Thu, Jul 12, 2007 at 10:54:56PM +0200, Iljitsch van Beijnum wrote:
> On 12-jul-2007, at 22:27, Philip Lavine wrote:
>
> >I just don't understand how if there is 1 segment that gets lost
> >how this could translate to such a catastrophic long period of slow-
> >start. How can I minimize the impact of the inevitable segment
> >loss/out of order over a WAN. Is QoS the only option?
>
> Also note that minimal amounts of cell loss on ATM create huge
> amounts of packet loss at the IP layer.
from the phrases used ('catastrophic') my feeling is that perhaps Philip isnt
understanding that on a high speed TCP transfer a single missing bit of data
can cause the whole thing to stop and restart transmission from slow
Steve
Re: TCP congestion
Well, if its out of order its the same as if its lost or delayed, it needs to see that missing segment before the window is full As mentioned you need to get dumps from both ends, you will almost definitely find that you have packet loss which tripped tcp's slow start mechanism. Steve On Thu, Jul 12, 2007 at 12:02:49PM -0700, Philip Lavine wrote: > > Even if the segment was received out of order what would cause congestion > avoidance to starve the connection of legitimate traffic for 15 to 20 > seconds? That is the core of the problem. > > - Original Message > From: Fred Baker <[EMAIL PROTECTED]> > To: Brian Knoll <[EMAIL PROTECTED]> > Cc: Philip Lavine <[EMAIL PROTECTED]>; nanog > Sent: Thursday, July 12, 2007 11:56:06 AM > Subject: Re: TCP congestion > > > On Jul 12, 2007, at 11:42 AM, Brian Knoll ((TTNET)) wrote: > > > If the receiver is sending a DUP ACK, then the sender either never > > received the first ACK or it didn't receive it within the timeframe it > > expected. > > or received it out of order. > > Yes, a tcpdump trace is the first step. > > > > > > > > Be a better Globetrotter. Get better travel answers from someone who knows. > Yahoo! Answers - Check it out. > http://answers.yahoo.com/dir/?link=list&sid=396545469
Re: peter lothberg's mother slashdotted
I guess the question is can she actually get any content to download > 1Gbps? :) They cite this as worlds fastest home broadband but didnt Peter install an OC-768 to his basement a few years ago when he was testing some stuff for Sprint? Steve On Thu, Jul 12, 2007 at 06:17:52PM +, Paul Vixie wrote: > > http://slashdot.org/article.pl?sid=07/07/12/1236231 > > http://www.thelocal.se/7869/20070712/
Re: ICANN registrar supporting v6 glue?
On Sat, Jun 30, 2007 at 11:16:40PM +1000, Mark Andrews wrote: > > >Barrett Lyon wrote: > >>=20 > >> Apparently GoDaddy does not support v6 glue for their customers, who > >> does? I don't think requiring dual-stack v6 users perform v4 queries t= > >o > >> find records is all that great. > > > >At least eNom does. > > > >There are a few others but it tends to be that you have to raise a > >support ticket to actually get the records in, most webinterfaces don't > >support it yet unfortunately. > > > >One note here is that even though you can get glue into com/net/org > >using this method, there is no IPv6 glue for the root yet, as such even > >if you manage to get the IPv6 glue in, it won't accomplish much (except > >sending all IPv6 capable resolvers over IPv6 transport :) as all > >resolvers will still require IPv4 to reach the root. One can of course > >create their own root hint zone and force bind, or other dns server, to > >not fetch the hints from the real root, but that doesn't help for the > >rest of the planet. (Root alternatives like orsn could fix that up but > >apparently their main german box that was doing IPv6 is out of the air) > > You don't change the hints you just provide zones that override > B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, > K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your > own ROOT-SERVERS.NET zone with the s added in. I've read your email twice and I dont follow. Either you are telling me a) Provide my own hints with included (you specifically say thats not what you mean tho) or b) Serve my own root zone. From a root operator, surely thats not right either (I hope!)? > In the few couple of years I've only seen two outages with the > IPv6 root instances. In both cases they were fixed soon after > reporting the outage. So there are v6 roots out there? Where are they hiding and why arent they being provided in the hints file or NS queries on . ? Steve > > B.ROOT-SERVERS.NET. 3600IN A 192.228.79.201 > B.ROOT-SERVERS.NET. 3600IN 2001:478:65::53 > F.ROOT-SERVERS.NET. 3600IN A 192.5.5.241 > F.ROOT-SERVERS.NET. 3600IN 2001:500::1035 > H.ROOT-SERVERS.NET. 3600IN A 128.63.2.53 > H.ROOT-SERVERS.NET. 3600IN 2001:500:1::803f:235 > K.ROOT-SERVERS.NET. 3600IN A 193.0.14.129 > K.ROOT-SERVERS.NET. 3600IN 2001:7fd::1 > M.ROOT-SERVERS.NET. 3600IN A 202.12.27.33 > M.ROOT-SERVERS.NET. 3600IN 2001:dc3::35 > > >Note also that various ccTLD's are able to add glue to your zone on > >request (notably .fr/.ch/.nl/.se do so already for quite some time) > > > >Greets, > > Jeroen > > > > > >--enig28DE1EA6E1A720C65610D130 > >Content-Type: application/pgp-signature; name="signature.asc" > >Content-Description: OpenPGP digital signature > >Content-Disposition: attachment; filename="signature.asc" > > > >-BEGIN PGP SIGNATURE- > >Version: GnuPG v1.4.7 (MingW32) > >Comment: Jeroen Massar / http://unfix.org/~jeroen/ > > > >iHUEARECADUFAkaFMZMuFIAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy > >b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Ixw1AKC8ycHIGT3Nzs296Xf4XeeDvq+m > >agCeM0cnyTZxnh0QbnuQXVwhw2kil1o= > >=UGVO > >-END PGP SIGNATURE- > > > >--enig28DE1EA6E1A720C65610D130-- > >
Re: v6 multihoming (Re: The Choice: IPv4 Exhaustion or Transition to IPv6)
Hi Nicolas, you will never make 2GB of traffic go down one STM4 or even 3x STM4! But you are asking me about load balancing amongst 3 upstreams... Deaggregation of your prefix is an ugly way to do TE. If you buy from carriers that support BGP communities there are much nicer ways to manage this. I've never deaggregated and I have had and do have individual prefixes that generate more traffic than any single GE link. Steve On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: > Hi Stephen, > > Supose you have STM4 links, ok? > And you have 2G of trafic from your 10 ADSL customers, ok? > And those STM4 go to 3 dif carriers in USA. > Then, how you advertise only one IPv6 prefix to all and make the 2G go > trough one STM4 ? > > > On Fri, 29 Jun 2007, Stephen Wilcox wrote: > > steve. > > steve. >Hi Christian, > steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in > v6 and destruction ov DFZ are correlated. > steve. > > steve. >If you took everything on v4 today and migrated it to v6 tomoro the > routing table would not grow - actually by my calculation it should shrink > (every ASN would only need one prefix to cover its current and anticipated > growth). So we'll see 22 routes reduce to 25000. > steve. > > steve. >The technology we have now is not driving multihoming directly and v4 > vs v6 is not a factor there. > steve. > > steve. >So in what way is v6 destroying DFZ? > steve. > > steve. >Steve > steve. > > steve. >On Fri, Jun 29, 2007 at 02:13:50PM +, Christian Kuhtz wrote: > steve. >> > steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls > I must be. > steve. >> > steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is > trivial. And you should go ahead and plan that migration. > steve. >> > steve. >> As you well known, one of the core assumptions of IPv6 is that the > DFZ policy stay intact, ostensibly to solve a very specific scaling problem. > steve. >> > steve. >> So, go ahead and continue talking about migration while ignoring > the very policies within which that is permitted to take place and don't let > me interrupt that ranting. > steve. >> > steve. >> Best Regards, > steve. >> Christian > steve. >> > steve. >> -- > steve. >> Sent from my BlackBerry. > steve. >> > steve. >> -Original Message- > steve. >> From: Stephen Wilcox <[EMAIL PROTECTED]> > steve. >> > steve. >> Date: Fri, 29 Jun 2007 14:55:06 > steve. >> To:Christian Kuhtz <[EMAIL PROTECTED]> > steve. >> Cc:Andy Davidson <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > Donald Stahl <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 > steve. >> > steve. >> > steve. >> multihoming is simple, you get an address block and route it to > your upstreams. > steve. >> > steve. >> the policy surrounding that is another debate, possibly for another > group > steve. >> > steve. >> this thread is discussing how v4 to v6 migration can operate on a > network level > steve. >> > steve. >> Steve > steve. >> > steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: > steve. >> > Until there's a practical solution for multihoming, this whole > discussion is pretty pointless. > steve. >> > > steve. >> > -- > steve. >> > Sent from my BlackBerry. > steve. >> > > steve. >> > -Original Message- > steve. >> > From: Andy Davidson <[EMAIL PROTECTED]> > steve. >> > > steve. >> > Date: Fri, 29 Jun 2007 14:27:33 > steve. >> > To:Donald Stahl <[EMAIL PROTECTED]> > steve. >> > Cc:[EMAIL PROTECTED] > steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 > steve. >> > > steve. >> > > steve. >> > > steve. >> > > steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: > steve. >> > > steve. >> > >> That's the thing .. google's crawlers and search app runs at > layer > steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd > (the > steve. >> > >> community) got everything right with v6, it wouldn't matter to > > steve. >> > >> Google's applications whether the content came from a site > hosted > steve. >> > >> on a v4 address, or a v6 address, or even both. > steve. >> > > If Google does not have v6 connectivity then how are they going > to > steve. >> > > crawl those v6 sites? > steve. >> > > steve. >> > I think we're debating from very similar positions... > steve. >> > > steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because > if > steve. >> > life was so simple, we wouldn't need to ask this question. > steve. >> > > steve. >> > Andy > steve. >> > > steve. >
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On Thu, Jun 28, 2007 at 01:27:30PM -0400, Aaron Daubman wrote: > > On 6/28/07, chuck goolsbee <[EMAIL PROTECTED]> wrote: > >You left out: The "killer-app." > >Compelling content *only* available via the alternative technology. > >The IPv-ONLY google/porn/web/tube/iphone/whatever that enough people > >want/desire/need/are-willing-to-pay-for to move the network to IPv6. > > I wonder what it would take to convince a major online retailer > (Amazon?), an auction site (eBay?) or even transaction handlers > (google checkout, paypal?) to put up v6 portals that offered > across-the-board (or even select) discounts to customers coming in > through their v6-only portal? i presume it would take you to pay for the shortfall plus the cost of their implementing this distinction > Perhaps I'm simply too naive, but I would imagine that even a small % > discount (from within the business' profit margin) would be incentive > enough to get customers to at least start asking how they can get > access to this cheaper IPv6 portal... (the lengths many people will go > to to save a little money, often even spending more than they save in > the process, is amazing in and of itself) i cant understand why any retailer would limit its access to the marketplace for the sake of an obscure technical argument that their beardy long haired IT guy reckons is a good idea. imagine the board room discussion.. "and this will limit us to only 0.5% of our global market?" "and we need to by $x,xxx,xxx of new hardware to make this happen?" "and it will take man hours at a cost of $xxx,xxx?" this is the core of my argument here about whether v6 is the obvious solution to v4 depletion - what is the cost to push this technology vs other options. it needs to be cheaper else you are working an uphill battle > ...I would think it would also cause additional publicity for the > sites from the ensuing (even if only in the tech community) news > reporting, and that there may even be future gov't incentives > (write-off the discount?) for such practices. well, that may well be worth some $$$ but only if you are the first one! and if i were amazon, i'd say okay i'll do this but i'm only going to list my networking books on this v6 system - i can entertain the technical world, not lose any revenue, incur a minimal cost, and get the marketing points Steve
Re: [uknof] Re: [members] Network Level Content Blocking (UK)
[I have included the nanog list back here, as it was originally cross posted and there seem to now be divergent discussions in progress] On Sat, Jun 09, 2007 at 10:13:11PM +0100, Vince Hoffman wrote: > Ian Dickinson wrote: > > John Ekins wrote: > >> Some very big sites HAVE been on the list at times. This was clearly an > >> issue we took into account. Our system coped. > > > > Good for you. > > > >> I can't believe this is news to Pipex. This has been discussed at the > >> IWF and ISPA. And Pipex is a member of both. It has been discussed over > >> and over. The fact is small ISPs (like Brightview - 60,000 ADSL) and big > >> ISPs (BT, Virgin Media (NTL/Telewest) - millions) have implemented this. > >> They had the same issues and found a way to make it work. > > > > It's not news - I'm merely taking issue with your "zero-cost" stance, which > > I > > think is *potentially* misleading. > > > A colleague of mine informed me that receiving the IWF feed requires us > to be a member, a not totally insignificant cost (about £5k for us,) is > this correct? If so, combine it with colo, admin and hardware costs and > its certainly not "zero-cost" for us I think theres a bit too much focus being given to the implementation side of this problem. The Internet is currently a very cheap industry to set up in, compare to say becoming a telco in the 90s with large licensing fees and huge capex for startup. If the government says the Internet services need to provide X Y and Z at $ cost then so be it. I think the real issue is the technology and the perception it has. It is being imposed on operators to violate routing strategies and add these /32s which cannot scale, additionally inserting web caches many years after web caches ceased to be defacto with all the issues and reduced service level they come with. And after doing all this we are blocking on a tiny hand managed list, this doesnt even compare to early spam blocking systems and look how ineffectual they were! The scary part is this is being cited in parliamentary sessions as being the holy grail of child porn fighting. That is the real worry. Yes it is relatively expensive to implement, yes it can only be done through a series of hacks and violations to protocol and no it doesnt provide 1% of real protection or help to push forwards the anti child porn goals. So why are so many ISPs keen to sign up? Well any number of reasons - PR, political pressure, fear of being branded pro-child porn by the media. I think we as an industry can do so much better to find solutions to this problem without pandering to the first crazy idea that our PR mad government comes up with. Steve
Re: What happened to Cogent?
There are rumours of depeering from them Route-views shows much instability to their major peers eg 2914, 12956, 701 etc I have a couple of customer complaints and they are unreachable Perhaps they depeered, overloaded their net and turned it off and on again? Steve On Wed, Apr 25, 2007 at 03:55:18PM -0400, David Coulson wrote: > > About 20mins ago my connection to Cogent in Cleveland just went totally > nuts. I can't even get to www.cogentco.com over their circuit: > > > Packets Pings > Host Loss% Snt Last > Avg Best Wrst StDev > 1. v129.l3sw1.n2net.net 0.0% 11.1 > 1.1 1.1 1.1 0.0 > 2. v401.core1.n2net.net 0.0% 10.4 > 0.4 0.4 0.4 0.0 > 3. fa0-2.na01.b002352-3.cle01.atlas.cogentco.com 0.0% 11.5 > 1.5 1.5 1.5 0.0 > 4. g1-0-3501.core01.cle01.atlas.cogentco.com 0.0% 11.6 > 1.6 1.6 1.6 0.0 > 5. p6-0.core01.buf02.atlas.cogentco.com 0.0% 15.5 > 5.5 5.5 5.5 0.0 > 6. p6-0.core01.cle01.atlas.cogentco.com 0.0% 16.1 > 6.1 6.1 6.1 0.0 > 7. p6-0.core01.buf02.atlas.cogentco.com 0.0% 1 10.5 > 10.5 10.5 10.5 0.0 > 8. p6-0.core01.cle01.atlas.cogentco.com 0.0% 19.9 > 9.9 9.9 9.9 0.0 > 9. p6-0.core01.buf02.atlas.cogentco.com 0.0% 1 14.7 > 14.7 14.7 14.7 0.0 > 10. p6-0.core01.cle01.atlas.cogentco.com 0.0% 1 14.7 > 14.7 14.7 14.7 0.0 > 11. p6-0.core01.buf02.atlas.cogentco.com 0.0% 1 19.1 > 19.1 19.1 19.1 0.0 > >
Re: BGP Problem on 04/16/2007
On Fri, Apr 20, 2007 at 04:52:04PM +0200, Daniele Arena wrote: > > >> I remember this because I had such a reload and it was during a period > >of heavy cosmic activity.. as the hardware had always been reliable and > >was reliable after this was beleived to be the cause > > > >We have also started to use this as the standard excuse. > >Up to now, people believe us... > > Well, there is some documentation on Cisco containing references to > cosmic rays and parity errors: > > http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800942e0.shtml > > Cisco 7200 Parity Error Fault Tree > > "As with all computer and networking devices, the NPE is susceptible > to the rare occurrence of parity errors in processor memory. Parity > errors may cause the system to reset and can be a transient Single > Event Upset (SEU or soft error) or can occur multiple times (often > referred to as hard errors) due to damaged hardware. SEUs or soft > errors are caused by "noise" most frequently due to high-energy > neutrons generated in the atmosphere by cosmic rays. For more > information on SEUs, refer to the Increasing Network Availability > page. yup, thats the reference i was referring to.. we indeed had a single event upset on an NPE :) Steve
Re: UK ISP threatens security researcher
On Thu, Apr 19, 2007 at 06:10:06PM -0500, Gadi Evron wrote: > > On Thu, 19 Apr 2007, Will Hargrave wrote: > > > > Gadi Evron wrote: > > > > > "A 21-year-old college student in London had his internet service > > > terminated and was threatened with legal action after publishing details > > > of a critical vulnerability that can compromise the security of the ISP's > > > subscribers." > > > > > > I happen to know the guy, and I am saddened by this. > > > > In his blog post [1] he did admit to accessing other routers of Be's > > customers > > using the backdoor password; this is probably [2] a criminal offence in the > > UK. > > > > I'm not sure I have as much sympathy for him as you do. > > The guy basically looked at his own modem, which is what this was all > about. The rest of what he may have done is indeed up to your judgement. > > I am generally worried about the trend that is emerging of reporting > security issues resulting in legal threats. well in this case i dont know the nature of the threat but asking the guy to hold back the passwords seems reasonable what other examples are there as you suggest a trend in hushing security vulns? Steve
Re: BGP Problem on 04/16/2007
I dont have the reference to hand but with Cisco the crash reason hinted at something very odd which was either a hardware failure or cosmic ray - i think it was a parity error or something similar. I remember this because I had such a reload and it was during a period of heavy cosmic activity.. as the hardware had always been reliable and was reliable after this was beleived to be the cause Steve On Thu, Apr 19, 2007 at 10:17:49AM -0400, Robert E. Seastrom wrote: > > > With certain susceptible Sun CPUs which were popular during the last > sunspot maxima, this was actually demonstrably true (and acknowledged > by Sun), so don't laugh too hard. > > ---rob > > Leigh Porter <[EMAIL PROTECTED]> writes: > > > Somebody form a certain large network vendor actually blamed problems > > with their kit on cosmic rays causing memory corruption... > > > > -- > > Leigh Porter > > > > Jay Hennigan wrote: > >> > >> Andre Oppermann wrote: > >>> > >>> Audie Onibala wrote: > Yesterday on 04/16/07 between 3:00 - 3:45 PM we had sporadic > Internet problem. Our ISP's are Sprint and Qwest. > >>> > >>> Around that time there was quite a bit sunspot activity and the moon > >>> had an unusual position too. The NOC contacts of your ISP's probably > >>> may be of more specific help. But make sure to ask them for their > >>> networks SPF (sunspot protection factor). That's an important metric > >>> to qualify their network reliability. > >> > >> Are you sure it was sunspots? My NOC contacts were seeing substantial > >> memory corruption due to cosmic rays. > >> > >> > >> -- > >> Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED] > >> Impulse Internet Service - http://www.impulse.net/ > >> Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Thoughts on increasing MTUs on the internet
On Thu, Apr 12, 2007 at 11:34:43AM -0400, [EMAIL PROTECTED] wrote: > >I think it's a great idea operationally, less work for the routers and more >efficient use of bandwidth. It would also be useful to devise some way to >at least partially reassemble fragmented frames at links capable of large >MTU's. I think you underestimate the memory and cpu required on large links to be able to buffer the data that would allow a reassembly by an intermediate router >Since most PC's are on a subnet with a MTU of 1500 (or 1519) packets >would still be limited to 1500B or fragmented before they reach the higher >speed links. The problem with bringing this to fruition in the internet is >going to be cost and effort. The ATT's and Verizons of the world are going >to see this as a major upgrade without much benefit or profit. The Cisco's >and Junipers are going to say the same thing when they have to write this >into their code plus interoperability with other vendors implementations of >it. I dont think any of the above will throw out any particular objection.. I think your problem is in figuring out a way to implement this globally and not break stuff which relies so heavily upon 1500 bytes much of which does not even cater for the possibility another MTU might be possible. Steve > >Iljitsch van Beijnum <[EMAIL PROTECTED]> >Sent by: [EMAIL PROTECTED] > >04/12/2007 05:20 AM > >To > >NANOG list <[EMAIL PROTECTED]> > >cc > > Subject > >Thoughts on increasing MTUs on the internet > >Dear NANOGers, >It irks me that today, the effective MTU of the internet is 1500 >bytes, while more and more equipment can handle bigger packets. >What do you guys think about a mechanism that allows hosts and >routers on a subnet to automatically discover the MTU they can use >towards other systems on the same subnet, so that: >1. It's no longer necessary to limit the subnet MTU to that of the >least capable system >2. It's no longer necessary to manage 1500 byte+ MTUs manually >Any additional issues that such a mechanism would have to address?
Re: Thoughts on increasing MTUs on the internet
On Thu, Apr 12, 2007 at 01:03:45PM +0200, Iljitsch van Beijnum wrote: > > On 12-apr-2007, at 12:02, Pierfrancesco Caci wrote: > > >wouldn't that work only if the switch in the middle of your neat > >office lan is a real switch (i.e. not flooding oversize packets to > >hosts that can't handle them, possibly crashing their NIC drivers) and > >it's itself capable of larger MTUs? > > Well, yes, being compatible with stuff that doesn't support larger > packets pretty much goes without saying. I don't think there is any > need to worry about crashing drivers, packets that are longer than > they should are a common error condition that drivers are supposed to > handle without incident. (They often keep a "giant" count.) > > A more common problem would be two hosts that support jumboframes > with a switch in the middle that doesn't. So it's necessary to test > for this and avoid excessive numbers or large packets when something > in the middle doesn't support them. the internet is broken.. too many firewalls dropping icmp, too many hard coded systems that work for 'default' but dont actually allow for alternative parameters that should work according to the RFCs if you can fix all that then it might work alternatively if you can redesign path mtu discovery that might work too.. Martin Levy suggested this too me only two weeks ago, he had an idea of sending two packets initially - one 'default' and one at the higher mtu .. if the higher one gets dropped somewhere you can quickly spot it and revert to 'default' behaviour. I think his explanation was more complicated but it was an interesting idea Steve
Re: problem with BGP or I am an Idiot
On Fri, Nov 17, 2006 at 06:44:11AM -0800, Philip Lavine wrote: > > To all, > > Probabaly the the latter; however here is the situation. I am advertising a > rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my > other location in CA where I am advertising another rte 2.2.2.2 via BGP to > the Internet via the same ISP_A. I am using the same AS for both routes. > > For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the > 1.1.1.1 rte "% Network not in table". I know 1.1.1.1 rte is valid it shows up > in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet > rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 > and its routable??? > > How is this possible? I have the following filters but I removed them and it > seems to not make a diff. > OUTBOUND - ip as-path access-list 1 permit ^$ > ip as-path access-list 1 deny .* > INBOUND - ip as-path access-list 2 permit .* you will not accept a route with your AS in teh path you can override it (on cisco) with allow-own-as Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, Nov 10, 2006 at 12:54:28PM +, [EMAIL PROTECTED] wrote: > > > > The craziest stuff that gets announced isnt in the > > > reserved/unallocated realm anyway so the effort seems to be > > > disproportional to the benefits... and most issues I read about with > > > reserved space is packets coming FROM them not TO them > > > > Steve's 100% spot-on here. I don't have bogon filters at all and it > > hasn't hurt me in the least. I think the notion that this is somehow > > a good practice needs to be quashed. > > I think there is a terminology problem here. People think > that "bogons" means "bogus routes". From that they infer > that bogus routes should be filtered and use the Cymru feed > because it seems to be a no-brainer. > > The problem arises because the Cymru feed only contains > the low-hanging fruit. It only refers to address ranges > that *might* be bogus and which are easy to identify. > The problem is that if you pick this fruit, it soon goes > rotten and you end up filtering address ranges which are > in use and almost certainly not bogus. > > If there were some way to have a feed of real bogons, > i.e. address prefixes that are *KNOWN* to be bogus at > the point in time they are in the feed, that would be > useful for filtering. And it would likely be a best practice > to use such a feed. > > But at the present time, such a feed does not exist. > > Also, I think that anyone contemplating creating a new > feed should give some thought to what they are doing. > It would be very useful to have a feed or database which > can assign various attributes to address ranges. When there > is only one possible attribute, bogon, then the meaning > of the attribute gets stretched and the feed becomes useless. > But if there are many attributes such as > UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE, > RIR-REGISTERED then it starts to look interesting. > Some networks might like to filter based on several > attributes, others will just filter those with the > DOS-SOURCE attribute. how about PORN-SOURCE, COMMUNIST-SOURCE, DEMOCRACY-SOURCE, TERRORIST-SOURCE, RIGHT-WING-CHRISTIAN-SOURCE, COURT-ISSUED-LIBEL-CASE-SOURCE be careful before you open such a pandoras box... will this scale? who will want to use it? can it be exploited? what sort of liability do you take on by becoming responsible for policing the Internet? Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, Nov 10, 2006 at 01:18:02PM +, [EMAIL PROTECTED] wrote: > > > WRT acls, I would suggest any acl is a bad idea and only a dynamic > > system such as rpf should be used, this is because manual filters > > that deny bogons has the same issue as BGP filtering in that it can > > go stale and you drop newly allocated space. > > Your comment implies that ACLs are static and must > be configured manually. In this day and age of automated > systems, that is no longer true. Anyone who wants to can > easily implement dynamic ACLs. They will be slightly less > dynamic than a routing protocol, but ACLs do not have to > be manually configured and do not have to be static. > > Of course, on some hardware ACLs have a significant CPU > impact, but that is less of a factor than it used to be. for the purpose of scope tho we have to imagine this is a large ISP looking at every one of its border links to peers and transits given that, your options for suitable deployments are a lot more limited Steve
