Re: what the cause?
[EMAIL PROTECTED] (Frank) wrote: all the AS numbers are the same Yes, one can see that. Looks like you only get a default from your transit. Background: The AS number in [brackets] is determined by a lookup in the router's RIB. So if you only have the default (from AS6163 as it seems), the lookup result will always be 6163. Elmar. -- Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden. (Marius Fränzel in desd) --[ ELMI-RIPE ]---
Re: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
Eduardo :) The best of my thanks for this really good work; including tests for prefix reachability is something I'd call essential. I have btw implemented your prefix list filter additions (with the exception of the RIPE lines; I want to see everything local), and my table is down to 167K prefixes (from 234K). Before anyone asks: I do get defaults from my transits ;) Yours, Elmar.
Re: large-scale wireless [was: cpu needed to NAT 45mbs]
[EMAIL PROTECTED] (Frank Bulk) wrote: If you're going with Extricom you don't need to worry about channel planning beyond adding more channel blankets. Is that based on marketing, theory (based on the whitepapers and patent descriptions) or practical experience? Elmar.
Re: qwest backbone
[EMAIL PROTECTED] (David Ulevitch) wrote: Philip Lavine wrote: Any issues on the qwest backbone Something fun up in SEA. We see 701 down and 2914 down in the westin building as of about 10-15 minutes ago. I saw a glitch on the way to 703 (via 701); NY seems to be ok. Downtime 15 minutes. Elmar.
Re: BGP Problem on 04/16/2007
Hi Steve, [EMAIL PROTECTED] (Stephen Wilcox) 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... Cheers, Elmi. -- Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden. (Marius Fränzel in desd) --[ ELMI-RIPE ]---
Re: AS41961 not seen in many networks
Hi Sebastian, [EMAIL PROTECTED] (Sebastian Rusek) wrote: Since November 2006 we announce our 3 new prefixes: 194.60.78.0/24 194.60.204.0/24 194.153.114.0/24 from new AS41961. It seems that somewhere our announcements are blocked probably due to bogon lists. To make it easier for everyone - could you provide hosts in each network that are pingable? Yours, Elmar.
Re: Cogent now peering with Sprint?
Hi Fredy, [EMAIL PROTECTED] (Fredy Kuenzler) wrote: Think of 174 started to peer with 1239 and redirecting some outbound traffic to 3320 over this new peer. Since 3320 is buying from 1239, they will pay more to 1239, and 1239 accepts 174 as a new peer because they get more money from 3320 ... as mentioned, this is just a rumour I heard, but reading William B. Norton's theory (tactic #9), this would make sense. In the very least it's eventually something to use to put pressure on those AS3320 guys. The idea is pretty smart ;) Elmar. -- Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden. (Marius Fränzel in desd) --[ ELMI-RIPE ]---
Re: power cords for .nl
[EMAIL PROTECTED] (Mark Foster) wrote: I take it you were after info other than that found at urls similar to this one? http://www.dbicorporation.com/internat/intpower.htm (which will show you that the local outlets are the same as in Germany or Korea, Schuko type, just for the record) I would've thought that datacentre internal cabling for mains would be a different can of worms anyway, in my experience most primary power distribution is done from a 3-phase lead into a PDU and from there into IEC strips, with local mains-interfaces being fairly secondary in nature. So wouldn't you mainly want IEC male-female type? Problem is, the 6503E's power supplies take 20-Amp cables and have the appropriate connector (IEC 320 C20). The appropriate sockets (C19) are a bit hard to come by in data centres, and, of course, all of this is unnecessary in Europe, where Voltage is above 200. We faced the same problem last week (getting the 6503s plugged into APC power strips which only have C13s)) and bought ourselves adaptor cables that let plug into the Ciscos' C20 on one and C13 on the other side. If anyone wants to buy, we got them from 3KV in Munich (contact Norbert Wöllner at [EMAIL PROTECTED] and give him my regards). Good luck! Elmar. -- Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden. (Marius Fränzel in desd) --[ ELMI-RIPE ]---
Re: cctld server traffic
[EMAIL PROTECTED] (Randy Bush) wrote: any cctld ops seeing unusual traffic in the last hours? .de didn't. What should we have expected? Cheers, Elmar.
Re: a record?
[EMAIL PROTECTED] (Sean Donelan) wrote: Security by obscurity eliminates all (100%) of this automated scans and automated attacks. So, having SSH on port 63023 (for example) and seen probes, you can be 100% sure that someone have SPECIFIC interest in your This is just security by outrunning the bear. The assumption is bears will stop chasing you if they catch a different hiker first. You're failing to catch the intention here. Unfortunately, we now have decades of experience in cybersecurity that this isn't true. It appears to work for a while, but on the Internet bears are always hungry and learn. There are people actively scanning for any open ports running any protocol, without a SPECIFIC interest in your computer. Funnily, I see many many more scanning attempts for the same port (or handful of ports) across entire networks than the other way around. And as stated before: If somebody scans 63023, he has interest in your site and is worth the effort of doing something about it. That's the whole point in changing the port. Changing the port is not making the system more secure, it only filters out passers-by. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: a record?
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote: I'm going to repeat what Sean said, because you clearly didn't read what he said: You're trying to be harsh, even though I don't understand why. I read what you just rephrased, and I understood it fully, believe me. Let me explain my lines of thought here. I am fully aware of people scanning the full range of ports, but then, it's a _WHOLE LOT_ less full-port-range scans than full-address-range scans. You will see that in your logs, too. If the guys have found an interesting machine, they will scan all ports, sure, but then you _WANT TO DEAL_ with these guys. Whether it is because they are interested in you, or whether it is because they found a box worth cracking. That of course leaves aside the few guys who really try full-port-range scans on a lot of boxes or, accidentally, the ones I look over. I may be wrong in assuming they are taking interest, but I take interest in them and do something. It still is a lot less incidents to focus on. Saving unnecessary work is all that this is about, not whether or not I believe something (this being safer than that, that guy having a specific interest in this, whatever). Actually, I really don't care about people scanning closed or blocked ports. Except for a few potential target addresses, that is. But of course I am not doing this by reading server logfiles and wading through folks trying dictionary attacks on just-found-to-exist ssh ports. That's what firewall and ID systems are good at. Most of the time I get interested when they get interested, or when there's someone coming up, doing something more elaborate than running one of the easy scripts. Apart from that, I am simply not interested, because I have other work to do. And if I get rid of dummy alerts by changing the port for a generic login service, so be it. It's a tool to save work. You don't have to use it. Elmar.
Re: [NANOG]Cogent issues
[EMAIL PROTECTED] (Lyons, Myke) wrote: For the past hour or so a number of sites that I have with Cogent have been unreachable. Also, I am unable to get through to their support line. Is anyone else seeing this? Just to make analysis easier: Which prefixes should be missing? Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Scalability issues in the Internet routing system
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: I'd have to say that RFC 3513 is out of touch with reality here, yes. As far as I know current routers with hardware based forwarding look at the full 128 bits - certainly our Juniper routers do. Ours do as well, but essentially, that's because they are internal to our network. Nobody would need that in the shared DFZ part, there I agree with Rubens. So although you would need the longer prefixes (right up to /128) in your routing core, you would not necessarily have to have them in your edge routers (as long as they don't directly connect to your core, like Cisco keeps telling us we should do). Dunno whether that's a feasible approach, probably not (big transit providers essentially pushing transit through the core), but if possible, it would lighten the routing burden a lot. Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Recommendations for ISPs around the world
Dear colleagues, I'm at a loss here. My current project is to find good transit providers in those regions: South America, Eastern Europe, Africa, Asian-Pacific. Requirements are simple: - good regional connectivity/peerings - fair reach to mainland Europe (London, Amsterdam, Frankfurt) - locations close to exchanges (so we can join there, too) I'm thinking of using two transit ISPs per location (full BGP from our side, of course). I have considered MCI, BT Infonet, Verio, Reach, Sprint, for AP and/or Latin America, but they of course all tell you that they are greatly interconnected. For eastern europe I'm really at a loss, and Africa seems to lack regional connectivity. All I can found is local stuff. So, if anyone can give me a hand here, that would be greatly appreciated. TIA, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
Re Owen, Just a short (ok, now I read it again, it's grown...) answer to the list, but you're right, we might continue this in private. (Reply-To set) Thanks for being so patient explaining everything, and for discussing with a (still somewhat) hairy-head like myself :-) [EMAIL PROTECTED] (Owen DeLong) wrote: You're only talking v6? Why? Anyway, let's follow this through... Because we don't really need to solve this in V4. V4 multihoming is well understood and is unlikely to hit a scaling limit on router capabilities before we hit an end of life on address space. ... Again... Multihoming already works in V4 and there is no real need to solve this in the V4 world. I can expect a strongly rising demand of end-customers to multihome right now, and we still have a bunch of /24s to go on. But then, it may only add another 300Kprefixes to the BGP table, which is not really an order of magnitude. As to the it works - surely it does, but up to now I believed it wouldn't scale far enough. Maybe I'm wrong (see Moore). You only need one RLI in the packet header. More would actually be bad. Let me 'splain. If you are routing on RLI, then, you need to choose the best path and stick to it. If the packet doesn't make it through that way, that's OK... That's what retransmits are for. If you start rerouting it on the fly, it's likely to loop a lot before dying, but, little else is achieved. Worse, it's likely to loop even if it might have gotten there given one path and only one path chosen as best by the RLI inserting router. Actually, I don't understand the last part; why should it loop in this case? It's a matter of destination(s) look-up on the core routers, just like in your model. Only the destination's potentially more than one. It would of course loop anyway if it entered (the same part of) the same transit AS again, but that is independent of whether you see the ESI or not (aka RLI insertion vs. encapsulation). I'm still not comfortable with the box in Sao Paolo determining whether the packet should go to ISP A in Hamburg or ISP B in Munich or ISP C in Frankfurt (from where the respective ISP would forward it to the customer in Cologne). This decision can easily be made later on and result in a better path. No, it is not. Since the RLI inserting router has up to date dynamic information about which RLIs are reachable and at what cost (BGP The inserting router is less probable to have up-to-date RLI topology information than routers closer to the packet's destination, due to the way the topology information gets distributed. No. You have nearly the same advantage you have today. If the path goes away, then, hopefully by the time of retransmit, the RLI inserting router will have learned that that RLI destination is no longer reachable, and, he will insert a different one in the retransmitted packet. Same as what happens today with the retransmitted packet being sent a different way. I don't like hopefully here, but maybe that's our trade-off anyway. You are, nonetheless, giving the RLI inserting router somewhat hotter information, if it has to make the topological choice (choose destination RLI and, implicitly, select a group of possible paths over all others). If it were only to know the translation information which does not change as often, I'd be much happier. What I also do not like is the wrong analogy to today's routing mechanism. You claim implicitly that the RLI inserting router's new decision was the same as what happened in the Internet routing system today: rerouting packets. This means, in other words, you're making a global choice locally. But of course, the current system does not reroute at the packet source (only), it can do this on any hop between source and destination and thus makes only local choices locally. This is a significant difference, because it makes adaptation to changes easier, faster, and it works with only partial convergence along the path. Who exactly chooses? IMHO it's AS B that does the selection. And: B is closer to the target, aka the source of the routing information. Its BGP table is more probable to be up-to-date. Right... B is the first DFZ router. A is not likely DFZ since A is not multihomed in your scenario. No need for A to be DFZ if A only talks to B. Yesyesyes, consider A B C D E F T A B C D G H T What now? Is D necessarily the first DFZ router? I think not. So you are still using B for the RLI insertion; B has to make the choice, and that choice may be wrong or sub-optimal. Z's ESI is visible in the core, but, not carried in the routing table. Z does not have an RLI, but, instead uses the RLIs of their provider(s). Yup, in your add something to the header scenario, the ESI is still visible. In mine it is not (it is, but encapsulated). Actually, it does not matter, as long as the destination can revive this information (destination as in the re-translating router). In the long run (once
Re: /24 multihoming issue
[EMAIL PROTECTED] (Kyaw Khine) wrote: I opened ticket with both 701 and 19094 when we did failover 2 weeks ago. Both 701 and 19094 insist that they just take the route and send it out to the rest of the world. I do see the prefix via both 701 and 19094 (heavily prepended) here in Frankfurt, Germany: 5539 3549 701 33105 12312 3257 7911 19094 33105 33105 33105 33105 5669 286 209 701 33105, (received used) 8220 2914 701 33105 (and some dupes) Neither one seems to filter wildly; I would believe that you hit aggregate-based (what's an allocation in ARIN terms?) ingress filters somewhere. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
I wanted to answer on this, because I thought along the same lines. [EMAIL PROTECTED] (Owen DeLong) wrote: For example: Host A connected to ISP X then ISP Y to ISP Z which provides service to Host B. Today, A, X, Y, Z all need to know how to reach B. If we separated the RLI from the ESI, then, the fact that B is reached via Z only has to be available information that can be looked up by A, and, X and Y only need to know how to get to Z. Only Z needs to know how to reach B. This allows the amount of data kept by each point along the way to be much smaller. My idea (somebody had it before, I'm sure, but then, it is my head that got invaded by it, so here she comes...): Rewriting would IMHO not work easily, but encapsulation would. Admittedly, this idea has occurred and lead to MPLS implementations (which are weak at interconnecting ISPs anyway). Well, let's see what else we can do, that MPLS maybe cannot. If the end user does not determine the RLI themselves, but their ISP does (on edge routers), it looks like this: A is the customer, Internet access provided by X B is the customer of Z Y is an intermediate system A - [Src: a.b.c.d Dst: e.f.g.h Data: ...] - X X - Add envelope - [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] X - [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] - Y Y - [RLI: Z [something]] - Z Z - Remove envelope - [Src: a.b.c.d Dst: e.f.g.h Data: ...] Z - [Src: a.b.c.d Dst: e.f.g.h Data: ...] - B Routing decision is thus made by looking up paths for Z. Multihoming works the same, but we get multiple RLIs in the packet. If B is multihomed, I am not in favour of A (or X) selecting the location of B to be used. I believe the routing system should be able to determine that, like it's done right now. We have some major points here, and one possible ballbreaker: + Prefixes (ESI) have gone from the routing process + Customers are hidden behind their ISPs + Packets carry their routing information (instead of ESI info) + Packets may as well be deeply inspected, if necessary - Edge routers need to be extremely powerful, because they have to determine all the ESI - RLI information Ballbreaker (shared with Owen's idea): - This scheme needs the ISPs' edge routers to do the looking up, and if we do not find a way to incorporate updating the lookup table into part of the routing system, we are in violation of Par. 2.1.20 of draft-irtf-routing-reqs-03.txt, which is a very sensible requirement IMHO. I'm not saying this solves all problems, but I did not want this idea lost in the mists of time; maybe it's a starting point, maybe it is not (I'm still not through with the draft). But at least it differentiates between DFZ (aka Internet Core) routing and edge routing. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Scalability issues in the Internet routing system
[EMAIL PROTECTED] (Tony Li) wrote: Please expect that your idea has been discussed before. We're an old bunch. ;-) I've just answered on a mail from Owen, so maybe you get the feeling of oh, we discarded that long ago when you read it. Please tell me ;-) Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
[EMAIL PROTECTED] (Owen DeLong) wrote: Why wouldn't rewriting work? The encapsulation you show below is little different from the rewrite I propose. Except that it conserves the original addressing information, which I believe to be important. First, let's start with something that looks a little more like an IPv6 datagram: You're only talking v6? Why? Anyway, let's follow this through... [DST: ::B Src: ::A EXT[RLI: Z] Prot: ICMP [...]]] Then, Upon arrival at the first Router within AS Z, the packet is rewritten again: [Dst: ::B Src ::A Prot: ICMP [Type: Echo Req [Data: ...]]] You have used special fields in the IP header. Well, that's an elegant way to do it _if_ you have this field. You do not have this in IPv4, and that's what we'll be stuck with for the next couple of years, unfortunately (or not: I can remember v4 addresses much more easily...) final packet arrives unchanged. Further, any router along the way that doesn't understand the Extension header doesn't have to really look at it, so, during transition, routing can occur on either RLI or Dst. If you encapsulate, you lose that transitional ability. Good point you have here. Actually, even that isn't necessarily an accurate characterization of what I am suggesting. The packet should not be rewritten until it reaches a DFZ router outside of AS Z. Whether that is within AS Y, or somewhere upstream (possibly more than one level upstream) of AS Y, that's where the initial rewrite should occur ideally. If the first DFZ router doesn't yet know about RLI, however, then, the first RLI aware router in the DFZ prior to reaching AS Z should do the rewrite. I see a couple of shortcomings to your idea: - it is limited to an IP protocol that carries a RLI header field - you only include one RLI in the packet header I do neither believe that we'll get rid of v4 soon, nor do I think it is a good idea to let the sender decide to which RLI to route the packet. The benefit of multihoming is lost then. Um... No... You don't want multiple RLIs in the packet. You want the router inserting the RLI to have the ability to chose from multiple RLIs. Definitely not. If you start playing with changing RLI along the way, then, you run into serious difficulty with looping possibilities. That is not intended. Another way to avoid loops must be found, and I believe the danger is pretty small. The RLIs in the packet are not changed in transit. But of course every new router can choose towards which RLI to send the packet. Luckily, distance on a working path in the Internet generally decreases as you approach a target you have chosen. I do see that there is a danger of looping, but I believe a way to detect that can be found. By choosing an RLI close to the source that, at the time of selection, had a valid dynamic advertised (BGP) AS Path for reachability, you seriously reduce the likelihood of looping the packet. Yes, but you lose the benefit of multihoming, because the rewriting edge router may carry outdated information or simply make a bad choice. I'd rather have routing intelligence in the core than in the edge. If B is multihomed, I am not in favour of A (or X) selecting the location of B to be used. I believe the routing system should be able to determine that, like it's done right now. Look... The first DFZ router selects the location of B to be used in todays world, why should this change? I am not sure why you believe that the firsts DFZ router that is being traversed does the choice today. In paths like (from source to multihomed-target): A B C D T A B E F T Who exactly chooses? IMHO it's AS B that does the selection. And: B is closer to the target, aka the source of the routing information. Its BGP table is more probable to be up-to-date. + Prefixes (ESI) have gone from the routing process That's a GOOD thing. Yup. Longest match sucks. + Customers are hidden behind their ISPs I'm not sure what you mean by that. Neither customer Z's ESI nor RLI (they don't need one) are visible in the core. Only their ISPs' RLIs are visible. No... This scheme needs DFZ routers to do the lookup. This is going to require significant changes to RFCs for full implementation anyway, and, no, the whole point of my proposal is for routers NOT to have to carry full lookup information, so, it is my intent to modify that requirement. If I understand the idea correctly, you have to distribute two types of wide-area routing information: One ESI-based and one RLI-based. This is because any DFZ box max or may not be able to RLI-route and/or, if it sees that that's not been done yet, perform the translation. Of course, not every DFZ router needs both those tables, but there are some that do. Oh, and you do of course have to distribute the mapping info. But at least it differentiates between DFZ (aka Internet Core) routing and edge routing. I think that is the necessary first step.
Re: Scalability issues in the Internet routing system
Susasn, Using the compression (cooking) per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a minimum set of routes can provide some leverage against the prefix growth. By cooking down the prefixes you unfortunately lose topology information which might be a bad thing, and at the same moment disrespect the site's wish to how it would like to be routed. Another bad thing, if you think of companies/sites paying for the entire network in the long run. Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes. I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions? Yours, Elmi. PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)? -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Scalability issues in the Internet routing system
[EMAIL PROTECTED] (Andre Oppermann) wrote: Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes. And this won't change in future. I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions? Yours, Elmi. PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)? With pretty high certainy one can say that it is an old idea with some minor twist or wording change. I was thinking of something different from Susan's approach, hence my question. Cooking up stuff to save memory and processing in the router isn't it, IMHO, but I have ideas in my head which I would like to share. But then, I wouldn't want to spoil everybody's time if it's old. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
[EMAIL PROTECTED] (Todd Vierling) wrote: Tier-2s should be given much more credit than they typically are in write-ups like this. When a customer is single homed to a tier-2 that has multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's aggregations, that means one less ASN and one or more less routes in the global table. That's the operators' view, but not the customer's. The customer wants redundancy. So we should try to find a way to tell them Hey, it's mostly Tier-1's (or wannabes) that play such games, stick to a trustworthy Tier-2. And, hey, btw., connect redundantly to them, so you have line failure resiliency and also a competent partner that cares for everything else. Only seeing the operators' view will amount to nothing in the customer's will to run along with the Tier-2. Eventually, it breaks down to trust. And customers learn that the big players are not always trustworthy. Oh, and customers do not always remember names. Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote: For the customer with an Internet mission critical app, being tied to a Tier 2 has it's own set of problems, which might actually be worse than being tied to a Tier 1. Please elaborate. Elmar.
Re: multi homing pressure
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote: The problems with a small provider might include: * Business viability * Global reach * Capacity * Redundant architecture * Etc., etc., etc. Thanks - understood ;-) I see, btw, a lot of Tier-3 (or -4, -5) providers that have easily survived their Tier-2 Transits going down the river. If customers can be convinced that the tier thing has nothing to do with business viability and/or stability, and that size does not always matter, we might get them on the right track. As long as they believe the marketing-speak, that Tier-1 ISPs are god (no double-o here) and Tier-2's are still quite good, but everything else is crap for real business, well... Always remember: For every customer, their stuff _is_ mission critical. So everyone will take the multihoming road if they can afford it. We can make it more expensive, or we can offer other solutions. Yours, Elmar (formerly with a Tier-17, quite stable though) -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: multi homing pressure
[EMAIL PROTECTED] (Mike Tancsa) wrote: The customer wants redundancy. The customer wants reliability That's what you know and what I know. The customer has already jumped one step ahead from reliability to multiple providers, just like he does with parcel services etc. There are better ways to do it as you describe below. Yup, but the customer needs to be made aware of them. Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: And Now for Something Completely Different (was Re: IPv6 news)
[EMAIL PROTECTED] (David Conrad) wrote: I'm suggesting not mucking with the packet format anymore. It might be ugly, but it can be made to work until somebody comes up with IPv7. Instead, since the locator/identifier split wasn't done in the protocol, do the split in _operation_. It has been done a long time ago, IMHO. I wonder whether I am the only one seeing this, but we already have a (albeit routing-) locator (ASN) and an identifier (IP address), that are pretty much distinct and where the routing locator is not used inside the local network, but only outside. There's your edge/core boundary. Every multi-homer will be needing their own ASN, so that's what clutters up your routing tables. It's economy there. Btw, a lot of ASNs advertise one network only. People surely think multihoming is important to them (and I cannot blame them for that). Hierarchical routing is one possible solution, with a lot of drawbacks and problems. Forget about geographic hierarchies; there's always people who do not peer. Visibility radius limitation is another (I cannot believe the idea is new, I only don't know what it's called). Cheers, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Cogent move without renumbering
[EMAIL PROTECTED] (Charles Cala) wrote: Q can an end user take non portable ip's with them to another service provider? What in non portable did you not understand? Elmar.
Re: TLD anycast clouds?
[EMAIL PROTECTED] (Steve Gibbard) wrote: I'm attempting to come up with a list of all the top level domain DNS servers that are anycasted. I already know about the anycast clouds run by PCH, Neustar, Verisign, DENIC, and UltraDNS, and .mx appears from traceroutes to be anycasted as well. (I know about the anycasted root servers as well; they're out of scope for this question...) Are there others that I'm missing? Add .de to your list. z.nic.de is anycasted. I'd propose taking the list of TLDs, generating the list of associated authoritative DNS servers (and their IP addresses) and try that list on the routing registries... Cheers, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: TLD anycast clouds?
[EMAIL PROTECTED] (william(at)elan.net) wrote: authoritative DNS servers (and their IP addresses) and try that list on the routing registries... Assuming that you do that, what would you be your criteria to find based on RR if the ip is anycasted or not? Maybe I overestimate the openness of the people and believe everybody would drop their documentation there... ~whois -h whois.radb.net 194.246.96.1 route:194.246.96.0/24 descr:DENIC eG anycast prefix origin: AS31529 ... The AS object gives a lot more clue then... aut-num: AS31529 as-name: DENIC-ANYCAST-AS descr:DENIC eG descr:DNS anycast AS object ... remarks: | DENIC eG operates the .de ccTLD registry. DENICs IPv4 | remarks: | DNS servers are partial unicast and partial anycast. | remarks: | This object covers the IPv4 anycast setups.| ... Maybe using route servers helps more (coffee!) :-) I mean lets suppose that I run dns server at AS0 and peer at location A and also at location B with same ISP with AS1. I might have one dns server at location A and another different one at location B, which means its anycasting. But from peering perspective it would just appear as the same path AS0-AS1 no matter what location it is. That's some kind of anycasting, but from a networking point of view it's redundant links to the same thing ;-) If you are lucky, you can see different next-hops in the BGP. Opposite to that route to the same server might be seen from different peer AS# based on location because of routing policies. Using views from route-servers that are distant from each other might improve the picture. The RIPE RIS project may be able to help. Cheers, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: [Misc][Rant] Internet router
[EMAIL PROTECTED] (Per Gregers Bilse) wrote: My finest Dilbert moment; it's over ten years old now, in fact. [...] *g* It is _so_ true and so happens in probably 80% of the companies. It got so bad that if there was nothing to report (ie, no outages, no problems, everything just worked) Boss was convinced we (network techies) were either lying, or superfluous. I myself get that feeling sometimes. My boss doesn't, because he always knows of one more project that could be done...nasty :-) Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Internet router
[EMAIL PROTECTED] (Aaron Glenn) wrote: Can someone tell me who own this router IP 65.198.220.90? http://ws.arin.net/whois/?queryinput=!%20NET-65-198-220-0-1 Ronald W. Jean Network Engineer Hmm. That somehow sums it up quite good. El why the webwhois? mar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Internet router
[EMAIL PROTECTED] (Elmar K. Bins) wrote: That somehow sums it up quite good. Folks, I'm taking this back, seeing that the original poster is not alone. Makes me wonder as to what current network engineers do know about the world they do networking in. I - please forgive me if this seems far-fetched - would have thought everybody doing real networking (as in interconnecting with other networks) would know where and how to look for that information and how to interpret the usual tools' output. Am I wrong? Puzzled, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: IPv6 Address Planning
[EMAIL PROTECTED] (Alexander Koch) wrote: [/124] Also I cannot help but like how it can be organised with a brain that still works on IPv4 or so. 2^4 is 16, so ::zzx0 up to ::zzxf and, yeah, the next linknet is then ::zzy0 to ::zzyf, with y being just x+1. I second that. I get thoroughly confused every time, there's an xxxa coming up after a xxx9. I tend to use xx10 first, then see that it doesn't work, then remember. Currently we're using /126s on p2p, but I believe a migration would be in order, considering the small amount of addresses we are using anyway. I definitely abstain from /64s. This is wasteful. Yours, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: /8 end user assignment?
[EMAIL PROTECTED] (Joel Jaeggli) wrote: With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS. oddly enough there's been some research on this subject. you might not in fact be able to conclude that if your routing is sufficiently stable. Actually, if you don't allow/do zone transfers (which we don't), TCP/DNS sessions are sufficiently short-lived to function properly. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: OT: Cisco.com password reset.
[EMAIL PROTECTED] (Scott Stursa) wrote: When I tried to access my CCO account this morning I got a page with instructions to email [EMAIL PROTECTED] to get a new password. I did this from the email address registered to me on CCO and promptly received a new password to my email address which worked properly after that. Yeah, I tried that. Didn't work in my case. Neither did it in mine (multiple accounts hooked on one email address is what cco-locksmith complained about). I have sent the appropriate email to cco-team, but heaven knows when they will process it. I give them a day before escalating; I'm pretty sure they're currently pushing staff into the cco-team so the requests can be served. What bothers me is that some people got notifications while others got none - any idea on why (I didn't get any)? Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: ICANN, VeriSign Will Consider Changes on .net Agreement
[EMAIL PROTECTED] (Eric Brunner-Williams in Portland Maine) wrote: FWIW, we did a Major Protest at the Rome meeting about Sitefinder and it took Vint months to come to the conclusion that it (interposition on the lookup error semantics) was not just a business decision. IMHO the entire issue comes down to something like this (please don't nail me on details, it's a coarsely drawn picture): - ICANN issued a formal request for proposals - Some registries-to-be - including Verisign - made offers - ICANN chose Verisign (no speculation about the reasons here) - ICANN and Verising closed a contract that had not really much to do with the original ICANN specs and RfP It's of course at ICANN's leisure to make contracts which stand contradictionary to their original intentions (all very well documented). But considered that pricing (and equal registrar access) was an important issue during the proposal evaluations, it makes me wonder where the free-pricing thing came from anyway. Apart from that, Verisign is throwing a bait here. Everybody will (money's always interesting) take the alright, we'll discuss about the pricing issue and forget about the being allowed additional services without prior ICANN consultation issue. And probably more that's in the contract. All in all, ICANN is losing reputation pretty quickly, and I would not be surprised if the ITU used this to their advantage to get a foothold in the Internet business. I am interested in what ICANN has to lose if it stuck to its original role of some neutral registry-registry. Opposed to what you, Eric, say, I strongly believe that the ICANN folks know exactly what they are doing, and why they are doing it. I also strongly believe that I wouldn't like their reasons. Elmar.
Re: DOS attack tracing
[EMAIL PROTECTED] (Richard) wrote: Ethernet to the primary upstream. I think that the lesson is _always_ use a router powerful enough to handle all ingress traffic at wire rate. Without access to the router, there is nothing you can do. So we are going to switch out the router. If you are mostly concerned about not being able to use the router console during attacks, you may change the CPU scheduling a bit. A brief scheduler allocate 6 2000 has helped me a lot there. The box stays manageable. This does of course not help you with the router going dead in regard to packet forwarding... Yours, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Schneier: ISPs should bear security burden
Ferg, you asked for it. I've been there -- I know how I feel about it -- but I'd love to know how ISP operations folk feel about this. Links here: http://www.vnunet.com/news/1162720 Schneier has a profound interest in the ISPs being forced to buy his (or his competitors) security gear to fulfill the customers' dreams of a clean Internet connection. Pretty biased, if you don't mind. What he lacks to understand is the reasons why ISPs don't do it. It's not just lazyness (only part) or lack of responsibility; it's more like that it's expensive and nobody would pay for it - no, not the customers; they like to get everything for free, remember? The most prominent reason keeping ISPs from filtering their clients' data streams is - tada - jurisdiction. It's simply not allowed in countries that don't officially harvest everything they can get their hands on. There is something called privacy rights. Nobody may legally interfere with the data stream that reaches my boxes, and nobody - not even my boss! - must fiddle with my email if not expressly allowed by myself. So it is a damn good sign of the ISP's responsibility if it does _not_ place filters in the data stream. But then, my sympathies for Bruce have long evaporated, so I am of course biased as well. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Schneier: ISPs should bear security burden
[EMAIL PROTECTED] (william(at)elan.net) wrote: According to my sister (who works in that area as a regional water expert), tap-water is held to higher standards than bottled water. In Canada at least... ymmv. Yeah, gotta to clean it up from pollutants [spam, ddos], add antibacterial [antivirus] agents, check that the supply [latency] is not too low [high], make sure there are no leaks [anauthorized access]. In fact, the tap-water analogy is a very bad and at the same time a very good one. (1) In some countries, tap water is really pure and clean, often a lot better than what you can buy in bottles. This is especially true for Germany, Austria, and, according to Dragos, for Canada, too. The reason for the water quality here in ol' Europe is defined quality standards and ongoing tests. (2) In other countries, water companies are allowed to adhere to a lot less rigid standards. I was pretty surprised how awful water in the US midwest was. Full of chlorine and tasting dead. I still cannot believe, people drink it there every day (but they do, it's what Coke's made with there). So we do see differences here, some of which stem from the available water supplies in the area, and some of which are the effect of different defined standards and - inherently - jurisdiction. Countries are different, there is - legally spoken - no world-wide Internet. Everyone falls under the legislation of their home country (for various values of home...). And while we may not like it, this jurisdiction can be very different from mine. Or yours. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: SORBS Identity theft alert
Oh. [EMAIL PROTECTED] (Andrew D Kirch) wrote: See more about mailbombing. Mailbombers are spammers. They just aren't in it for the money. Or possibly they are. SORBS asks for donations to get delisted, and also seeks donations from Subscribers. It is very -- I believe this is a critical thing. There are a lot of sites getting listed through one way or the other (hey, denunciation is common!). Are you (is Matthew) planning to change this? Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: RIPE50: Peering BoF
Hi Cara, Since quite a few of you are also attending the RIPE meetings Susan though it would be a good idea for me to mention that a (European) Peering BoF will take place in Stockholm at RIPE50 on Sunday 1st May 2005 and from 18.00 to around 21.00. Unfortunately for me, this comes a little late. I'll join the mob on monday. Have fun discussing peerings and remember to announce earlier next time. Elmar.
Re: Disappointment at DENIC over Poor Rating in .net Procedure
[EMAIL PROTECTED] (Daniel Roesen) wrote: On Sat, Apr 02, 2005 at 01:48:51PM +0200, Elmar K. Bins wrote: The other: ICMP has been rate-limited. It might not be the way to test those locations. An mtr output would be more interesting :) mtr uses ICMP too. Yes, but it also shows where packets get lost... Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Disappointment at DENIC over Poor Rating in .net Procedure
[EMAIL PROTECTED] (Randy Bush) wrote: a.nic.de, 100 packets, 7% packet loss round-trip min/avg/max = 163.454/199.368/494.708 ms c.de.net, 100 packets, 2% packet loss round-trip min/avg/max = 15.071/46.131/724.957 ms z.nic.de, 100 packets, 3% packet loss round-trip min/avg/max = 180.9/222.723/578.468 ms s.de.net, 100 packets, 0% packet loss round-trip min/avg/max = 184.26/219.786/501.547 ms l.de.net, 100 packets, 1% packet loss round-trip min/avg/max = 170.435/211.573/568.7 ms f.nic.de, 100 packets, 5% packet loss round-trip min/avg/max = 171.717/206.826/489.947 ms Overall for DENIC: 3% loss and 15ms / 166ms / 725ms min/avg/max latency. c.de.net is the one I'd be using, and it gives 2% loss and 46ms latency. c.de.net is the one you WISH your resolver would use. sometimes it might, others it might not. Maybe Bill tunes his resolver. Nonetheless, two things come to mind: why the heck have you gotten such huge RTTs to z? I'd pretty much like to see your traceroute... The other: ICMP has been rate-limited. It might not be the way to test those locations. An mtr output would be more interesting :) Elmar.
Re: Disappointment at DENIC over Poor Rating in .net Procedure
[EMAIL PROTECTED] (Florian Weimer) wrote: As always: Never trust a statistic you have not faked yourself ... I doubt that DENIC will ever publish the technical part of its bid, so this isn't convincing. Like you already admitted on the DENIC list, this has of course been made public, since the largest parts of all proposals can be found on the ICANN web site. DENIC's proposal can be found here: http://www.icann.org/tlds/net-rfp/applications/denic.htm Elmar.
Re: Known communities for AS174?
[EMAIL PROTECTED] (David Hubbard) wrote: But I've tried setting each of those and it doesn't seem to have any effect. Anyone know if that info is out of date or maybe has something else to try? Are you sure you're sending communities? Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: The Cidr Report
[EMAIL PROTECTED] (Hank Nussbacher) wrote: Duh! No suprise there. ARIN just gives IP space and only offers some measly online training: http://www.arin.net/library/training/index.html RIPE on the other hand, has 3-6 course a month, throughout Europe: http://www.ripe.net/training/lir/index.html http://www.ripe.net/cgi-bin/courselist.pl.cgi You should read the course outline. RIPE teaches nothing whatsoever to do with routing. It's all registration stuff... But certainly, a routing course could be added, maybe to a somewhat more techy track like where the DNSSEC courses sit. Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Registrar and registry backend processes.
[EMAIL PROTECTED] (Lionel Elie Mamane) wrote: A nonprofit firm in Frankfurt, Denic eG, which manages Germany's eight million registered .de domain names, has also indicated that it is planning to bid. For what it is worth, some consider the .de whois server broken; see below. Let's note that the new RFC (3912) doesn't mention the help methodology anymore. And some call this not broken but necessary. I can explain off-list, if you like. The .DE whois server is broken. I should be able to telnet to the WHOIS server on the whois port, send it a domain, and get results. You are getting results. $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. denic.de domain: denic.de status: connect Connection closed by foreign host. Further, these options are not documented anywhere, because the usual help methodology, as documented by the RFC, doesn't work: http://www.denic.de/en/domains/technik/denic_whois-server/index.html (Easily found by searching for whois, first hit - yes, I know, it's ugly, but you're still not telling the truth which is my point here) $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. ? domain: ? status: invalid Which is defined in what RfC? If it is, I will gladly tell the folks to implement it. Anyway, I see your point in that server being somewhat problematic if you need more than free/used; yet the information is there, and someone who really needs more info has no hard time finding the docs. Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Registrar and registry backend processes.
[EMAIL PROTECTED] (Lionel Elie Mamane) wrote: $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. ? domain: ? status: invalid Which is defined in what RfC? RFC 954, which has recently (September 2004) been obsoleted by RFC 3912, which doesn't mention it anymore. Yes, one could have seen that. I'll take the issue to the people involved. Yours, Elmar. (Btw: HELP works...) -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Registrar and registry backend processes.
Hi William, And some call this not broken but necessary. I can explain off-list, if you like. Why off-list? Just tell that you want to support multi-lingual domain names. There are a couple more reasons, and I'm not sure it's NANOG business ;-) I believe he meant that URL should be presented as part of normal whois answer. While me and others who care have already found it long ago, you can't expect that of people who might do one denic lookup per year True. But if this lookup is so important, they are easily willing to try the website. Of course, it's not nice, giving no hint at all. I've told the folks here, maybe they'll insert a comment or something. But please don't take it that you should not implement it, if its no big deal (and for most its not), then please present text-only copy of documentation for most important options. And in general because most people do not even know about ?, please just present URL to documentation in all other queries. Be generous in what you accept... Yup :-) Yours, Elmar. PS: Btw, HELP works... -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: Association of Trustworthy Roots?
[EMAIL PROTECTED] (William Allen Simpson) wrote: While the Association of Trustworthy ISPs idea has some merit, we've not been too successful in self-organizing lately. ISP/C? I thought we already had built such a thing, currently covered by ICANN. But well...life changes everything, and for some (or many) or us, this association doesn't seem so trustworthy anymore. Maybe it would be better to improve trustworthiness of the existing authorities. I believe there is still much room for participation, not to mention political issues you simply cannot counter on a technical level. At the moment, I'm concerned whether we have trustworthy TLD operators. One can never know what's going on behind the scenes. Maybe Verysign is on the issue, maybe not. I believe, there are at least three VS people on this list who could address this. I don't know whether they are allowed to. It's been about 24 hours, it is well-known that the domain has been hijacked, we've heard directly from the domain owner and operator, but the TLD servers are still pointing to the hijacker. By chance - how is the press coverage of this incident? Has anybody read anything in the (online) papers? Unfortunately I haven't been able to follow the newsboards intensely this week-end, but Germany seems very quiet about this. Yours, Elmar.
Re: no whois info ?
[EMAIL PROTECTED] (Peter Corlett) wrote: william(at)elan.net [EMAIL PROTECTED] wrote: [...] Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) while whois data is still updated once or twice a day. That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! This tempts me to hack something into Exim that does a whois on previously-unseen sender domains, and give a deferral if the whois denies existence of the domain. Is this likely to have any meaningful effect? No. It depends too much on (a) the registry and registrar for the domain (b) overall whois availability to that TLD (not everybody uses whois) (c) your connectivity to the whois servers involved (possibly more than one) Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
LG close to MCI Japan anyone?
Hi there, I'm currently searching for a looking glass close to AS703 in Japan. Unfortunately, JPIX doesn't offer one (would have been to easy anyway). Any pointers? Yours, Elmar. PS: Whoever maintains traceroute.org and is on the list: Very many of the listed RS and LGs are offline and some have been for quite a while.
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
Hank :-) that, nor any way of modifying the list (correct me if I'm wrong). See pages 9, 10 and 12 of the PDF I posted. Specifically, it sets up: ip access-list extended autosec_iana_reserved_block, and ip access-list extended autosec_complete_bogon which you of course can change like any other ACL. Yup, read the last bits now, so at least that holds no more fear. Unfortunately one still has to mop all routers every time. Thanks for correcting that, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;)
[EMAIL PROTECTED] (Owen DeLong) wrote: Bundusch Germania Politzei Forgive my lack of German spelling/grammar, but, hopefully I came close. It's spelled Bundesgrenzschutz. AS3280 BGS (German Border Police) AS3281 BGS (German Border Police) AS3282 BGS (German Border Police) AS3283 BGS (German Border Police) AS3284 BGS (German Border Police) AS3285 BGS (German Border Police) Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: who gets a /32 [Re: IPV6 renumbering painless?]
[EMAIL PROTECTED] (Iljitsch van Beijnum) wrote: For instance, 212.x.y.z is known to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry? Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe. And if everyone gives transit to anyone. Ideal world. Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: who gets a /32 [Re: IPV6 renumbering painless?]
[EMAIL PROTECTED] (Jeroen Massar) wrote: The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. It depends all on what one wants, either one gets a lot of routes and thus what we currently have in IPv4 or it is done completely different, like that. That's the point of view of an Internet technician (ok, who's on this list, after all...). It is not the point of a user, a manager or a corporation. HIP is too complicated, it relies on too many parts. It will never be used widely, unless someone find a way to _entirely_ hide it from the end-user. I cannot see a way to do that, starting with the certificates and for a long time not ending with server and client implementations. It is nice in theory, it streamlines protocol interaction, adds security, makes you mobile, but it uses too many parts in complex interconnection. I consider it impractical on the large, although it may fit the bill for small, technically-oriented user groups. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: anycast roots
[EMAIL PROTECTED] (Stephane Bortzmeyer) wrote: It is not easy to find by itself (you have to do a lot of traceroutes) so, if you have access to this information, it would be quite useful. (I'm one of the persons who see a lot of jitter for j.root-servers.net with Randy Bush's experiment.) Well, either my probes don't pick up the jitter, or I'm guessing the naming convetion for j wrongly. I see jns1-hgtld.j.root-servers.net jns2-hgtld.j.root-servers.net jns3-hgtld.j.root-servers.net jns4-hgtld.j.root-servers.net jns5-hgtld.j.root-servers.net jns6-hgtld.j.root-servers.net (same from AS8495/AS8220 and AS8763) in alternating fashion, but I would assume jns1 through jns6 are just the individual servers of a setup called hgtld. Yours, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: anycast roots
[EMAIL PROTECTED] (Kurt Erik Lindqvist) wrote: On 2004-11-12, at 02.53, Randy Bush wrote: which roots are anycast? c f i j k? b m k (London, Amsterdam, Frankfurt) Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
