Re: 240/4
On 18.10 10:48, Adrian Chadd wrote: Asking the whole internet to support 240/4 is going to tie up valuable resources that would be far better off working on IPv6. Keep in mind that it's not just software patches. Software vendors don't do stuff for free. I doubt ISPs are going to pay huge amounts of money to support a peer crazy enough to try this. And until tested, there is no guarantee that hardware based routing platforms (your PFCs, etc) can route Class E addresses as if they're unicast. So how about pulling a reachability test and announcing a few /19's from 240/4, stick a website on it and get people to report back? If there was serious community interest in this, I am sure the RIPE NCC could be persuaded to test this as part of the well-oiled de-bogonising machinery. this immediately provides automated measurements as well. It may take a little longer than sual to set up as we may want to ask all our de-bogonising peers whether they are OK with this just to be sure. Daniel PS: Personally I am not convinced that this space will ever become useful for global routing. But we won't know for sure until we have tried it.
Re: Spain was offline
On 01.09 13:47, Martin Hannigan wrote: I can't get a TLD zone? But back to the root servers. Are you agreering with me that if I announce F and I root's netblocks inside of my own network that everyone would be ok with that? C'mon Joe, straight answer on that one. :) Straight answer: No. Exercises: Who is responsible if this set-up fails? Who is responsible if it lies? Who is likely to get blamed for any failures? Would this require explicit consent from all customers subject to such treatment? Would this require a possibility for each custoemr to opt out of such a scheme? And - ah yes - what particular problem does such a set-up solve? Daniel helps operating K helped create nsd measures dns
Re: the future of the net
On 16.11 21:33, Bubba Parker wrote: Seems to be back up now. At this time I got Linux Journal Is Currently Unavailable Due to a Denial of Service (DoS) Attack Sorry for any inconvenience. Interesting. At first sight I though that was why Randy posted the URL under future of the net ;-) ;-) ;-). Daniel
Re: IAB and private numbering
On 15.11 07:38, Mark Smith wrote: RFC1627, Network 10 Considered Harmful (Some Practices Shouldn't be Codified) and RFC3879, Deprecating Site Local Addresses provide some good examples of where duplicate or overlapping address spaces cause problems, which is what happens when different organisations use RFC1918 addresses, even if they aren't connected to the Internet. This is practical engineering, not theoretical science. Practical engineering is about *trade-offs*. We were seeing address space requests for huge deployments with a real low probability to ever be routed anywhere beyond a quite local domain. There are huge deployments of this kind now and happily so without unnecessary using finite address resources. The drawbacks were known and discussed. Note that 16271918. Clear warnings were written into 1918; it is one of the more operational RFCs, certainly at the time. We also discussed the possibility of NATs but it was out-of-scope for 1918; we discussed application layer gateways though; we did not anticipate any NAT deployments beyond a very local scale. Would we rather have run out of unallocated unique IPv4 address space at some point in the past? Would an alternative have been ready by then? (Would we rather run out of unallocated IPv4 address space on -say- 31-Dec-2005? Will IPv6 be ready for prime time then?) Daniel One of the instigators and co-author of RFC1918.
Re: oh k can you see
We have considered the options carefully and decided to announce a covering /23 to get around the problem spotted by Randy and the folks in Oregon. We considered the /24+/25 soloution but decided against that because it makes little sense when we are considering to eventually remove as much of the BG cleverness as possible. See the attached announcement for details. Thanks to all people who took the time to make suggestions either privately or on list(s). This was both operational and useful. ;-) Daniel ---BeginMessage--- Dear Colleagues, As you probably know, the RIPE NCC have been deploying two types of anycast mirror instances of K-root server: global nodes and so-called local nodes, intended to serve only a local ISP community. To limit propagation of the K-root prefix for the local nodes we are using a NO_EXPORT community. Unfortunately this may lead to a situation when some of multihomed networks don't see K-root prefix at all, even for a global node. For more detailed description see http://www.merit.edu/mail.archives/nanog/msg13358.html. Thank you, Randy, for spotting this. This is not specific to anycast and has never appeared to be particularly widespread. To remedy this problem we plan to start announcing a covering prefix 193.0.14.0/23 from AS25152 from our global node to our peers at AMS-IX without the NO_EXPORT community. We will announce the covering prefix at 10:00 UTC on Thursday, 10th November 2005. In parallel we will be monitoring and measuring changes in traffic distribution for further analysis. We will then proceed with other global nodes. Regards, Andrei Robachevsky RIPE NCC ---End Message---
Re: oh k can you see
Randy's description of the issue with NO_EXPORT is correct. It has never appeared to be particularly widespread. It is not specific to anycast. You also describe the rationale correctly by saying it would be good if a server in Kenya did not take load from nyc. I'll expand a little more on that. K does anycast with two objectives: primarily to increase robustness of the service in the face of serious load increases, secondarily provide better service to some local areas in the Internet topology. It is the secondary objective that poses the problem. We operate local nodes which are intended to serve only a local area. This is clearly a routing problem and routing policy is clearly the responsibility of ISPs. The local ISPs should make sure that routes of local nodes do not propagate far enough to cause unwanted load. Consequently we could just announce one route without doing anything to it and wash our hands as far as routing and network load is concerned. Server load is not a concern here because in the case of local nodes the network will saturate far more quickly than the server. This is a very clean solution. It keeps responsibility where it belongs and does not introduce extra complexity in BOP routing. I like it. ;-) However we try to be helpful and provide tools to the ISPs by tagging the routes from such local nodes with NO_EXPORT and we artificially lengthen the AS-paths to the global nodes in order to make the local nodes more attractive to ASes that hear both. The latter is problematic too because it can cause non-optimal node selection but does not lead to anything worse than that. Remember that these are nothing but hints to ISPs who determine their own routing policy and are responsible for it. So if someone barks at K for this it is the wrong tree for the most part. What should we do? Stop giving the hints? Add complexity by announcing another less specific covering prefix like F does? Any better ideas? We are currently in an evaluation phase of our anycast deployment. We are taking measurements and are analysing them. Early results: http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-anycast_k-root.pdf We are also seriously considering to reduce the number of local nodes where this is feasible. This is a good time to hear good ideas. Let us have them. Daniel PS: Bill, I hope this also answers your question on why we do this. We have been doing it for a long time too. As I said: suggestions are welcome.
Re: oh k can you see
On 01.11 05:41, Randy Bush wrote: mornin' daniel: ev'nin randy: Of course the NCC takes resposibility for the K anycast deployment including the way we announce BGP routes to K. We also clearly describe and announce what we do. We cannot take responsibility for what others do with that routing information; we cannot because we have no control over and little way of knowing what they do. We are doing the best we can; hence this conversation. We are considering to add a covering prefix announced from global nodes relatively quickly. This should solve the particular problem and we cannot (yet) see any problems it would create. But this is more complex than the current state and thus brings us further away from salvation ;-). If there are reasons not to do this, please let us know. We are also considering seriously to treat local nodes and global nodes the same routing wise wherever possible. This will be done one-by-one wiht the proper announcements and concurrent measurements. My poersonal hope is that we can do this for all K nodes and thus remove all BGP cleverness that originates from us. This does not mean that all cleverness concerning K's routes would be removed though. Daniel
Re: Level 3's side of the story
On 16.10 16:04, Simon Leinen wrote: Kevin Loch writes: Does anyone have reachability data for c-root during this episode? The RIPE NCC DNSMON service has some: http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.nettype=dropststart=1128246543tstop=1128972253 If there is anyone with more comprehensive data I'd like to hear about it ;-) ! According to BGPlay for that particular prefix from Route-Views data (for some reason the RIPE RIS server used by BGPlay seems to be down at the moment), the episode seems to be between these times (UTC): It is up now. Of the two routes to c.root-servers.net via Level 3 in that data set one stayed up during the period and the other got healed immediateely via AS286. It flipped back later. ... The interval in the URL above starts 72 hours before the start of the episode and ends 72 hours after its end. I cannot see any particular problems that would coincide with the episode, from that set of probes (RIPE TTM). I agree that there is nothing really significant here. It is mostly noise. What one is looking for in these graphs is strong vertical patterns. dnsmon did not detect anything significant concerning reachability of c.root-servers.net. As someone else said, partial unreachability of a particular root nameserver isn't that much of an issue. Indeed. But it's an interesting question nevertheless. A red instance of a fish from the northern seas ? Daniel
Re: as numbers
On 31.07 17:20, [EMAIL PROTECTED] wrote: we did that (move a root) in the CIDR /8 experiment. we could do it for this too :) one root name server: yes the root name servers: no, definitely not Daniel PS: Ony as soon as implementations are available of course ! ;-(
Re: as numbers
On 29.07 09:59, Henk Uijterwaal wrote: I'd think that 30 days is too low. What we see (*) is that after 30 days, only half of the assigned ASN have appeared on the Internet. Some 75% of the assigned ASN appear on the net in the first 6 months after assignment, 80-85% after a year. Anything not seen after a year (15-20%), is unlikely to ever appear, these can be recovered (at least in theory). While this looks like a lot, it does not really solve any problem. Geoff's numbers show that the pool will expire in 5 years. Our estimate is a little bit longer, but not that much. 2010-2005 is 5 years, if the trend that 20% never appears continues and all these ASN are revoked, this simply means that the pool will expire in 6 years. 2010 or 2011 hardly makes a difference. Henk hits the nail on the head. And reclamation is not straightforward: The RIPE NCC has hit strong resistance to reclamation, most often with the argument that the ASes are used in inter-domain routing on the Internet but our BGP data collectors just do not see the paths concerned. It takes considerable effort to do reclamation properly whithout putting the future user of any reclaimed number space at risk! Also: I think we should all be very concerned about this. As with all such projections, Geoff's are valid only for an unchanged consumtion pattern. If I was running a network I would start to ask my vendors serious questions and start to prepare deployment scenarios. Daniel
Re: GSM gateways in the US?!?
On 25.07 07:59, Simon Lockhart wrote: There are two methods that are obvious to terminate calls into mobile (GSM) networks in North America: Just to give you a .uk experience, I don't know the technical details of how this is implemented These are pretty common plans over here even for enterprises smaller than the BBC. A friend in a medium sized taxpayer funded organisation recently related the following: that organisation had just invested considerably into their PABX, particularly into toll authorisation and billing. Shortly after this was introduced they realised that the national toll volume sharply decreased. They were just about to declare a serious victory for effective cost control when they realised that this was due a change in the corporate GSM plan that allowed essentially free national calling and people in the organisation were making the right choice ;-) This suggests a much simpler solution to this whole problem: Give all the people in the office cell phones for intra-organisational calling. Lacks some call management features, and certainly lacks geek satisfaction, but costs very little to implement... Daniel
Re: soBGP deployment
On 23.05 22:13, Tony Li wrote: ... We, as responsible operators/architects/vendors/coders need to pick a solution and field it. It may well be an interim solution, but we MUST act, and soon. We are already seeing the stress patterns, without reinforcement it is only a matter of time before we see wholesale fractures. Given that any solution will have an implementation and deployment delay, we dare not wait much longer. From discussions with large operators during NANOG week it is clear to me that at this point most will simply not deploy anything that dynamically interacts with their inter-domain routing (BGP). All are comforatble with deploying something that works via the current mechanism of periodically built configurations. In fact most said to wait for something that would take some of the heuristics out of that process. We will not get any deployment unless either that attitude changes or we engineer taking it into account. I prefer the latter. To me the first stage of any deployment becomes obvious then: Map the fucntionality of s*BGP into tools to build routing configurations from signed information distributed by whatever means. This will make rapid deployment possible with a high comfort level for operators which is key! It would bring immediate benefits and help us build and understand the databases that are necessary. In parallel we can develop more dynamic ways of distributing the information and interacting with BGP. If the design and trust model of s*BGP is indeed well conceived this will be attractive enough for operators to see deployment. Note that I am not advocating routing registries. I agree with those that consider them a failure although I have been a long time supporter. The idea is to start building the (signed) meta-information and using it as additional input to the configuration generation already done by operators. Ideally this would quickly obsolete from routing registries and many heuristics. Can such a first step of an incremental deployment be designed for any of s*BGP? Daniel
Re: [dnsop] Re: Root Anycast
On 03.05 16:06, Rodney Joffe wrote: ... See y'all in Seattle. Daniel Karrenberg and others will be providing loads of fuel to spark debate amongst non-kooks about the efficacy of anycast DNS ;-) Sneak preview: http://rosie.ripe.net/ripe/meetings/ripe-50/presentations/uploads/Tuesday/karrenberg-bgp_anycast_stability.pdf Daniel
Re: [dnsop] Re: Root Anycast
On 05.05 16:56, Daniel Karrenberg wrote: Sneak preview: http://rosie.ripe.net/ripe/meetings/ripe-50/presentations/uploads/Tuesday/karrenberg-bgp_anycast_stability.pdf Sorry, correct URL is: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-anycast.pdf
Re: fwd: Re: [registrars] Re: panix.com hijacked
On 16.01 10:25, Lou Katz wrote: Is there anything that us folks out in the peanut gallery can do to help, other than locally serving the panix.net zone for panix.com? Avoid being caught by an IPR lawyer while helping; ;-) Then organise operators to insert operational clue into the various policy processes. Daniel
Re: verizon.net and other email grief
On 14.12 09:39, Todd Vierling wrote: That's definitely true, though it can be used successfully -- if there's a very reliable kill-switch to withdraw the advertisement in a moment, or some kind of fallback mechanism in place to handle gross failures. Using this as the *only* remedy for unavailability of an anycast instance is insufficient given the speed at which bad news travels in BGP. You want to have the service available at multiple addresses with each of those engineered as differently as possible. Daniel
Re: anycast stability experiment
The RIPE NCC dnsmon (http://dnsmon.ripe.net) has collected such data for all root servers from dozens of places for about two years already. You are welcome to the raw data. NB: The further back in time the more work it will be for us to dig out raw data. Differences to your set-up: - most probes are not near the edges of the net, for most definitions of edge - probing times are properly randomised - the mean probing interval is 60s - UDP only [Continuous but not scientifically rigorous examination of the data shows that your bet is a pretty safe one. In other words: for practical purposes routing is stable at all proble locations. So the data is in fact pretty boring. If it weren't as boring, k.root-servers.net would not be anycast the way it is.] Daniel
Re: European Nanog?
On 14.09 13:23, Roland Perry wrote: ... more to the point, who decided meeting content? essentially daniel karrenberg does. I thought it was a committee of the Workgroup chairs (apart perhaps from the first day). Roland, you are almost right. From http://www.ripe.net/ripe/meetings/ripe-49/eof-info.html : The European Operators Forum (EOF) is a forum where new technologydevelopments of interest to Internet Protocol network operators arepresented and discussed. The EOF has no formal charter or chair. The agenda is co-ordinated by a program committee led by Rob Blokzijl, RIPE Chair. Participation is open to all interested parties. The EOF is normally a day and a half session that takes place prior to scheduled RIPE Working Group sessions. The Program Committee welcomes input for possible topics and can be reached at [EMAIL PROTECTED]. ... All sugestions for content go to the eof-coord list. Anyone willing to contribute to putting together the EOF programme is welcome to join this list. It is an extremely informal group. Most, if not all, RIPE WG chairpeople are on the list; but it is not limited to them. The RIPE NCC currently supports me to act as a secretary and to look after the meeting/speaker logistics. Daniel
Re: RIPE Golden Networks Document ID - 229/210/178
Some facts: RIPE is an operator forum, comparable to NANOG, APRICOT, AFNOG, (Strictly speaking RIPE pre-dates all of the others if one disregards that NANOG started as the NSFnet regional network meetings. ;-) RIPE NCC is a Regional Internet Registry, comparable to ARIN, APNIC, LACNIC, AFRINIC, (The RIPE NCC is the first of the regional registries.) RIPE is the public forum where RIPE NCC policies and procedures are set; they describe how the RIR allocates and assigns internet numbers. RIPE NCC policies and procedures are *extremely* careful not to prescribe any inter-domain routing practises and go out of their way to stress that operators have the authority about that. RIPE also makes general recommendations, which have nothing to do with the RIPE NCC. The golden networks recommendations are in this category. They are also just that: recommendations. --- Some opinions: The goals of the RIPE recommendations are laudable: Make dampening work predictably by aligning parameters. They reflect a general belief in think globally, act locally which still permeates RIPE discussions. However, this is not likely to work because: - operators have the sole authority about routing - different local goals - different capabilities of infrastructure - different capabilities of staff (design and operation) - sheer ignorance (Yes, I tend to be a bit more cynical these days than the average RIPE attender.) I doubt if a survey such as Rodney tries to perform will yield any useful results because responses will not be universal nor evenly distributed. -- More personal opinions: If there is a significant number of operators that want to base any of their decisions on what services are behind specific addresses, this cannot be solved by static documents but must be solved by a registry. I would design this as a voluntary registry which operators may use in any which way they want if they choose to. The *art* in the design of such a registry would be defining the classes of services and agreeing on how to verify that an address houses a service of a given class for some classes such as DNS root and TLD servers. OTOH for DNS root and TLD servers, determining their addresses is trivial using the DNS itself and the containing prefixes can be found from current BGP tables and/or BGP archives such as the RIS. So the case for such a registry for DNS servers alone is highly questionable. Daniel
Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)
On 23.07 22:30, Simon Waters wrote: The abstract doesn't mention that the TTL on NS records is found to be important for scalability of the DNS. Sic! And it is the *child* TTL that counts for most implementations.
Re: VeriSign's rapid DNS updates in .com/.net
On 22.07 14:46, Randy Bush wrote: ... the TTL issue is almost entirely NS RRs, ... of course, almost all date in the gtlds are NS RRs, so the worry about TTL crank-down holds, though just for silly gtld servers. then again, they're paid to serve. This assumes rational behavior of a lot of zone admins. YMMV Of course rational behavior may be increased by information and education. Daniel
Re: VeriSign's rapid DNS updates in .com/.net
Matt, others, I am a quite concerned about these zone update speed improvements because they are likely to result in considerable pressure to reduce TTLs **throughout the DNS** for little to no good reason. It will not be long before the marketeers will discover that they do not deliver what they (implicitly) promise to customers in case of **changes and removals** rather than just additions to a zone. Reducing TTLs across the board will be the obvious *soloution*. Yet, the DNS architecture is built around effective caching! Are we sure that the DNS as a whole will remain operational when (not if) this happens in a significant way? Can we still mitigate that trend by education of marketeers and users? Daniel
Re: VeriSign's rapid DNS updates in .com/.net
On 22.07 12:26, Stephen J. Wilcox wrote: I dont see any reference to adjusting the TTL in the verisign announcement. Correct. They say they will update the zones every 5 minutes from the registry data. These are not the same things (or did I miss that bit?) Correct. Also, isnt a lot of this dependent on the NS records in the second level gtlds which is hosted by the ISPs.. so this part doesnt change? Correct. What I am concerned about is the pressure to lower TTLs across the board if the increase in zone update speed creates expectations that it alone cannot fulfill. I observe this being sold as instantaneous updates instead of instantaneous additions. When this becomes clear the pressure will be to deliver what the salespeople promised. This will result inthe obvious soloution: Lower TTLs everywhere. I am not sure the DNS will remain stable if TTLs are lowered to a couple of seconds throughout. I am suggesting clearer marketing: Quick additions: Yes. Quick changes/deletions: No. Note that I am not concerned about *judicious* lowering of TTLs in preparation for changes or to provide services such as akamai. It is more a general trend of many independent actors serving nor real purpose that worries me. Caveat emptor. Daniel
Re: VeriSign's rapid DNS updates in .com/.net
On 22.07 17:08, Paul Vixie wrote: therefore if there were a drop in TTL for root-zone data, it would only be a multiplier against 2.1% of f-root's present volume. I am not worried so much about the root servers here because of the reasons you cite. The root server system is engineered to cope with hugely excessive loads already. I am worried about all the other root servers that have to deal with much lesser query loads and might feel the impact of lowered TTLs much more. ... and the impact of having it in many TLD's will be to put downward pressure on TTL's. this all needs to be looked at very carefully. Yes, we need to keep an eye on this and argue against lowering TTLs across the board for little good reasion.
Re: VeriSign's rapid DNS updates in .com/.net
On 22.07 21:05, an alter ego of Daniel Karrenberg wrote: I am worried about all the other root servers that have to deal with much lesser query loads and might feel the impact of lowered TTLs much more. Of course I meant all the other DNS servers. Daniel
Check Your Routing Table! 85-88/8 active
It is *now* high time to check whether you see the following
pilot prefixes:
85.192/16, 85.255.248/21,
86.192/16, 86.255.248/21,
87.192/16, 87.255.248/21,
88.192/16, 88.255.248/21.
If you do not see all of these prefixes it is extremely likely that you
will have a connectivity problem shortly. We also suggest that you
check any packet filters you may be responsible for.
Regards
Daniel Karrenberg
RIPE NCC
--
Notes:
This address space has been allocated by the IANA on April 4th 2003,
almost a month ago. The fact has been widely announced then.
Routing decisions are fully within the responsibility of the network
operators. The IANA and the RIRs will only announce which parts of the
address space are currently in use. They have no authority whatsoever
over routing decisions taken by you and other network operators.
More details about this pilot service of the RIPE NCC can be found at
http://www.ripe.net/ripe/draft-documents/deboganising-draft.html .
A visibility comparison of the pilot prefixes with some production
prefixes can be found at http://www.ris.ripe.net/debogon/debogon.html .
Those interested in history, see http://www.ris.ripe.net/debogon/ .
Pingable targets exist in all pilot prefixes at
t{85,86,87,88}-{16,21}.rrc03.ripe.net , i.e. the target within
the /21 pilot prefix of 85/8 is t85-21.rrc03.ripe.net .
For testing purposes it is possible to do ping and traceroute
originating within the pilot prefixes via
http://www.ris.ripe.net/cgi-bin/debogon.cgi .
Please use this with prudence.
More information on how to do Bogon filtering efficiently and reliably
can be found at Team CYMRU: http://www.cymru.com/Bogons/index.html
EOF, Amsterdam, May - Call for Presentations
[apologies for duplicates, hint: they have the same message-id] Hi Network Operations Folk, NOW is the time to consider making a presentation at the European Operators Forum (EOF) to be held during the 48th RIPE meeting in Amsterdam on Monday 3rd and Tuesday 4th of May 2004. We would like to have as many practical, hands-on presentations as possible this time. Remember: They do not have to be long. We prefer an stand-up interesting 10 minute presentation over a well prepared 90 minutes explanation of something not so interesting to operators. Find some information about presenting below and think about all those experiences this year that might be interesting to other operators. Should you have questions, please do not hesitate to contact me by e-mail at any time. Thanks Daniel -- Information about the EOF and presenting there: http://www.ripe.net/ripe/meetings/ripe-48/eof.html Information about the meeting in general: http://www.ripe.net/ripe/meetings/ripe-48/index.html -- Guidelines for submitting abstracts: We expect to finalise the program in shortly. We will get back to you then with scheduling details. In the meantime please provide the information below. We place special emphasis on the abstract which should contain references to related material already available if possible. Please send this to eof-coord at-sign ripe.net. - Author(s) - Speaker - (Working) Title - Abstract - Draft Presentation (if available) - Relation to other known work and/or presentations if known - Time Requested It would be helpful if the abstract was written such that potential attenders will learn what to expect from the presentation, i.e. The presentation will describe our experiences with the Red Packet Washer (http://www.netdet.net/RPW/). We have been using the device for half a year now. It helps us deliver more hygienic datagrams to our customers and peers. We will discuss problems with packet discolouring as well as increased throughput to our upstreams due to decreased clogging by dirty micrograms. We will compare performance with the hand-scrubbing of packets which we used previously. Currently we are optimising device management and getting bugs resolved. We will strive to include the latest experiences in our report. is much better than The presentation will describe the Red Packet Washer made by Network Detergents.
Re: DNS requests for 1918 space
On 16.03 11:22, Geo. wrote: Can anyone point me at any papers that talk about security issues raised by private networks passing dns requests for RFC 1918 private address space out to their ISP's dns servers? RFC1918
Check Your Routing Table! Production Use of 84/8 Imminent.
The first allocation out of 84/8 has happened. It is *now* high time to check whether you see the pilot prefixes 84.192/16 and 84.255.248/21. If you do not see both of these prefixes it is extremely likely that you will have a connectivity problem very shortly. We also suggest that you check any packet filters you may be responsible for. Regards Daniel Karrenberg RIPE NCC -- Notes: 84/8 has been allocated by the IANA on November 17th 2003, almost 4 months ago. The fact has been announced on this list a couple of times since. Routing decisions are fully within the responsibility of the network operators. The IANA and the RIRs will only announce which parts of the address space are currently in use. They have no authority whatsoever over routing decisions taken by you and other network operators. More details about the pilot prefixes can be found at http://www.ripe.net/ripe/draft-documents/deboganising-draft.html A visibility comparison of the pilot prefixes with some production prefixes can be found at http://www.ris.ripe.net/debogon/debogon.html Those interested in history, see http://www.ris.ripe.net/debogon/ More information on how to do Bogon filtering efficiently and reliably can be found at Team CYMRU: http://www.cymru.com/Bogons/index.html Unfortunately we are not currently able to provide a host within the pilot prefixes that can reliably answer pings, nor are we able to do connectivity checks from there. The allocation had to happen before we were ready with this part of the pilot prefix pilot.
Re: Counter DoS
On 10.03 20:55, Steven M. Bellovin wrote: The phrase seriously bad idea comes to mind. Other phrases include illegal, collateral damage, and stupid. Those plus escalation of agression and uncontrollable feedback loop. Daniel Karrenberg PS: I will spare you the re-run of a recent discussion I had with some 5-year-olds, but there *is* a certain similarity.
Re: 168.0.0.0/6
On 24.02 23:20, Randy Bush wrote: BGP routing table entry for 168.0.0.0/6, version 7688303 ... 3277 13062 20485 20485 20485 8437 3303 194.85.4.249 from 194.85.4.249 (194.85.4.249) Origin IGP, localpref 100, valid, external, best ripe is being overgenerous to the swiss! Not so. They are pretending to be over-endowed to some peers only. Isn't that something to notify AS3303 aka SWISSCOM about rather than NANOG? Especially since it does not look like it is spreading very widely. Daniel
Proposal: De-boganising New Address Blocks
[Apologies for duplicate messages] This is of interet to all operators worldwide. Operators who do not participate in RIPE are invited to send comments and suggestions directly to the author. De-Bogonising New Address Blocks http://www.ripe.net/ripe/draft-documents/deboganising-draft.html Abstract This document describes an improvement in the notification process about new blocks of address space being distributed by the RIRs. It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under 84/8 Pilot.
Re: New Draft Document: De-boganising New Address Blocks
On 24.02 16:32, [EMAIL PROTECTED] wrote: That is a misleading title. I thought it was to the point and rather cute ;-). The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. This is the status quo, aka best *current* practise. However, it will also allow spammers to announce this space and get it through bogon filters. Correct, but only in the absence of more specific filtering. the problem this proposal aims to correct is the increasing number of false positives caused by the apparent *serious* lag in relatively static bogon filtering. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? Personally I think this is a great idea and if we hear from a lot of operators actually willing to take such feeds it may become reality beyond volunteer efforts like the Team CYMRU one. However there are a number of serious issues with something like this, not the least of which are the liability issues in case this goes wrong very dynamically and semi-automatedly. It is certainly something to progress if there is enough interest. However I think the current proposal shold go ahead too because the false positives are a real problem that needs to be addressed quickly. Daniel
Re: updated root hints file
On 29.01 15:36, Jess Kitchen wrote: http://www.root-servers.org/ seems to only have news on I's ASN change, no mention of B or J or the anycast F/K/I's ... methinks this info should have a home on this site.. If you folow the link from this site to http://k.root-servers.org/ you will find info about K's anycast instances. We will add them to the table too, just for completeness. Daniel
Re: What's the best way to wiretap a network?
On 21.01 09:24, Kurt Erik Lindqvist wrote: From the initial discussions in Sweden around the new electronic communications act, it seems as if the operators are obliged to provide tapping free of charge. If this turns out to be the case, I guess it is pretty much the same all over Europe as the law is supposed to be based on a EU framework. Slightly off topic: This is being fought by ISPs and civil rights groups all over the place here. It is amazing how much brain-damage is defended by EU Framework these days. It is also amazing how much national politicians and pressure groups can assert things about *neighboring* countries that are blatantly wrong or totally out-of-date. In the EU political structures and processes still have to be built; it is a new thing. Daniel
Re: New IPv4 Allocation to ARIN
On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
Re: good cabling in real environments [Re: Request for submissions: messy cabling and other broken things]
On 17.12 19:07, Pekka Savola wrote: How do you do good cabling in dynamic, real environments? :-) My own 25 years of experience boil down to: Try to plan for expansion as well as possible when designing, then periodically start over and completely re-build the messy parts. The period of starting over depends on the pain level of the planned outages this may cause and the general pain caused by the state of things. All clever plans I have seen in this area have not lasted more than about 2-3 years. It seems very difficult to predict where the growth is and how it happens. I admit this is a slightly cynical view but such is life. What I dread most, are situations where no-one takes the responsibility for starting over when it is really necessary and everybody suffers. Daniel
Re: Root Authority
On 16.12 07:14, Paul Vixie wrote: we (i'm speaking for f-root here) have no authority. nobody has to listen to us, we are the most powerless bunch of folks you'll ever meet. now if you'd asked where we derive our *relevance*, i'd say the same as mr. bush and mr. kletnieks -- from all the root.cache files that point at us. and as long as we don't do anything stupid i guess (and hope) that this state of affairs will continue. (relevance trumps authority.) that having been said, f-root got its start as NS.ISC.ORG and the man who said it was ok for us to be a root name server was jon postel. i'm not sure he had any authority either, but folks pointed at him and so what he said was relevant in spite of any authority he mightn've had. Amen! This also holds for k-root and is so well put that I will not paraphrase it just for the sake of putting it differently. It is worth reading again! Daniel
Re: Anit-Virus help for all of us??????
On 24.11 18:20, William Allen Simpson wrote: Brian Bruns wrote: One thing that many people don't realize (from my personal experience) is that contrary to popular belief, Win98SE is a good all around desktop OS to use. It can run most things like productivity apps and games, and with 128-256MB of RAM, its quite fast even on an old laptop like mine. Unlike XP, it doesn't have a million services running, nor does it have the nasty UPnP stuff from WinME. I agree wholeheartedly. if haveto(M$) use(W98SE); I recommend that at home to all local primary schools. They often do not have the latest hardware but some of them even run it on the latest hardware now. This and frequent reloads of standard clean disk images tends to keep things clean and operational. The image loads from a *nix server are routinely done by 10-year-olds. Unfortunately this is not a really long term strategy. I expect apps that are essential to the schools but do not run on W98SE in the not-too-distant future. I guess they will have to find loads of money and buy macs then. ;-) Daniel
Re: possible ORG problems, maybe?
On 17.10 09:47, Randy Bush wrote: but one has little assurance that the response is from the same server as the one from which one had the dns response one is debugging. That is true. However this only matters if the operator of the server allows them to be inconsistent *and* routing so volatile that queries are routed to different instances over short periods of time. In my opinion the increased DDoS resilience alone outweighs this drawback. In addition the service quality can be increased as the number of places at which the service can be provided is independent of the number of server addresses available due to DNS protocol limitations. Hard data: We probe DNS servers from 60+ points across the internet once a minute on average. We log the id.server or hostname.bind value they return. I have not completed the colour picture version of analysing this part of the data but here is a quick perl script version: For the period from UTC to 2359UTC yesterday 60 out of 63 probes (95+%) got *all* of their 1400+ answers from the *same instance* of k.root-servers.net. The three probes that talked to different instances showed 1, 2 and 4 change events respectively. I consider this stable enough for debugging purposes. Data for f.root-servers.net shows a similar picture. Both data files are attached. We will provide this data in full colour form at dnsmon.ripe.net sometime in the coming weeks. Daniel id.server change events over 00-24h UTC 16 Oct 2004 probe Unix-second id.server jordaan.ripe.net 1066262834 k1.ams-ix osdorp.ripe.net 1066265997 k2.ams-ix tt01.ripe.net 1066265765 k1.ams-ix tt03.ripe.net 1066264341 k1.ams-ix tt07.ripe.net 1066263351 k2.linx tt08.ripe.net 1066264396 k1.linx tt101.ripe.net 1066263692 k2.linx tt102.ripe.net 1066263660 k2.ams-ix tt106.ripe.net 1066263675 k1.linx tt13.ripe.net 1066263669 k2.ams-ix tt16.ripe.net 1066265900 k1.ams-ix tt17.ripe.net 1066265938 k2.linx tt22.ripe.net 1066265931 k1.ams-ix tt23.ripe.net 1066265275 k1.linx tt26.ripe.net 1066265922 k1.linx tt27.ripe.net 1066263670 k2.linx tt27.ripe.net 1066277285 k2.ams-ix tt27.ripe.net 1066281317 k2.linx tt27.ripe.net 1066281916 k2.ams-ix tt27.ripe.net 1066281978 k2.linx tt28.ripe.net 1066263029 k2.linx tt31.ripe.net 1066262515 k2.linx tt32.ripe.net 1066265728 k1.linx tt34.ripe.net 1066264347 k2.linx tt35.ripe.net 1066263579 k2.linx tt36.ripe.net 1066265821 k1.ams-ix tt40.ripe.net 1066266054 k1.ams-ix tt42.ripe.net 1066263820 k1.linx tt46.ripe.net 1066262809 k2.linx tt46.ripe.net 1066277318 k2.ams-ix tt46.ripe.net 1066281259 k2.linx tt47.ripe.net 1066263388 k2.linx tt49.ripe.net 1066263719 k2.ams-ix tt52.ripe.net 1066263700 k1.ams-ix tt53.ripe.net 1066263547 k2.linx tt54.ripe.net 1066263448 k2.linx tt55.ripe.net 1066264461 k2.linx tt56.ripe.net 1066263652 k2.linx tt56.ripe.net 1066289206 k1.ams-ix tt57.ripe.net 1066263443 k2.ams-ix tt58.ripe.net 1066263917 k1.linx tt59.ripe.net 1066263880 k2.ams-ix tt62.ripe.net 1066263745 k1.ams-ix tt63.ripe.net 1066265313 k2.linx tt64.ripe.net 1066265845 k1.linx tt66.ripe.net 1066263341 k2.ams-ix tt69.ripe.net 1066263469 k1.linx tt70.ripe.net 1066265124 k1.linx tt71.ripe.net 1066265453 k1.linx tt72.ripe.net 1066263370 k2.linx tt73.ripe.net 1066263666 k2.ams-ix tt74.ripe.net 1066264146 k1.linx tt76.ripe.net 1066265324 k1.linx tt77.ripe.net 1066264512 k2.ams-ix tt78.ripe.net 1066263788 k1.linx tt80.ripe.net 1066264148 k2.ams-ix tt81.ripe.net 1066263388 k2.ams-ix tt82.ripe.net 1066264239 k2.ams-ix tt84.ripe.net 1066263094 k2.linx tt85.ripe.net 1066263695 k2.linx tt86.ripe.net 1066263776 k1.linx tt87.ripe.net 1066263651 k1.linx tt88.ripe.net 1066264483 k2.ams-ix tt89.ripe.net 1066265562 k2.linx tt90.ripe.net 1066263876 k1.ams-ix tt92.ripe.net 1066263814 k2.linx tt93.ripe.net 1066262921 k2.ams-ix tt94.ripe.net 1066263274 k2.ams-ix tt97.ripe.net 1066263862 k2.ams-ix tt98.ripe.net 1066265295 k2.ams-ix jordaan.ripe.net 1066262826 pao1e.f.root-servers.org osdorp.ripe.net 1066265992 pao1f.f.root-servers.org tt01.ripe.net 1066265749 pao1c.f.root-servers.org tt03.ripe.net 1066264356 pao1d.f.root-servers.org tt07.ripe.net 1066263361 pao1e.f.root-servers.org tt08.ripe.net 1066264397 yow1b.f.root-servers.org tt08.ripe.net 1066269597 pao1e.f.root-servers.org tt08.ripe.net 1066269649 pao1f.f.root-servers.org tt08.ripe.net 1066269720 yow1b.f.root-servers.org tt101.ripe.net 1066263685 pao1e.f.root-servers.org tt102.ripe.net 1066263678 pao1e.f.root-servers.org tt106.ripe.net 1066263671 sfo2a.f.root-servers.org tt13.ripe.net 1066263662 yow1a.f.root-servers.org tt13.ripe.net 1066269591 pao1f.f.root-servers.org tt13.ripe.net 1066269699 yow1a.f.root-servers.org tt13.ripe.net 1066307212 pao1f.f.root-servers.org tt13.ripe.net 1066307266 yow1a.f.root-servers.org tt16.ripe.net 1066265895 pao1f.f.root-servers.org tt17.ripe.net 1066265953 mad1a.f.root-servers.org tt22.ripe.net 1066265939 yow1b.f.root-servers.org
A RR Wildcards and Stability
The comittee should realise that the question Verisign poses about observed adverse effects, while interesting, is not as pertinent as it seems at first sight. John Klensin put it very well yesterday in a rigorous way. I'll offer a less rigorous but more graphical analogy: A contractor drills large holes in the central structural parts of a building to allow installation of their innovative garbage disposal. Civil engineers question the effects this has on the building's stability. The contractor's defense is: Well it is still standing! How much work did those tenants really have patching up the holes to reduce the air drafts and stop the crackling noises? Daniel
Re: sitefinder technical discussions
On 06.10 23:51, Mark Kosters wrote: In the interest in gaining more community review and comment, a discussion list has been setup to discuss factually-based technical issues and solutions surrounding the operational impact of wildcards in top-level domains on Internet applications. VeriSign technical people will participate in discussions that are within the scope for this mailing list. The list is [EMAIL PROTECTED] To subscribe or unsubscribe the usual -request convention works. Send a message to: [EMAIL PROTECTED] Put subscribe or unsubscribe in the body of the message. I am very hesitant to join this particular list because I am afraid that Verisign will somehow use the fact that I am subscribed as they please in their PR efforts, e.g. A panel of Internet experts convened by Verisign Inc including insert your name here has discussed ., the panel did not come to consensus that .. . I would rather use existing fora such as the relevant IETF WG(s) or this list. Daniel
Re: VeriSign Capitulates
On 06.10 10:54, [EMAIL PROTECTED] wrote: There is no data to indicate the core operation of the domain name system or the stability of the Internet has been adversely affected, VeriSign's Galvin said. This means that there are no papers published or conference presentations which detail the problems caused by sitefinder. http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
Re: Is there anything that actually gets users to fix their computers?
On 03.10 04:12, Sean Donelan wrote: Short of turning off their network access, why won't users fix their computers when the computer is infected or needs a patch? Hey, it's working! If it ain't broken Related question for network engineers: When did you have your last medical check-up? To what extent do you follow your physician's recommendations? Daniel
Re: Is there anything that actually gets users to fix their computers?
On 03.10 10:36, Erik-Jan Bos wrote: Hey, it's working! If it ain't broken I doubt this. Recently, I worked with a couple of people that each had their PCs infected. Their own virtual neighborhood complained to them, and they surely were embaressed about the situation, but... They just did not know how to fix it, i.e. where to start. Call it cluelessness, call it lack of education. There is that too; but I have frequently observed people not doing it even when provided detailed step-by-step instructions. On the other hand they would proceed relatively quickly once it stopped working, e.g. the Internet plug was pulled. Some of them would use the instructions provided, others would get help; but not before it stopped owrking. The most successful tactic I have seen is for providers is to block all Internet access except the one to the site containing the instructions and the fix. Of course that is often not a viable business proposition Daniel
Re: Is there anything that actually gets users to fix their computers?
On 03.10 10:59, Erik-Jan Bos wrote: Perhaps an auto club for PC-users: You call and within the next 24 or 48 hours, depending on your subscription, an expert would dial in or come by to get you on the virtual road again. If this was a viable business proposition, it would exist. My experience is that the product to be maintained is both too complex and too badly designed and engineered to be readily maintainable. In other words: This is more viable for cars than for personal computers and more viable for MacOSX than for WIntel. I speak from 10+ years of experience as friendly computer expert for the virtual and physical neighborhood. Daniel PS: The health question in my original contribution was serious. Digression 1: Cars have become less maintainable by the auto club because of added *proprietary* complexity too. Digression 2: I also help maintaining computers at the primary school my kids attend. When I started this, the soloution that could be maintained by professionals was all new WIN NT servers and all new WIN 2K workstations. Luckily (sic!) the school could not afford this by a fair margin. The mainenance offer was all-in for a periodic fee. Now the professionally maintainable soloution is based on Linux servers. This is moving in the right direction both from an enginieering and cost view point. However the maintenance offer is now buy blocks of support hours at a discounted rate. My guess is that the substance of the maintenance deal has not changed; they have just become more honest in selling it. :-( ;-) So even for a small business this option does not really exist yet. Back to work Daniel
Re: what happened to ARIN tonight ?
On 29.09 10:27, James Cowie wrote: Single-homed /24 through UUNet's 7046 to 701. Withdrawals started at 01:21:38 GMT (21:21:38 Eastern time), and ARIN flapped severely for about fifteen minutes. Then they spent another hour and ten minutes inconsistently reachable from half the world, with the picture mutating slowly. 701 seems to have been telling inconsistent stories about ARIN's reachability, depending on which of our peers you consulted -- IGP instability? By 03:10 GMT everyone seems to have slowly gotten a consistent picture again, with ARIN restored. The RIPE NCC Routing Information System saw a very similar picture: Flapping from 01:20:50Z - 01:38:22Z, consolidation 01:59:46Z - 02:28:20Z. For details see: http://www.ris.ripe.net/cgi-bin/risprefix.cgi?net=192.149.252.16%2F32preftype=lspecaction=SearchstartDay=20030929startHour=00startMin=00startSec=00endDay=20030929endHour=06endMin=00endSec=00rrcb=allpeer=alltype=%25sortby=stimeoutype=html.cgifields=type http://www.ris.ripe.net/cgi-bin/risprefix.cgi is quite useful in answering questions like this, i.e. What happened to prefix x.y.z/a between times t and u? It is near real time with a lag of typically 5 minutes. Daniel ~
Re: Verisign Responds
On 23.09 06:07, Paul Vixie wrote: We call on the IAB, the IETF, and the operational community to examine the specifications for the domain name system and consider whether additional specifications could improve the stability of the overall system. Most urgently, we ask for definitive recommendations regarding the use and operation of wildcard DNS names in TLDs and the root domain, so that actions and expectations can become universal. With respect to the broader architectural issues, we call on the technical community to clarify the role of error responses and on the separation of architectural layers, particularly and their interaction with security and stability. and it does seem rather urgent that if a wildcard in the root domain or in a top level domain is dangerous and bad, that the ietf say so out loud so that icann has a respected external reference to include in their contracts. The IAB has done an excellent job with http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html. I quote: ... Proposed guideline: If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone. Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records. For zones that do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone's permission. We hesitate to recommend a flat prohibition against wildcards in registry-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users. We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? This should be enough of an expert opinion for ICANN and others like the US DoC in the sort term. Verisign have realised that and are talking about an -so far vapour- expert panel to counter that. I wonder about its composition . Daniel
Re: Verisign Responds
On 23.09 14:34, Paul Vixie wrote: What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed. brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ... Daniel
Re: News of ISC Developing BIND Patch
On 17.09 00:50, Sean Donelan wrote: On Tue, 16 Sep 2003, John Brown wrote: not all the *root-servers* carry .arpa or in-addr.arpa J (one of verisigns) does not carry this zone, based on their own internal decision. Actually, I thought that was one of Jon Postel's decisions when they were experimenting with creating root-only root servers. Correct. Unfortunately, the progress on that front didn't continue after the DNS wars started. Progress has continued albeit so slowly as to resemble stagnation. Daniel
Re: Not the best solution, but it takes VeriSign out of the loop
On 17.09 04:27, Paul Vixie wrote: speaking for f-root, we won't be cooperating with anything like that. speaking for k-root we will not either. ... sounds like mob rule to me -- count me out. so, block me first, i guess? block us second. Daniel
Re: Dynamic Internet Maps based on BGP table / AS_PATH
http://www.ris.ripe.net/cgi-bin/risas.cgi Select output format graphical. The really nice feature is that you can do this for any time in the recent past and from multiple view points because it works off a database of BGP data collected in 9 places all over the globe. Feedback welcome! The netlantis tool mentioned earlier works off (part of?) this data and produces a nicer output for some purposes. Daniel
Re: Dynamic Internet Maps based on BGP table / AS_PATH
On 09.09 17:09, Mehmet Akcin wrote: hey are you looking something like that? http://www.netlantis.org/index.php?menu=2page=gasp Actually much nicer is now http://www.netlantis.org/index.html?menu=2page=sagm This is *really* cool. Daniel
Re: rfc1918 ignorant
On 23.07 10:07, Kevin Oberman wrote: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) You read this correctly. We also wrote: It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. I consider this quite explicit. I also consider this still very valid. Imho the PMTU argument is moot. This should not be an issue at all other than on the edges these days. Should it nonetheless be an issue it can be done in the boundary routers which have interfaces numbered public address space. I do not know all the details here, so if I am wrong in detail, please tell me. Daniel
Re: it's 1918 in bologna
On 10.07 19:56, Randy Bush wrote: note the 37. address. cute, eh? and i thought omphaloskepsis was greek! Someone is going to have fun when tat part of 37/8 gets assigned and used. as the us military is blocking overseas access to more and more address space, i guess non-american isps can use that space with impunity. ^ Do they publish a list? ;-)
EOF, Amsterdam, September - Call for Presentations
[apologies for duplicates, hint: they have the same message-id] Hi Network Operations Folk, the holiday period is starting! A good time to consider preparing a presentation at the European Operators Forum (EOF) to be held during the 46th RIPE meeting in Amsterdam on September 1st and 2nd. We would like to have as many practical, hands-on presentations as possible this time. Remember: They do not have to be long. We prefer an stand-up interesting 10 minute presentation over a well prepared 90 minutes explanation of something not so interesting to operators. Find some information about presenting below and think about all those experiences this year that might be interesting to other operators. For the EOF Coordination Group. Daniel Karrenberg -- The EOF The European Operators Forum (EOF) exists for the exchange of Internet operations experience. It has evolved from the information exchange part of the early RIPE meetings to provide an open forum outside of the work programme of the working groups and the RIPE plenary. The EOF aims to attract presentations relevant to network operators, practical hands-on reports, outlines of future developments and small tutorials. Product marketing presentations are not appropriate, user experience reports are. The EOF programme is assembled by an informal coordination group that is always looking for new people who are able to help by attracting interesting presentations and supporting presenters. Contact: Daniel Karrenberg [EMAIL PROTECTED] Presenting at the EOF The EOF wants to attract practical hands-on experience reports. We aim to make turning interesting experience into a presentation as easy as possible. Consider the following: - presentations do not have to be long Something interesting can be said in as little as 10 minutes. This limits the time spent to prepare material and often is a good way to start for first-timers. - support is available We will do our best to support you in preparing your presentation. If you want, we can help structuring your material, help to polish language and arrange for a test-run of your presentation. We can also try to arrange for someone from the same country or region to support you if that is helpful. We can also help you find someone else to present your material in case you cannot make it to the meeting. In short: If you have something intersting to say, we will help you do it! Contact Daniel Karrenberg [EMAIL PROTECTED] for more information. - no product marketing presentations The EOF is *not* an appropriate forum for product marketing presentations. User experience reports which are presented by users are definitely relevant. In-depth technical presentations or tutorials are also possible. We expect to finalise the program in early August. We will get back to you then with scheduling details. In the meantime please provide the information below. We place special emphasis on the abstract which should contain references to related material already available if possible. Please send this to eof-coord at-sign ripe.net. - Author(s) - Speaker - (Working) Title - Abstract - Draft Presentation (if available) - Relation to other known work and/or presentations if known - Time Requested It would be helpful if the abstract was written such that potential attenders will learn what to expect from the presentation, i.e. The presentation will describe our experiences with the Red Packet Washer (http://www.netdet.net/RPW/). We have been using the device for half a year now. It helps us deliver more hygienic datagrams to our customers and peers. We will discuss problems with packet discolouring as well as increased throughput to our upstreams due to decreased clogging by dirty micrograms. We will compare performance with the hand-scrubbing of packets which we used previously. Currently we are optimising device management and getting bugs resolved. We will strive to include the latest experiences in our report. is much better than The presentation will describe the Red Packet Washer made by Network Detergents. More information about the meeting can be found at http://www.ripe.net/ripe/meetings/ripe-46/index.html Should you have questions, please do not hesitate to contact me by e-mail at any time. During July and August my response time may be slightly longer than usual due to the holiday period. Thanks Daniel
Re: it's 1918 in bologna
On 10.07 12:19, Randy Bush wrote: ... note the 37. address. cute, eh? and i thought omphaloskepsis was greek! Someone is going to have fun when tat part of 37/8 gets assigned and used. Daniel From http://www.quinion.com/words/weirdwords/ww-omp1.htm : OMPHALOSKEPSISI pronunciation Contemplating one's navel as an aid to meditation. This word seems to be relatively new, at least the Merriam-Webster Word of the Day column claims it to have been invented only in the 1920s. It turns up in only a few dictionaries and seems to be a word that survives more for the chance to show off one's erudition than as a real aid to communication.
Re: Mark Allman: Internet measurement: what next?
On 08.07 14:59, Jack Bates wrote: The RIPE-NNC tests are much more related to what I was refering to, although they are limited in many reguards. If you tell us what limits you want removed we may work on that! We are definitely working towards making the results generally available; see http://www.ripe.net/ripe/docs/ripe-271.html for details of that proposal. So far we have had very positive reactions on this although some ISPs are worried about being exposed in comparison to competitors who do not participate. We will also add quite detailed measurments of DNS servers for the root and TLDs. Data has been taken for several months now. A beta version of the resulting products will be available soon. I have been thinking about a multi-tier measurement network, adding probes that do not have dedicated hardware and high precision clocks, but rather conisist of just a software package. These could be deloyed more easily. Daniel Karrenberg RIPE NCC
Metoo Was: Pesky spammers are using my mailbox
On 03.06 13:44, Dominic J. Eidson wrote: I'm having a feeling that someone harvested a bunch of adresses, possibly from NANOG, and is using them as the sender address in pretend-to-be KLEZ spams.. I have received several bounces lately, several of them appearing to be KLEZ, all with me as the original sender Just to add another data point: The same thing started happening to me a few days ago. I do not know any of the recipients of the bounces but some people I *do* know advised me they are getting them. I cannot say whether this is really KLEZ or not, not enough data. Daniel
Re: BGP to doom us all
On 28.02 18:13, Barry Raveendran Greene wrote: Now - show me an operational environment on the Internet were this authorization chain is _working_ today. RIRs and RADB do not count. As you mention before, those databases and keeping them up to date are a pulling teeth exercise. ... My opinion is that lazy operational practices are the single biggest threat to the Internet. What's the point of building security and robustness into a system when people choose not to turn it on? RIRs do count and the infrastructure to set up the chain is there. Address assignment and allocation is a quite formal and well recorded process these days. The address *allocationassignment* databases are in good shape for about the last 8 years. The fact that they are not in good shape for assignments from the good old days is true. But this is being actively worked on and one should not blow it up out of proportion. Deploying technologies like SBGP would of course provide additional incentives to record allocations and assignments and the resulting signing of certs even better. Daniel
Re: Bell Labs or Microsoft security?
On 29.01 03:32, Sean Donelan wrote: ... Multics security. Bell Labs answer: Unix. Who needs all that extra security junk in Multics. . [reader warning: diatribe following] Gee, there once were a handflul of people; their principle goal was to make an OS for their own use. They did it in such a way that it could be developed by its users while they used it. Creeping featurism was held down successfully, at least initially ;-(. It ran on platforms orders of magnitude cheaper than what Multics ran on at the time. It taught a lot of people about programming style. I hope I learned some things from it. And they wrote up the shortcomings of the security architecture concisely at the time this began to matter. They understood stuff that M$ with its creeping featurism, low support cost defaults, undocumented API of the week cannot possibly begin grok and deal with because of ETOOBIG. Now you and I use it because it does the job better than anything else. Then you blame them for not designing in today's requirements 30 (not 20!) years ago. Give them a break ... Daniel PS: Worm? Virus? Who wrote this up concisely first? PPS: Plan 9 anyone?
Re: Important Informational Message - root.zone change
At 12:59 AM 11/5/2002, Sean Donelan wrote: Since its been 5 years since the hints/cache boot file has changed, it may be useful to remind people an immediate change to your local configuration files is not required. You don't need to slashdot internic.net tomorrow morning trying to download the file. As long as 1 listed IP address responds with the current list of root servers, the server doesn't even need to be a root server itself, your name server should figure out who are the current roots. In the 1980's and 1990's when the hints/cache file changed regularly, some people when years without updating it. Or only updated it when they upgraded their name server code. Don't Panic. Well said! I am quite disappointed that ICANN has not included similar language in their announcement. They know better. Daniel
Re: WP: Attack On Internet Called Largest Ever
At 07:50 AM 10/23/2002, Jamie C. Pole wrote: It's a terrible thing when the most competent assessment of an attack comes from a company spokesperson, rather than someone just a little more technical... In my reality the shop floor is not allowed to comment on something that is seen as vital to a corporation's interests at all. This in order not to destroy carefully crafted statements by the spokespeople vetted by the lawyerpeople. Such statements tend to be designed to hide the bad news and amplify whatever snippets of good news can be found. The *perceived* affluence of *comptetent* technical people has an effect on this: It makes the shop floor *much less* likely to talk even to peers for fear of their jobs. Daniel
RE: WP: Attack On Internet Called Largest Ever
[Longish diatribe. I just use my share of bandwidth here in larger packets. I hope you will consider S/N large enough] At 04:51 PM 10/23/2002, Joe Patterson wrote: would it cause problems, and more importantly would it solve potential problems, to put some/most/all of the root servers (and maybe gtld-servers too) into an AS112-like config? Is it a problem that's even worth looking at? It is definitely worth exploring. As David Conrad pointed out, the technology is there. Also it is very appealing in terms of DDoS resistance and general distributedness that works so well for the Internet. Is it a solution that's worse (for some reason I haven't noticed yet) than the problem? The problem is making absolutely sure that the root zone that is served is authentic. For AS112 this is not really important because the queries it syphons off are all bogus anyways. So I could not care less if they received bogus answers. For the root this is an entirely different matter! Of course if we had DNSSEC widely deployed it would be a no-brainer. But I am afraid that is going to take a long time; I hope it happens before DNS itself becomes obsoleted. So with the lack of DNS security the problem could be mitigted by routing security, i.e one could have some trust in the place the information comes from instead of having the information itself authenticated. However there is no such thing as routing security either. The best we can do in the absence of pertinent security technology is to try to distribute things carefully; always making sure that ISPs, and end-users if they wish, have current and usable information to determine themselves which DNS servers and which routes to them they trust. While doing this we also must maintain clearly the responsibility of the server operators to serve the authentic unique root zone and to provide a consistent service with good performance. At the same time there is the ever increasing number of self appointed people suggesting to run root servers for a variety of motives, usually even good intentions; however with the potential to change the content of the root zone *without accountability* or even without telling the users of those servers. Those who know me will testify that I am a very grass roots, bottom-up oriented person suspicious of centralisation and hierarchies. But the prospect of having multiple differing instances of the root zone in the Internet makes me very uncomfortable. In fact it would mean that we will have no Internet any longer but different networks, that one cannot trust any longer that a hyperlink will end up in a single place, that a server is really the one one intends to talk to etc. pp. Unfortunately we do not have the security techologies deployed yet that will alleviate this problem. So we have to keep things together for some time or end up with no Internet left. Daniel
Re: More federal management of key components of the Internet needed
At 07:05 AM 10/24/2002, Alan Hannan wrote: It worked for airline security. Oh, did it now? Just to paraphrase Seans very professional language: Before the US government proposes to unilaterally take responsibility for a particular service it should consider its track record of providing parts of that particular service in the past. Not to mention that the service serves the World and not just the US. Daniel
Re: IRR listing of IANA-reserved, a question..
Speaking for myself too: I have been wanting an *authoritative* *single* listing of unallocated address space for at least 6 years. Note that this is at a finer granularity than the IANA allocations list and it would have much more frequent changes than the IANA list as address space is allocated to local registries. However it could include a more coarse data set that changes less frequently for those that do not want or need the higher granularity. The only way to make this happen is for the RIRs to collect this data among themselves and publish it regularly. Because of the possible ramifications of errors in this list it is not as simple to do that reliably as it may seem at first glance; but it should be done. I know that the RIRs have efforts underway to publish such authoritative lists. I do not know the exact status of this work. But I fully agree with your requirement for a *single* *authoritative* list. Of course I would use it in the routers I operate. However these are not significant to many peoiple these days. Daniel PS: I do not care at all about the format as long as it is readily machine parseable. Daniel
