Re: Superfast internet may replace world wide web
Glen Kent wrote: says the solemn headline of Telegraph. http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/04/06/ninternet106.xml It is always good to see that journalists don't know that Networks are also used for other purposes than their daily dose of nonsense (also called the Internet or World Wide Web for the web-only portion etc) Also related to this one, here: Web could collapse as video demand soars http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/04/07/nweb107.xml .. and we in Nanog are still discussing IPv6! ;-) The CERN LHC (Large Hadron Collider) is a nice toy. They had an Open Day (http://lhc2008.web.cern.ch/LHC2008/index-E.html) yesterday, which was really impressive. No more Open Days in the tunnel are planned for the next couple of years, thus for everybody who missed it: http://gallery.unfix.org/2008/2008-04-06-cern-lhc/ Greets, Jeroen signature.asc Description: OpenPGP digital signature
Flow Based Routing/Switching (Was: Does TCP Need an Overhaul? (internetevolution, via slashdot))
Paul Vixie wrote: [..] i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* inexpensive. should somebody tell dr. roberts? Isn't the reason that NetFlow (or v10 which is the the IETF/Cisco named IPFIX) exists the side-effect of having routers doing flow based routing aka keeping an entry per IP flow, thus using that entry for every next packet to quickly select the outgoing interface instead of having to go through all the prefixes ? The flows are in those boxes, but only for stats purposes exported with NetFlow/IPFIX/sFlow/etc. Apparently it was not as fast as they liked it to be and there where other issues. Thus what exactly is new here in his boxes that has not been tried and failed before? Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 tunnel for ISP sought
Joel Snyder wrote: [..] Experimentation with SixXS.NET has proven to be problematic, How so? It is always fun to read that people have 'problems', but it is even funnier then when the person's name isn't even listed in whois.sixxs.net and thus doesn't even have an account, nor am I able to even find a single email from either opus1 or your name, thus I really wonder what things are 'problematic' for you. You might be interested to try this marvelous thing called the World Wide Web, and read http://www.sixxs.net/contact/ and when you have done that, use this great invention called email to contact us, if you still have questions about things, that is why that page is there, clearly people are scared by it and don't dare to ask... As you might guess, our IPv6 traffic load is estimated to be between zero and unmeasurably small, but we'd still like to have it hover above the absolute zero mark. Then again, if you are a real ISP, you will have to do what everybody else in the business is doing: - get a block from ARIN (or your favorite local RIR :) http://www.sixxs.net/tools/grh/dfp/arin/ doesn't list you, thus you might want to start out there - arrange transit - this generally means you are going to pay for bits just like in the IPv4 world. - fix your routers and the rest of your network Though SixXS is there to get people going in using IPv6, it definitely is not meant to support your full business process, if you require that, go pay somebody who can give you their full attention, there are lists in the FAQ with organizations who can do that for you for that purpose. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: 3rd party network monitoring
Jason LeBlanc wrote: My bad, you might be able to do it with PingPlotter using remote proxies that are linux. I can see using the Vixie personal colo list to find cheap vm offerings in various locations. Other option, a few could get together and share some resources to get the proxies distributed. Did you actually *check* the URL I passed in? TTM does quite a bit more and is already distributed around the world and available to ISP's. Again: There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Greets, jeroen signature.asc Description: OpenPGP digital signature
Re: 3rd party network monitoring
Jason LeBlanc wrote: I did look at it, it still lacks a few things, but it does cover most. It would be nice if you added some screenshots or demo pages as to what the reporting looks like. I had to dig around and find a paper on the slammer worm to see what the output looks like. Contact RIPE NCC for that, if you would have read it, you would have found that it is their project. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: 3rd party network monitoring
John A. Kilpatrick wrote: On Wed, 5 Mar 2008, Tom Sands wrote: When we did get a hold of someone, they mentioned they could support simple ICMP requests. To them simple means it's just a ping check. They won't montior/graph/care about latency. I was pondering creating a smoke ping collective. Get a bunch of guys to agree to run smokeping and monitor each other. That's a great tool for visualizing changes in latency and works just as well with ICMP as with HTTP. There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Enjoy ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: YouTube IP Hijacking
Arnd Vehling wrote: Randy Epstein wrote: My point was that even with a license, accidents still occur. My point is that without a license more accidents will occur. The problem here is a problem causes in a *REMOTE* network, that you, as a decent engineer, should safeguard against in *YOUR* network. That *other* networks don't have a clue, doesn't mean that you can't, at least partially, protect against them. Or to get to the car analogy: driving a Hummer H1 or for that matter a Volvo or any other decent SUV (or a tank :), protects you from all those maniacs (wiht and without license) on the road, as when they hit you you will only have a dent, their car will be totaled. In other words: secure your network and make it watch out for the idiots maniacs, with and without a license. See the other threads on tip and tricks on how to get this working, but you as a decent engineer should know that already and have some nice monitoring in place to avoid incidents like these... Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Secure BGP (Was: YouTube IP Hijacking)
[EMAIL PROTECTED] wrote: [..] Pushing this task off to a server that does not have packet-forwarding duties also allows for flexible interfaces to network management systems including the possibility of asking for human confirmation before announcing a new route. There is no (direct) requirement for most of these solutions to do it in the router that forwards actual packets, just add a special BGP box for this. This box then 'verifies' if the update looks OK. When the update looks fishy, it can either, depending on what you want either notify your favourite $nocmonkey to look at it and/or at least instruct the real routers to not use that path. You can take (S-)BGP(-S) for verification, but you can also use IRR data or whatever source you have for stating 'this prefix from there over this path is trusted', compare against that and voila, you got a report when the assumed vectors don't match and you can at least react to them. These kind of systems already exist, see previous emails, but clearly not too many actually make use of them, now that is too bad for your customers who couldn't see their lolcats or worse who couldn't reach their stock house for quickly selling their shares before that company went down the drain completely... Greets, Jeroen signature.asc Description: OpenPGP digital signature
ISP's who where affected by the misconfiguration: start using IRR and checking your BGP updates (Was: YouTube IP Hijacking)
First the operational portion: For all the affected network owners, please read and start using/implement one of the following excellent ideas: * Pretty Good BGP and the Internet Alert Registry http://www.nanog.org/mtg-0606/pdf/josh-karlin.pdf * PHAS: A Prefix Hijack Alert System http://irl.cs.ucla.edu/papers/originChange.pdf (A live/direct BGP-feed version of this would be neat) * Routing Registry checking, as per the above two rr.arin.net whois.ripe.net contains all the data you need Networks who are not in there are simply not important enough to exist on the internet as clearly those ops folks don't care about their network... Of course there is also (S-)BGP(-S), but that will apparently never happen, and actually, with the a system like PGBGP or PHAS one already covers quite a bit of the issue, until a real hijacker just uses the original ASN. IRR data helps there partially though as it tends to have upstream/downstream information, but it doesn't cover all cases. For the rest google(bgp monitor hijack) for a list of other things. Now for the sillynesss non-ops political blabla FUD Max Tulyev wrote: I think it was NOT a typo. This was a test, much more important test for this world than last american anti-satellite missile. And if they do it again with more mind, site will became down for a weeks at least... More of that, if big national telecom operator did it and have neighbors to filter them out - it can lead to global split of the network. Of course, it should be happened early or late with THIS design of the Network. Oh boy oh boy, I just have to comment on this :) Wow, somebody with an email address like yours, especially the president and the .su bit are amusing, is commenting on another country doing 'tests'!? You might actually try keeping your bombers closer to the shores instead of trying to play chicken with the USS Nimitz :) http://www.upi.com/NewsTrack/Top_News/2008/02/11/russian_bomber_buzzes_nimitz/5914/ In Soviet Russia the Internet hijacks you? Please folks, keep the posts operational :) /non-ops political blabla FUD Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: NetworkSolutions - Was: Re: v6 gluelessness
Bjørn Mork wrote: Randy Bush [EMAIL PROTECTED] writes: Network Solutions appears to have some level of support for RRs because I am aware of domain names registered through them that have RRs. it is pushing glue to the parent zone, com et alia, that is the problem. Why don't you just put your DNS servers in some other TLD and forget about the problems of adding glue records to .net/.com? The name of your DNS server can't really be that important. Oh yes it is, as it is another dependency and another two/three lookups. Lets say example.com uses ns.example.nz: query ., .com, example.com, .nz, example.nz, ns.example.nz (though maybe the latter is hinted as glue, though with DNSSEC that doesn't really help), www.example.com instead of: query ., .com, example.com, www.example.com Quite a bit quicker, and also less parts that can fail. Lets see, a) IPv6 glue, or b) no IPv6 AAA glue and having quicker resolution and less dependencies, let me think for a second, take a small guess what I take (b). Also, if you would look at http://www.sixxs.net/faq/dns/?faq=ipv6glue it is somewhat easy to find an alternative registrar which can do the glue for you. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: NetworkSolutions - Was: Re: v6 gluelessness
Randy Bush wrote: David Freedman wrote: Will somebody please, please PLEASE let me know what magic process for networksolutions are to get glue added, am on the 72nd hour of the phone game where questions are bouncing between: as far as i have been able to sort this o netsol understands glue o the registrar has to push it to the netsol registry And what if NetSol is your registrar that needs to add the glue!? Indeed, welcome to the 72 hour+++ phone loop with clueless folks who don't understand what you are talking about. Apparently, around 2003 somewhere there was clueful and when you mailed [EMAIL PROTECTED] they could add the relevant entries manually. Last couple of times I tried that though, the person who answered clearly didn't understand the concept of glue, let alone 's or what IPv6 or even IP remotely was... As the roots will have glue starting next month, but for .org it is apparently impossible to get it added though, I am not going to spend time to get through to them though. We can only pray that they finally start getting a clue somehow and add it to their webinterface so that we don't have to go through it manually. The real solution seems to be: swapping to Enom. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 gluelessness
Randy Bush wrote: for those of us who are trying to provide dual stack services, how the heck do we get v6 glue added to the gtlds? specifically, i want to add v6 glue for psg.com and rip.psg.com in the com zone. similarly for the root, as rip.psg.com serves some tlds. Depends on your registrar. As one of the few ones enom.com can add glue for at least .com and probably some others. And NetworkSolutions Joker.com don't even know what 'glue' means, they think that you want to use their managed DNS services and put 's in there. Then again NSI doesn't even get the part right that there are people who do not have a phonenumber starting with +1, let alone that some people don't have a fax, thus nicely pushing invalid information into whois. Some people claim that if you can get through the hoops of the phonesystem at NSI that they can manually add them though. I've added a little list here: http://www.sixxs.net/faq/dns/?faq=ipv6glue Updates and anecdotes of course are welcome :) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Cisco IP forwarding question
[EMAIL PROTECTED] wrote: I have a customer that's trying to do something I've never seen before, and I'm trying to help him set it up. They have a 2811 set up with a VPN using a GRE tunnel. We have that up and running to the other end ok. However, the customer wants to control which RFC 1918 10.x space he assigns to each external destination within a larger NAT'd VPN, mostly using 10.x space. The solution is simple: go to $RIR, justify the address space(1), and get it. No more silly kludges and all problems resolved. Greets, Jeroen 1 = be it IPv4 or IPv6 signature.asc Description: OpenPGP digital signature
Re: Network Operator Groups Outside the US
Rod Beck wrote: [..] 6. I am not aware of any Dutch per se ISP conferences although that market is certainly quite vibrant. See http://www.nlnog.net/ though conferences is not the case, then again there is RIPE + AMS-IX meetings, who needs more than that :) Also see http://www.swinog.org for the Swiss Network Operators Group, which I can really recommend for attending meetings as they are a lot of fun. (Hint: Generally the meeting is hold in the Altes TramDepot (http://www.altestramdepot.ch/) , which is a beer brewery and has a wide selection of beers ;) I am also disappointed to see the Canadians and Irish have next to nothing despite Ireland being the European base of operations for Google, Microsoft, Amazon, and Yahoo. Ireland has SAGE-IE (http://www.sysadmin.ie/) which fills in the niche quite well, together with ILUG (http://www.linux.ie/) for related subjects. I think they are quite well covered too :) Germany btw has CCC Congress + SummerCamp (http://events.ccc.de), thus they are also covered :) Though indeed not 100% ISP events, they are very much related and also a lot of fun. 8. Both DEC-IX and AMS-IX have member meetings each year. Not clear how difficult to get invited if you are not a member. If you are not a member at either of these your network has a problem :) (Oh and you are missing out on the great AMS-IX parties too!) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
Scott Weeks wrote: [..] I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it. Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already. In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
Leigh Porter wrote: Wow, is this what you folks do at Christmas ? Clearly you yourself are affectionate about this thing called Christmas, if you are so affectionate about it, then why are you making silly comments which do not contribute at all to the topic at hand? Must be very boring that Christmas of yours. On a more operational topic: even during Christmas (that Coca Cola induced commercialism party that gets attributed to some religion), people are using the Internet, and stuff breaks on the Internet, as such there will always be people who have to work on days like this. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
Joe Greco wrote: [..] Okay, here, let me make it reaaally simple. Yes, indeed lets make it reaaally simple for you: If your ISP has been delegated a /48 (admittedly unlikely, but possible) for $1,250/year, and they assign you a /56, their cost to provide that space is ~$5. They can have 256 such customers. Fortunately ISP's get their space per /32 and up based on how much they can justify, which is the amount of customers they have. As such for a /32 single /48 is only (x / 65k) = like 20 cents or so? And if you are running your business properly you will have more clients and the price will only go down and down and down. Really (or should I write reaaally to add force?) if you as an ISP are unable to pay the RIR fees for that little bit of address space, then you definitely have bigger problems as you won't be able to pay the other bills either. How high are your transitequipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical! As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel. For some magic reasons though(*), it seems to be completely ludacrist to do it this way, even though it would make the bill very clear and it would charge the right amount for the right things and not some arbitrary number for some other arbitrary things and then later complaining that people use too much bandwidth because they use bittorrent and other such things. For the cable folks: make upstream bandwidth more pricey per class than downstream, problem of heavy-uploaders solved as they get charged. Greets, Jeroen (* = then again I don't have an mba or something like that so I prolly miss out an all kinds of important factors why people have to make it so complex) signature.asc Description: OpenPGP digital signature
Re: /56 for home sites, /48 for business sites billing considerations (Was: European ISP enables IPv6 for all?)
Leo Vegoda wrote: On 19 Dec 2007, at 21:31, Jeroen Massar wrote: [...] When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for. They received the prefix because they had a plan. That's all, a plan. Not a promise. It is not a plan, it is justification. The 200-rule has been taken out of the allocation already. And based on the x customers times /48, they justified that they will need a /20 or something else. As such when they are going to give out /56's, they suddenly need 256 times as many customers and unless they are going to grow insanely (for a /32 from ~60k to 15m customers) they won't be able to justify their address space anymore. As such, keep it simple folks, just pass out /48's. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
Lou Katz wrote: I am having trouble understanding why I cannot get an allocation of any size, only an assignment. Unless I didn't read the documentation correctly, there seems to be no way in hell that I can get PI v6 space of any size, which of course leads me to be disinterested in v6. The nasty friday-evening answer: PEBKAC Indeed, when you don't state WHY you think you can't get one you indeed won't. Greets, Jeroen signature.asc Description: OpenPGP digital signature
/48 for each and every endsite (Was: European ISP enables IPv6 for all?)
Changing subject for these replies which will definitely be a bit on the quite mean side... no offense but start reading for once. Next to that there are also LIR courses which cover all of this. (see other mail for /56 for end-user-sites, /48 for end-business-sites) Mikael Abrahamsson wrote: [..] So, out of our /32, if we assign each customer a /48 we can only support 65k customers. Can I read from this that you never actually read any of the $RIR policy documentation about getting IPv6 address space even though you did request a /32 before, clearly without thinking about it? So in order to support millions of customers, we need a new allocation new as in We already have one, but we actually didn't really know what we where requesting, now we need more and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed). This explains quite a bit why people are looking so weird when certain other organizations get a /20 and upward from $RIR. My suggestion: start reading. Other option is to have more restrictive assignments to end users and therefore save on the /32, but that might be bad as well (long term). That would be stupid and totally against the idea of IPv6. Andy Davidson wrote: [..] From the RIPE perspective, there are seven empty /32s between my /32 and the next allocation. I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table. That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request... Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: European ISP enables IPv6 for all?
Kevin Oberman wrote: [..] Note that sixxs only deals with commercial providers. Many (most?) of the major research and education networks around the globe have done IPv6 in production for years. That includes ESnet, DREN, NREN and Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number of national networks in Asia. Which is a well know fact and who have quite a limited set of end-sites who can actually connect to them, that is why these are not listed. Similarly it doesn't list hosting providers either, enabling a colo to do IPv6 should be childs play, getting it to the enduser though... ;) That said, while we provide IPv6 services You provide services and access, but which places are actually enabled to use it? That the network is there is one thing, this is the easy part, linking up the end-sites is the hard one. Greets, Jeroen signature.asc Description: OpenPGP digital signature
/56 for home sites, /48 for business sites billing considerations (Was: European ISP enables IPv6 for all?)
Mohacsi Janos wrote: [..] In my opinion there is two type of users as usually ISP services are marketed: 1. Home user - not really interested in configuration of their devices - they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity: They generaly don't use more than one LAN internally. All their devices are connected either directly to ISP device or to the home-gateway purchased at the cornet. In this case the /64 with autoconfiguration is the best option. User don't have to configure anything (may be enabling IPv6 on their computers). This would force these places to: a) use bridging to get that single /64 onto their network thus making firewalling really difficult. b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses. ISP's are paying their transits by paying for the *BANDWIDTH* usage. So why don't ISP's have a couple of classes (to keep it simple) which are like eg: 10Gb account 50Gb account 100Gb account This would also solve the Those stupid users are torrenting problem, as they are PAYING for the traffic and other costs that you actually have. Don't charge for IP addresses, charge for *BANDWIDTH* usage. If I have 200 devices on the network which don't do a thing (maybe they are light bulbs or it is my fridge) I will do much less traffic than one single user who is trying to complete his nature movie collection. 2. Power users/business users - they can configure their devices, and they want measured and reported SLAs. If they want IPv6 they can articulate their needs: /64, /60, /56, or /48 with prioritisation, filtering and other business needs. In this case DHCPv6 prefix delegation seems to be the most flexible solution. Since they can configure basic things on their device. The ISP can help them and negotiate accordingly... Scratching the 'power users' concept, as they belong in the above home user part, I agree. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: /48 for each and every endsite (Was: European ISP enables IPv6 for all?)
Mikael Abrahamsson wrote: [..] The world tends to change in 7 years. You seem to like bashing people for not knowing future policy and changes 7 year ahead of time, which I think it quite sad. Not intended that way. What I was really surprised, and critical, of though is you mentioning that you say So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation, which I read as We got a /32 recently, but never thought that we should give /48's to endsites. Changes the interpretation quite a bit. But even in 2000 the policy was and still is: /128 for really a single device /64 if you know for sure that only one single subnet will ever be allocated. /48 for every other case (smart bet, should be used per default) As such, if you have near 60k customers then you should already have realized that you needed more than a /32, especially as you can then also guess that in a couple of years it will be quite a bit more. For the longer term, I guess 7 years might fall into that by now, thus if you got a /32 in 2000 and you had 10k customers then you should be fine. If you already had 200k customers or so and then only requested a /32 though I think one can definitely state you made a big booboo. Andy Davidson wrote: [..] With respect, Jeroen, because I did *PLAN* (your emphasis) our organisational requirements, this is precisely the reason why I think it's significant that a lot of space was left unallocated following my allocation. Correct, that is a good thing. My RIR only asked me to *PLAN* two years in advance (see ripe-414 [footnote 0]), though prudent organisations may plan for longer. I thought it was significant (and good) to note that they are allow me room to grow sometime after that period. Nothing wrong there indeed and you should indeed at least plan for two years and probably more, when adding HD ratio and some prospects one should easily come up with a pretty good ballpark figure of clients that you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while If you offer the sweeping statement that anyone who ever needs to go back to the RIR for more space has made a 'mistake' with their requirement planning shows you're only thinking in an incredibly short term manner. Unless, of course, you are only used to working in companies which do not grow. :-) As mentioned above, not the way I intended it to mean. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: /56 for home sites, /48 for business sites billing considerations (Was: European ISP enables IPv6 for all?)
Mohacsi Janos wrote: This would force these places to: a) use bridging to get that single /64 onto their network thus making firewalling really difficult. I am not quite sure. My colleague tested NetScreen box with /64 advertised from LNS. It seems to be working. If you are routing the /64, thus that it exists entirely on the clien-side, then it should work, but if you are allocating 1 single /64 to the customer, and eg keeping ::1 as the ISP side, then you have to do weird magic to make that work. b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses. They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block That is IPv4 and seems to be the case in general for IPv4. That mentality needs to be stopped for IPv6. When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: /48 for each and every endsite (Was: European ISP enables IPv6 for all?)
Christopher Morrow wrote: On Dec 19, 2007 5:03 AM, Mikael Abrahamsson [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2007, Jeroen Massar wrote: new as in We already have one, but we actually didn't really know what we where requesting, now we need more We got our current block in 2000 (or earlier, I don't know for sure, but 2000 at the latest). So yes, we didn't know what we were doing back then. Then again, I'd say nobody knew back then. I'd say it's fair to bet that quite a few folks in all regions pursued ipv6 allocations more than 3-5 years ago when the policy was essentially '/32 per provider, simply show a business plan for providing services to 200+ customers in the next N years' (without much in the way of planning or proof-of-planning). HD ratio and all related documentations have existed for quite some time already. If they would have read the docs they would have understood what it meant and also gotten the reason why they asked for the 200+ rule in the first place. [..] Some large providers are attempting to plan 5-10 years out for address policy if possible, not everyone has that luxury, but in the end we (internet routing community) want limited prefixes/org that means planning horizons have to be adjusted up from 2yrs to something else. I can fully agree with this and it is definitely something that one might want to push into the RIRs. I actually hope that most ISP's do realize that they might become a bit larger in a few years, fortunately there is the 7 adjacent /32's that can be used for sizing up quite a bit. The only thing then is to hope that only the aggregate ends up in BGP. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: European ISP enables IPv6 for all?
Vassili Tchersky wrote: [..] XS4All (Netherlands) is providing the same service if I correctly remember. They used to have a product called PowerDSL, which did IPv6 over PPPv6, but apparently due to changes in the infra they had to drop this. XS4all does still, since about 2001 or so, provide a tunnelbroker to their own users. Every user can simply go to the service.xs4all.nl site, and view/modify their tunnel + subnet configuration there. Only static tunnels are supported though (at least this is afaik). Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: European ISP enables IPv6 for all?
Steven Haigh wrote: On Tue, Dec 18, 2007 at 10:09:16AM +0100, Jeroen Massar wrote: Vassili Tchersky wrote: [..] XS4All (Netherlands) is providing the same service if I correctly remember. They used to have a product called PowerDSL, which did IPv6 over PPPv6, but apparently due to changes in the infra they had to drop this. XS4all does still, since about 2001 or so, provide a tunnelbroker to their own users. Every user can simply go to the service.xs4all.nl site, and view/modify their tunnel + subnet configuration there. Only static tunnels are supported though (at least this is afaik). It's kind of interesting that from 2001ish to current day and there is still only a handful of service providers worldwide that seem to offer *any* kind of support for IPv6. After all the propaganda, is there actually any other major deployments in the IPv6 space? I wonder how your Martian hands look like, they must have many many fingers. For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native For a long long list of Japanese providers see: http://www.ipv6style.jp/en/statistics/services/index.shtml As for all the ISP's who have received and are at least routing, check GRH (http://www.sixxs.net/tools/grh/) From the ipv6.org web site, I see Most of today's internet uses IPv4, which is now nearly twenty years old. - read as it works well! That site is IMHO always quite out of date unfortunately. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: European ISP enables IPv6 for all?
Florian Weimer wrote: * Jeroen Massar: For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native Does PPPv6 still work on the T-DSL platform? 8-/ From what I understand it depends on the router/dslam/whateverthingy one gets connected to. Some do, some don't is what I gathered. The list would be more convincing if it contained links to product pages. Unfortunately not available for all of them. If folks have references/updates/addons etc of course don't hesitate to submit them, I'll be more than happy to list them. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Verizon has been listening to nanog.
Edward A. Trdina III wrote: I wonder if they will permit BGP announcements from the business grade FIOS service? Does anyone know? man tun|tinc|openvpn|*swan|ipsec|... If they don't allow it and you can live with a few bytes of overhead per packet, nothing (except hard firewalling and doing weird things, thus effectively not providing Internet connectivity) can stop them. Greets, Jeroen signature.asc Description: OpenPGP digital signature
NNTP vs P2P (Re: Can P2P applications learn to play fair on networks?)
Adrian Chadd wrote: [..] Here's the real question. If an open source protocol for p2p content routing and distribution appeared? It is called NNTP, it exists and is heavily used for doing exactly where most people use P2P for: Warezing around without legal problems. NNTP is of course nice to the network as people generally only download, not upload. I don't see the point though, traffic is traffic, somewhere somebody pays for that traffic, from an ISP point of view there is thus no difference between p2p and NNTP. NNTP has quite some overhead (as it is 7bits in general afterall and people need to then encode those 4Gb DVDs ;), but clearly ISPs exist solely for the purpose of providing access to content on NNTP and they are ready to invest lots of money in infrastructure and especially also storage space. I did notice in a recent newsarticle (hardcopy 20min.ch) that the RIAA has finally found NNTP though and are suing Usenet.com though... I wonder what they will do with all those ISPs who are simply selling NNTP access, who still are claiming that they don't know what they are actually requiring those big caches (NNTP servers) for and that they don't know that there is this alt.bin.dvd-r.* stuff on it :) Going to be fun times I guess... Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Information Wiki
[added bcc to [EMAIL PROTECTED] so that they can have a look at it too from their end etc etc] Robert E. Seastrom wrote: [EMAIL PROTECTED] writes: ARIN has set up a wiki at http://www.getipv6.info to publish information that will help ISPs, large and small in implementing IPv6 and migrating to an IPv6 Internet. The unintentionally funny part of this is that the wiki hangs (the redirect to http://www.getipv6.info/index.php/Main_Page from http://www.getipv6.info works, but the subsequent page load does not) if you try to connect to it using IPv6. Is this a subtle way of saying that I am not the intended audience? Welcome to the wonderful world of MTU issues ;) $ tracepath6 www.getipv6.info 1?: [LOCALHOST] pmtu 1500 1: ge-1-3-0.breda.ipv6.concepts-ict.net asymm 2 1.320ms 2: 2001:838:0:10::1 asymm 3 3.404ms 3: ge6-2-0.br0.ams3.nl.gbxs.net asymm 5 4.666ms 4: so-0-0-0.bb1.bru2.be.gbxs.netasymm 5 8.504ms 5: ge-0-3-0.bb1.bru1.be.gbxs.netasymm 6 8.662ms 6: ge-6-0-0-32.bb1.bru2.be.gbxs.net asymm 8 15.684ms 7: 2001:7f8:4::cb9:1asymm 9 15.809ms 8: so-1-0-0.dus11.ip6.tiscali.net17.379ms 9: so-0-0-0.ham10.ip6.tiscali.net23.015ms 10: so-0-0-0.ham10.ip6.tiscali.net asymm 9 22.305ms pmtu 1480 10: sl-bb1v6-bru-t-7.sprintv6.netasymm 9 38.707ms 11: sl-bb1v6-rly-t-1001.sprintv6.net asymm 10 148.863ms 12: 2001:440:1239:7000::2asymm 11 155.694ms 13: no reply 14: no reply 15: no reply Something is nicely filtering out ICMP there and clearly some hop is not 1480 ;) The fun really starts when you have a 1280 pMTU though. Unfortunately ARIN doesn't have any traceroute6/tracepath6 tool available online so that one can check the path back, which could show where it goes wrong, as asymetric routes tend to be a big issue also ;) I won't even show the other traceroute which has a 400ms+ path and bounces from between nl - uk - us - jp - kr - us - arin and then goes dead. IMHO ARIN should also definitely look at getting a good transit provider, which would also help quite a bit with these kind of problems. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: ipv6/v4 naming nomenclature [Was: Apple Air...]
Barrett Lyon wrote: On Sep 18, 2007, at 1:30 PM, David Conrad wrote: [..] On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote: Please please please, for the sake of a semi-'standard', please only use [..] What RFC (or other standards publication) is this documented in? Where did the www.ipv6 and www.ipv4 standard come from? Note my clear use of semi and 'standard' and mind the quotes. Also note that for instance an IETF standard is only a standard when something in very common use for quite some time. Maybe this would be a good one to jot down as an Informational/BCP kind of document. It is something which is in use by a lot of sites who have been enabled with IPv6 for about the last 10 years and needed a way to distinct IPv4 and IPv6 variants of their hosts. Remember, before that people on NANOG started noticing the existence of IPv6 in the last few months, and before we had the 6bone with 3ffe::/16 there was also a 6bone with 5f00::/8 (RFC1897, which I really had to look up as my bear is not that long ;), oddly enough that is even before most people even had internet or knew that it existed. As for end-users such as normal non-network people, having a standard that adds more characters than necessary (that eventually may become arbitrary) seems rather silly. It is not meant to be used by end-users. Those should simply Google/Yahoo/Baidu for the description of the site and get the content and not be bother with remembering hostnames, let them use bookmarks or something, then they at least won't be caught by typo-squatters who are dominating the DNS system. It is only a semi-'standard' which is in use by network operators who didn't want to remember the or A for a hostname while being able to choose a protocol to ping/telnet/ssh/etc as there was a time when we already had IPv6 but some tools (yes, including PuTTY ;) did not allow selection of either IPv4 or IPv6 protocols. But also allowing the hosts to have an + A so that a tool could pick the protocol that was available. Sometimes you want to select that thus using: hostname.example.com A + hostname.ipv6.example.com A hostname.ipv4.example.com A solved that problem without having to add support for a '-6' or '-4' switch for IPv6 and IPv4 respectively into all tools that one uses. Some code doesn't come with source and some people don't want to patch it up so this is a perfect way to solve it. As mentioned above, this is for people who want to pick the version of IP protocol used. End-users don't even know what IP is, and they also should not know and they definitely should not have to care. As such, when you think that your site is 'working fine' over IPv4, then add an A record to it, when you think that IPv6 is fine, add an record, otherwise, have a trick like http://www.braintrust.co.nz/ipv6wwwtest/ and test if your users can reach the IPv6 variant or not. Most likely they won't have IPv6 enabled yet, if they have then great :) Why wouldn't w4.domain or w6.domain suffice for this purpose rather than making it overly scientific? It would suffice, it just is not what is in use. Also some people like to actually name OTHER things than their 'www' with it. The trend for that seems to be more that you can ignore the 'www' portion anyway and just http://youtube.com or http://google.com work. Also, I know a certain company using 'w3' for intranet-only websites, while using 'www' for internet websites. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Apple Airport Extreme IPv6 problems?
Barrett Lyon wrote: [..] I would actually think Apple (and any other vendor that default enable v6 tunnels without notifying the user) should react to this and provide a fix that allows their current user base to opt-in to their pre-existing tunnels with education on what that means to the user. It's great to be progressive, but it's not good to do it when it can impact users. IMHO what Apple (bcc'd :) should provide is a 'connectivity test'. Thus when they enable 6to4 per default, they should test that they can at least reach the 6to4 anycast node which is going to relay their packets and they should test a remote node (eg connectivity-test.apple.com) if they can reach that. Which is sort of what Vista tries to do to and several other connection managers which show visually how/if there is Internet connectivity. XP for instance also whines when you don't have good connectivity to the Internet based on some tests. If the connectivity looks broken, then either disable the tunnel or at least notify the user that experience might be diminished. Regarding segmented v4/v6 DNS, this may already exist, but it may also be a good idea for the web masters out there to create a v6 logo or marking denoting that a user has reached a v6 page vs. a v4 page. This could also be more helpful and also allow users to choose which protocol is used to reach the site. It also creates a reason to have both an overlapping /A www. and a special www.v6./w6. and www.v4. alias. Please please please, for the sake of a semi-'standard', please only use the following forms in those cases: www.domain www.ipv6.domain www.ipv4.domain Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an and A and one of them doesn't work. You can of course add them, it is your DNS, but with the above people might actually try them. If that framework accompanied the overlapping DNS, then HREFs could shuffle users from one version of the site pending on the user preference. On a totally unrelated note: Not to make any accusation on the security of the end-point tunnel network what-so-ever, but an entirely other issue is the tiny bit of a security conundrum that default tunnels create -- tunneling traffic to another network without notifying the user seems dangerous. If I were a tinfoil-hat security person (or a CSO of a bank for example) this would really freak me out. Just if an enduser controls the path over which his traffic goes now anyway? The answer to that is crypted VPN's and nothing else. And of course for instance MS allows you to turn off those features using Active Directory management. Maybe Mac's also have such a button somewhere? Next to of course the use of a firewall which explains you what connections are being made and which packets are being sent. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Providers providing native IPv6
Hi, As some of you might know we maintain a list of ISP's that provide IPv6 connectivity to endusers, thus over Cable/DSL/PPP etc. This list is at: http://www.sixxs.net/faq/connectivity/?faq=native If you have any additions/changes for that, don't hesitate to spam the details to me offlist so that they can be updated. Product URL's are of course very welcome also for that purpose. There is another page listing Transit suppliers who can do native IPv6 for you: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit For tunnel providers, there is a 3rd list at: http://www.sixxs.net/tools/aiccu/brokers/ As a Q to the list, as we also have the data for GRH available, thus effectively every ISP that would be able to provide IPv6, would it maybe be better to add a link to the 'product' pages from there and tag prefixes where endusers can get it and how? Greets, Jeroen (As for the Q why we (SixXS) maintain a list of native and other IPv6 providers which would mean we would loose customers: when there is native IPv6 from ISP's then we can shut that part of the project down and go do other fun things ;) signature.asc Description: OpenPGP digital signature
Re: Apple Airport Extreme IPv6 problems?
[EMAIL PROTECTED] wrote: On Mon, 17 Sep 2007 17:15:38 EDT, John Curran said: In addition, if the record is added for the node, instead of service as recommended, all the services of the node should be IPv6- enabled prior to adding the resource record. Not a problem for names which are single services (www.foo.com), but caution is required when the name has multiple services running. My favorite shoot-self-in-foot on that topic - I stuck a quad-A in for a host that *was* IPv6-enabled on the production service, but it didn't have (at the time) an IPv6-ready ssh daemon. Hilarity ensued when using an IPv6-enabled ssh client - you'd get back an RST packet real fast and it was Game Over. So remember - there's probably more services you need to worry about. ;) Indeed, which is why a good policy to have for 'servers' is to have: - a hostname, generally I bind these to the EUI-64 address - a servicename, eg 'www' or 'imap', which are bound to ::80 and ::993 Then when the box dies or you want to move the service to another box, you just move the alias, or actually just kill the quagga on the box and let another instance handle it ;) Still the maintainance of the box can be done by directly accessing it. Of course one should simply have that all integrated into the service deployment system and not care about the boxes themselves, you just want n of them to provide service X and m of them to handle service Z, or to use as many of them so that service Y is running topnotch with capacity to spare. All depends on your size of course ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
How do applications handle IPv6 and IPv4 dual-stacked (Was: Apple Airport Extreme IPv6 problems?)
[as this has nothing to do with Apple Airports in particular I changed the subject again] Martin Hannigan wrote: Should be an operation defined by gethostbyname() no? and in another: Pretty good as in there is a browser standard to poke for v6 then v4 or is this a stack behavior? No, it is done by getaddrinfo() and the resolver layers of the OS, please read the somewhat longer mail from with the subject of Going dual-stack, how do apps behave and what to do as an operator, yes it is long, but it explains more or less how it works and answers these questions. Andy Davidson wrote: On 16 Sep 2007, at 07:39, Martin Hannigan wrote: On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: Browsers are pretty good at falling back on a different address in general / IPv4 in particular when the initial try doesn't work, Pretty good as in there is a browser standard to poke for v6 then v4 or is this a stack behavior? Since this conversation has already talked about behaviour when encountering vs A, I am worried that a browser running on a dual-stack laptop might cache the returned when it has some v6 connectivity, and then refuse to look again for the A when I pick it up and take it somewhere with only v4 connectivity. getaddrinfo() asks first for , then for A, then sorts the records and then returns them to the application. Thus no such problem there unless some OS implements this in the wrong way, but afaik that is not the case. Now indeed when you are swapping locations and thus change IP addresses (eg loose the IPv6 connection, gain IPv4, or change from one IPv4 address to the other or one IPv6 address to another), indeed TCP sessions will die, but that is a problem with mobility. We see the browser cache bite us regularly with regard to the way they dip into the cache for long-stale records today. The support burden will increase if there are stack transitionary woes as well. Browsers should (and afaik don't) care about the IP protocol they got a resource from, they cache based on URI http://www.example.com/bla.png; and do not note the IP protocol it was from. Note that there are a couple of browsers though which have their own internal IPv6 off switches, eg firefox has network.dns.disableIPv6 which can be turned off by the user, Safari had/has IPv6 turned off per default and so was Opera. This as they perceived IPv6 to have problems and thus if there is IPv4 they always first use IPv4 and then IPv6, ignoring the ordering done by getaddrinfo(). Greets, Jeroen signature.asc Description: OpenPGP digital signature
Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
[spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Somewhat long, hopefully useful content follows... Barrett Lyon wrote: [..] The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth. The IETF recommendation is that IPv6 is tried before IPv4, BUT there is RFC3484 (http://www.ietf.org/rfc/rfc3484.txt) which gives an extra edge to this. In general it comes down that the resolver will, assuming there is both an IPv4 and IPv6 address (A + ) on the dns label requested try, as a source address: - IPv6 native (anything not 2002::/16 + 2003::/32) - IPv4 native - IPv6 6to4 (2002::/16) - IPv6 Teredo (2003::/32 Of course when there is only a A or only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it connects correctly. The above table is re-programmable per host and there are discussions/drafts to automate that for a complete network. The correct way to use getaddrinfo() is described in: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html by Eva Casto and of course the almost 10 year old document by Jun-ichiro itojun Itoh at: http://www.kame.net/newsletter/19980604/ Now the really BIG problem there is though is that when network connectivity is broken. TCP connect will be sent, but no response comes back or MTU is broken, then the session first has to time out. Thus if a user has IPv6 and the server has it also but the connectivity between them is b0rked then it will take quite some time to recover properly from this. Apps could of course do a multi-connect and try all in parallel but I am pretty sure that servers are not waiting for that and for instance the Firefox programmers don't even know what threading is, seeing that they can't even separate their UI from the network and rendering code, thus don't wait for them to do it for that. Also there is this nasty concept of deployed base and getting people to upgrade is of course far from easy, fortunately those types won't do IPv6 either hopefully ;) 6to4 and Teredo are a big problem here, especially from an operator viewpoint. This as an operator has absolutely no control over the flow of packets from/to his/her network. When the packets flow back it might just be that, due to BGP in the remote network, something attracts the 6to4 packets destined back for 6to4 and they mysteriously disappear or get routed around the world. The same for the way from the user on your network to the 6to4 relay at 192.88.99.1 (if you, like me, can't remember the address just type host -t any 6to4.ipv6.microsoft.com ;) This one can also be situated anywhere on this planet and BGP might pull it somewhere where you don't want it to go. As such, if you, as an ACCESS operator want to have full control over where your users IPv6 traffic goes to you might want to do a couple of things to get it at least a bit in your control: - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 - setup a Teredo Server + Relay and make available the server information to your users and inform them of it. - and/or the better option IMHO, to keep it in control: setup a tunnel broker and provide your users access to that. For instance Hexago sells appliances for this purpose but you can also ask SixXS to manage one for your customers. For CONTENT operators, get yourself a nice chunk of RIR space from your RIR. Then what you might want to do is setup the following little test: http://www.braintrust.co.nz/ipv6wwwtest/ and/or mods of it, put it on your important content sites. This will allow you to discover if your clients are using IPv6 and if they are able to reach it. Then if you are confident that you are up to it and that your clients are fine, you might want to consider adding 's to your site and go fully dual stack. If you have somewhat tech savvy users you can of course also ask them to test it for you. Check out our Cool new toy: we got IPv6! or something and ask them how it works. As for the above spammed toys URL, I have to note that especially AXIS folks are really cool, you send them a mail asking what products support IPv6 and the next day you get back very nice PDF's containing their overviews of everything that supports IPv6, they have lots of it, nearly all their products do. The best thing of course is that the sales reps actually KNOW what IPv6 is, wow, I like those AXIS folks! :) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [funsec] The Great IPv6 experiment (fwd)
Stephen Sprunk wrote: [..] P.S. I'm writing this from behind a monopoly ISP who deliberately blocks all proto 41 traffic, and thus 6to4, so I have no idea what content, if any, the Experiment is actually providing... Anyone want to give me a Teredo relay for research purposes? :) As the site (http://www.ipv6porn.com) states: 8-- If you're here for the free content, it's not here! We're not ready for the world to know about this experiment yet, so don't go submitting this to Slashdot or Digg until the actual site is up. --8 And also: 8-- When will all this start? We anticipate beginning this experiment in the May-June timeframe. --8 But it is September and not there yet, at least I didn't see the page updated nor any extra traffic. It would be great if this one: http://www.sixxs.net/misc/traffic/ would shoot over the 100mbit for prolonged periods of time. and that the one at AMS-IX: http://www.ams-ix.net/technical/stats/sflow_stats.html actually had a 1.0% or so share of IPv6 traffic As for your proto-41 problem, just go to http://www.sixxs.net and (ab)use AICCU which supports AYIYA, which is a dynamic-IP able protocol sending it's packets over UDP. I hope to be releasing the DNS aware version somewhere in October and then there will be really no more blocking possible even in freaky hotels ;) There are a few PoPs in the US already, though mostly on the east coast, if anyone can sponsor up a PoP in the west coast or for that matter actually any other region, that would be great in helping getting IPv6 deployment further. The bigger experiment is actually proving to yourself that your infrastructure is IPv6 capable and that you have the possibility to provide IPv6 to your own customers who might want it. Ping me directly for more info or just check the site. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: ICANN registrar supporting v6 glue?
Stephen Wilcox wrote: On Sat, Jun 30, 2007 at 11:16:40PM +1000, Mark Andrews wrote: [..] You don't change the hints you just provide zones that override B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your own ROOT-SERVERS.NET zone with the s added in. I've read your email twice and I dont follow. Either you are telling me You want option c: c) Serve your own version of root-servers.net containing 's This never occurred to me but it indeed is the best way to do it. All the root-servers have names in root-servers.net, as such just make your own master zone containing: B.ROOT-SERVERS.NET. 3600IN A 192.228.79.201 B.ROOT-SERVERS.NET. 3600IN 2001:478:65::53 F.ROOT-SERVERS.NET. 3600IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600IN 2001:500::1035 H.ROOT-SERVERS.NET. 3600IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600IN 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 3600IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600IN 2001:7fd::1 M.ROOT-SERVERS.NET. 3600IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600IN 2001:dc3::35 + optionally the other roots-servers as found on www.root-servers.org And presto. You don't even have to turn of glue fetch etc, as the above zone will override the glue then anyway. Good one Mark, thanks. Greets, Jeroen signature.asc Description: OpenPGP digital signature
IPv6 filterers watch out: eBay gets 2001:0:500::/41
Hi, As the below is of course a 'good to see they are going at IPv6' thing this one is of course nice. But there is an additional point in it which might cause folks to check up on their filtering: it's a /41. Just to make clear again, ARIN IPv6 PI allocs can be of size /40 - /48. So better check your filters if this can get through when they get around doing so ;) My suggestion: use the relaxed filters (2000::/3 = /16 - /48). When crunch-time comes that there are 1m routes, you can always filter more specifically, but as we are still 1000 routes, give yourself and your routers some slack... Enjoy the weekend (we have sun in Dublin *wow*, jump in garden :) ! Greets, Jeroen -- 8--- OrgName:eBay, Inc OrgID: EBAY Address:2145 Hamilton Ave City: San Jose StateProv: CA PostalCode: 95008 Country:US NetRange: 2620::0500::::: - 2620::057F::::: CIDR: 2620::0500:::::/41 OriginAS: AS11643 NetName:EBAY-6-0 NetHandle: NET6-2620-500-1 Parent: NET6-2620-1 NetType:Direct Assignment NameServer: SJC-DNS1.EBAYDNS.COM NameServer: SJC-DNS2.EBAYDNS.COM NameServer: SMF-DNS1.EBAYDNS.COM NameServer: SMF-DNS2.EBAYDNS.COM Comment: RegDate:2007-06-08 Updated:2007-06-08 ---8 signature.asc Description: OpenPGP digital signature
eBay == 2620:0:500::/41, oops (Was: IPv6 filterers watch out: eBay gets 2001:0:500::/41)
Eric Vyncke wrote: Beware the subject line is wrong, it assumes that eBay is using Teredo ;-) (you scared me for a while!) Oops, indeed, some other people also noted this already. And it is good to see that people read subject lines, as due to recent nanog-banter I would almost have believed that nobody did. Of course it should not really matter which exact prefix they got, as long as folks keep their filters up to date. Greets, Jeroen (who blames the sunlight in his screen in the early morning :) signature.asc Description: OpenPGP digital signature
Re: Network Level Content Blocking (UK)
Joe Abley wrote: [..] Anyway, how does BT's cleanfeed work? How are British 3G operators doing equivalent blocking? I'd be interested in learning about the implementation. I wonder how this solves the, from what I found out, common situation that people rent cheap root servers in a country like Germany where they VPN into and thus have full access to everything. Or for that matter any form of VPN or other remote access. The only thing that this 'content blocking' solves is that popsmoms who don't have any clue about the Internet at all will be deprived from some freedom, that the government can look into everything claiming that everything on the Internet is p0rn (which is not so far from the truth according to some :). All the folks who really want to access icky pictures will do so any way by using something very simple called HTTPS or any other form of encrypted access and work arounds like VPN's, Tor, Open proxies and the myriad of other ways that are possible. Takes a little bit of effort, but hey, does it matter, you at least get to get your daily feed of icky stuff and you can say to the government oh I thought it was okay as it was not blocked by your filter. Btw, the 90% quote given is of course a marvelous thing when you have a single organization which has almost a monopoly ;) I wonder which companies are going to provide the 'solutions' to this problem and how well they sponsored various people of the government. Long live VPN's! Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Researchers Chart Internet's 'Black Holes'
Hank Nussbacher wrote: http://www.wired.com/science/discoveries/news/2007/06/hubble Despite its robust appearance, more than 10 percent of the internet flickers out like a candle every day, according to researchers who unveiled on Wednesday an experimental tool that probes the network's dark places. [..] I couldn't make it up from the slides or the terse text, but I am wondering how much information you can really deduce from BGP, yes it says they don't have that prefix, but for the rest, even if an ISP has a prefix it doesn't mean that any packet can flow from A to B. Doing traceroutes from a remote site doesn't help as that is just C to A or B. Better Internet Hubble Telescopes are therefor: RIPE TTM: http://www.ripe.net/test-traffic/ RIPE RIS: http://www.ripe.net/ris/ TTM is deployed globally around the world and does traceroutes/pings/bgp monitoring and a lot more to see where problems are, you can get a peek at what it can show you at: http://www.switch.ch/network/ttm/ courtesy of SWITCH in Switzerland. If you want an IPv6 Hubble you can check up GRH which has provided that kind of information for quite some time already. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Providers that carry IPv6
Krichbaum, Eric wrote: I saw this question a while ago but no (maybe one) answers. Who does have IPv6 in production today. Of the fixedorbit.com top ten for example? http://www.sixxs.net/tools/grh/lg/ You can check the routing tables for which ASN's are active or check the DFP list to see if they have an, active, allocation. Of course yelling at them that you want connectivity by calling their head sales guy up is also a great thing. There are a number of great transits who can provide you IPv6 transit, Tiscali,Easynet,NTT/Verio come to mind amongst others (still early here I might miss some good ones out). Check the above URL for more of them. Personally, I would give any participant in GRH a 'they are cool', for the mere fact that they allow their routes to be published and thus give an open view and clarity into their network. Is there anyone out that would supply an ISP with a tunnel to v6 routes? Please at least honor: ip6.de.easynet.net/ipv6-minimum-peering.txt Don't go tunneling around the world as some people still do :( Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Providers that carry IPv6
Antonio Querubin wrote: On Mon, 4 Jun 2007, Jeroen Massar wrote: Please at least honor: ip6.de.easynet.net/ipv6-minimum-peering.txt A typical trans-Pacific path is significantly longer than a typical trans-Atlantic path. The 40 ms policy recommendation in the above is unrealistically small for those of us out here in the Pacific Ocean where it takes roughly 50 ms just to reach only halfway across the ocean. It also favors a system of short IPv6 paths through multiple tunnels that add significant latency which is somewhat self-defeating. Ideally you want an IPv6 path between point A and point B to be reasonably close in latency to the IPv4 path. That is indeed the intention of that document, therefor that 40ms policy can be mostly ignored for that type of links. In the absence of ubiquitous, diverse, native IPv6 peering between Tier 1 providers, which I suspect will still take a while to develop, currently the only realistic way of keeping the latency delta minimized between an IPv4 path and an IPv6 path is to have your own diverse set of tunnels, even if it means tunnels that go halfway around the world. I don't see a real reason why one needs to tunnel around the world. Unless you are indeed in a very remote location where no transit provider is providing IPv6 yet. If that is still the case though I definitely would suggest that you start kicking your current IPv4 transits *VERY* hard in several naughty places to get them going and start providing it. At the very least they can do a tunnel over their own infrastructure and terminate you at their ends. The alternative is IPv6 connectivity that really stinks because packets have to bounce through multiple tunnels unnecessarilly. Try to avoid that at all cost of course. But if that is the only way, then for the time being that is then the only solution. Of course document it properly and kick upstreams to fix it. Greets, Jeroen signature.asc Description: OpenPGP digital signature
RFC4864 - Local Network Protection for IPv6
For all you NAT is soo secure I need to NAT folks please take the time and read the following RFC that the IETF has carefully put together to address all those arguments. URL: http://myietf.unfix.org/documents/rfc4864.txt Abstract: 8 Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of amplifying available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. 8 Now, if you have a problem with that document and the way it solves your problems, please raise them in the v6ops WG of the IETF so that they know about them and can address your concerns. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Training?
Petri Helenius wrote: [EMAIL PROTECTED] wrote: Alex Rubenstein writes: Does anyone know of any good IPv6 training resources (classroom, or self-guided)? If your router vendor supports IPv6 (surprisingly, many do!): Too bad the IPv6 support on the low-end Ciscos is mostly broken in many ways (does not work on WLAN, does not work across the local 4 port switch, etc.) , which are also the routers most classrooms could afford. The magic answer to training setups: one big fat Xen box with a lot of VM's, virtual interfaces and of course: Quagga. It looks like a Cisco, it feels like a Cisco, it is almost a Cisco. At least the interface is more or less the same. And that is what people need to learn, the basics of configuration. If there is a little variation in commands they should be able to cope to that. If they only know how to type it into a Cisco then they didn't really learn about it. Yes it is different, no it is not as cool, but it makes it very cheap to learn people these things. That said of course, who still types directly into their routers? I do hope that folks use one of the nice (custom) router/device management tools out there which avoids all of that. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Training?
Adrian Chadd wrote: On Sun, Jun 03, 2007, Jeroen Massar wrote: The magic answer to training setups: one big fat Xen box with a lot of VM's, virtual interfaces and of course: Quagga. It looks like a Cisco, it feels like a Cisco, it is almost a Cisco. ..r http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator Which is a great thing, but license-way quite useless, as it still means that you will have to have an official license for each IOS you run, and as IOS comes with a box, you would either be able to run your real 7200, or the simulated one. Or does anyone know where you can get IOS-only licenses so that you can run it on simulators? Same goes for the Vendor J simulation/training thing that doesn't exist. When you are on the cheap and do not want to break any laws / want-vendor-x- to-ignore-you-for-the-rest-of-your-life then you better play it on the safe side and get proper licensing. At a certain point you will be more than comfortable with the cli anyway and configuring ethernet ports. There are afaik not many options to configure other types of ports on simulated hardware / quagga's though. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Training?
[EMAIL PROTECTED] wrote: The magic answer to training setups: one big fat Xen box with a lot of VM's, virtual interfaces and of course: Quagga. You said magic. Does this mean that there is a site where you can download ISOs for this big fat XEN box? www.debian.org www.ubuntu.org www.fedoraproject.org I guess you know how that works. (apt-get install quagga, *xen etc.. read the various FAQ's online) XORP is of course also a great one, but doesn't have the 100% cisco-alike feeling. You could possibly even use livecd's for this. It might be an idea for somebody indeed to make a pre-cooked iso which does something like this, then again, like quite a few other things, as it is quite specific, a mere howto build a fat Xen-Quagga howto might be more appropriate than yet another distribution... That said of course, who still types directly into their routers? I do hope that folks use one of the nice (custom) router/device management tools out there which avoids all of that. You still have to figure out what to put into such a tool and that often involves quite a bit of labwork where you type things into routers and watch the results. Of course, but that is why, when you build a network, you first set it up in a lab. You can't make something when you don't know what you are going to do with it. A good extensible design and above all, a lot of experience, will help a lot in that area. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Cool IPv6 Stuff
Charlie Allom wrote: On Fri, Jun 01, 2007 at 02:28:34PM +0100, Jeroen Massar wrote: I am spamming this to NANOG, as there is bound to be ISP's out there and other service providers who might have something cool to add to I have plans to use IPv6 on people's ADSL so they can subscribe to multicast music streaming from the major label catalogues we have licensed for playlouder msp. http://devblog.playlouder.com/ You mean something like: http://unfix.org/projects/radio/ ? :) From the page I spammed: 8 Multicast IPv6 Some of the SixXS PoPs support Multicast IPv6, see the separate Multicast Support FAQ for more information. More information and the possibilities of Multicast can be found on m6bone. One could also take a look at Radio.Unfix. --8 And of course never forget the marvelous VideoLAN Client (VLC) and there are a lot of other tools available that can do similar things. It is one of the main reasons why we have, at least experimental, multicast supported by various SixXS PoPs. The overlay nature of Tunnel Broker setups, and relatively small scale, make that possible. Larger setups, like at ISP's, will be quite a bit more troublesome, which is also one of the reasons that Multicast is still marked experimental, as I still need to finalize the code for doing it in a scalable manner... Using ECMH (http://unfix.org/projects/ecmh/) or mrd6, which copied that same system, getting IPv6 Multicast connectivity is relatively easy. Hooking up to the m6bone can be a bit difficult, but definitely possible. Talk to the folks at the m6bone lists (http://www.m6bone.net) and they will get you sorted for sure. Something quite cool is that the Holy See (aka The Vatican :) is streaming various things onto the m6bone reaching a lot of people that way. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Advertisements
Stephen Sprunk wrote: Thus spake Donald Stahl [EMAIL PROTECTED] Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that. I can't imagine what an end-user could come up with to justify more than a /48 but what do I know. First of all, there's disagreement about the definition of site, The general definition of a site that I find appropriate is and works pretty well as a rule of thumb: A site is defined by it having a single administrative domain. As such, if you have for example an NREN, most likely every University will have their own Networking Department, with their own administrators of that network. As such, every university is a site. When the University is very large, it will have multiple administrative portions, eg generally Computer Science will have their own folks managing the network. When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up. It comes sort of close to an AS actually, except that an AS tends to cover a lot of sites. some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts. If you have 40k sites, then a /32 is a perfect fit for you. There are not too many organizations that come close to that though, making /32's excellent for most organizations, except the very small ones. These can request a /48, or something upto a /40 for that purpose. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 Advertisements
[EMAIL PROTECTED] wrote: On Thu, 31 May 2007 18:40:42 BST, Jeroen Massar said: When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up. Works great, until you realize that for traffic engineering purposes, you really want to announce your Los Angeles site at an exchange near there, and your London site to be announced near there, and you end up wondering whether deaggregating the /48, or getting a second/third /48 would be wiser.. ;) Yes, that is indeed one of the many problems that come associated with getting a huge /32. You are supposed to announce that at in one aggregated chunk... At the moment you end up announcing chunks of the /48 to the local area and backhauling traffic from one site to another. The option for getting a separate /48 per site is then very tempting I guess. Unless you have a 10k or so of those sites... Firewall-wise having one big chunk is of course very interesting as you only need 1 ACL. Then again, do you trust everybody in your company? :) I guess that a different way of authentication, eg using authenticated packets (IPSEC AH) will become more and more common. One part missing there is a Token which can be added though, eg you have a local Authority which says I allow X to send packet from Y to Z, take that token and attach it to packets. Firewalls trust the Authority and thus allow those packets through. Accidentally this is similar to something that came up in the DTN meeting last week. This is something that needs to be solved with a magic new routing mechanism though, like a lot of other things. Greets, Jeroen signature.asc Description: OpenPGP digital signature
ULA Registry
[Major cross post, set reply-to to NANOG, please honor it... ] [Note: I am not talking about ULA Central here, though it could apply] To stop the pesky emails about ULA, I hereby present a (partial) solution to this problem. We have ULA as per RFC4193. With a little math one can generate a ULA prefix sized /48 which is most likely globally unique. According to the RFC with 10.000 connections the collision probability is still a huge 4.54*10^-05. Some people have expressed a problem with this, especially when they want to use the generated ULA prefix for their large organization. The simple, cheap and quick solution: a ULA registry. This comes close to ULA-Central, but what we do is simply make a list of the in use ULA's, without any allocation policies whatsoever except: first come first serve and no cash to pay. The tool is here: http://www.sixxs.net/tools/grh/ula/ The page allows one to generate a ULA based on a given MAC address (multicast + locally defined + unregistered are not accepted) and then register it. The Name + Email are mandatory to restrict abuse a little bit. Email is not shown, except in whois and can be used to possible contact people who are leaking ULA prefixes. Note, it is indeed a _partial_ solution. When somebody still generates the same ULA prefix and does not check the list you can still collide. As this is primarily a problem for big organizations, they should be checking this list for collisions and registering their prefix when they see that they have a need for that. The list is available from the website, but also per whois.sixxs.net which is now serving up fd00::/8. It does not cover ULA-C (fc00::/8). As SixXS is a private hobbyproject kind of thing, we of course are not liable for anything that this might cause to you, your family, company etc. But enjoy it nevertheless. Full copies of the list in inet6num format are available from the site. Greets, Jeroen PS: GRH still classifies ULA's as BAD of course PPS: Thanks to Peter van Dijk for the multicast/locally defined MACs PPPS: Folks registering prefixes like crazy will nicely get locked out automatically, so don't even try... S: Thanks to SUZUKI Shinsuke and Holger Zuleger for the generator. signature.asc Description: OpenPGP digital signature
Directly contacting ISP's (Was: How many others are nullrouting BT?)
Jo Rhett wrote: [..] While NANOG is a nice stopgap for getting to the right people, it seems to me that we should, collectively, come up with a better system for doing this. If only the RIR databases were verified so that all contacts listed were reading, willing and able to act on abuse issues... [..] The RIR data only pointed to [EMAIL PROTECTED], and that was getting me nowhere. [..] RIR data is 'too open' for real contacts to be found. Like spam can cause abuse@ addresses to become useless, the information in the RIR data mostly also get overspammed and thus often are not properly read. There are of course a lot of places who do read them but still. IMHO the data present in RIPEdb is also of much higher quality than the data in ARIN, but that is my opinion. Thus your other option as a Network administrator becomes to look up the contact data in the Peering Database: https://www.peeringdb.com For BT this lists a NOC email address, and a direct person for Technical and Policy decisions, which has an email and phone contact for your perusal. Not directly the right person, but it at least brings you somewhat in the right direction. Next to that, of course never hesitate to setup an INOC-DBA account and hook yourself up there. That brings your complaint only a simple asn-dail away ;) As these two mediums are more or less restricted to folks who actually run an ASN, the chance of abuse/nonsense is lower, as such there is more value and people tend to pick up the phone much easier. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Best practices for abuse@ mailbox and network abuse complaint handling?
K K wrote: [..] I'm hoping to find either a better and widely accepted way to handle non-spam-related network abuse complaints (hacking, DoS, etc), or at least best practices for triage on the huge volume of mail that comes into abuse@, procedures such that the rare legitimate complaint about non-spam network abuse can be routed to my team in a timely manner. whois is the right one. But IMHO the ARIN whois is a bit limited and also odd, but that might be because I am used to seeing a different kind of data ;) In RIPE db we have a nice IRT (Incident Response Team) object which is meant for this, see amongst others: http://www.ripe.net/info/ncc/presentations/irt-tfcsirt6/sld001.html http://www.ripe.net/db/support/security/irt/irt-h2.html Next to that there is the 'abuse-mailbox' line which can be inserted with most objects, similarly to irt. These will at least allow your users to find you. Some of the tools out there that auto-spam abuse@ when they get a silly portscan use those fields, so at least you will get it at the right address and not at every other single address that is listed in whois. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: www.cnn.com
Stefan Schmidt wrote:
On Thu, Apr 26, 2007 at 10:06:32AM +0100, Randy Bush wrote:
roam.psg.com:/usr/home/randy doc -p -w www.cnn.com.
Doc-2.2.3: doc -p -w www.cnn.com.
Doc-2.2.3: Starting test of www.cnn.com. parent is cnn.com.
Doc-2.2.3: Test date - Thu Apr 26 09:04:52 GMT 2007
DIGERR (NOT_AUTHORIZED): dig @dmtns01.turner.com. for SOA of www.cnn.com.
failed
DIGERR (NOT_AUTHORIZED): dig @dmtns02.turner.com. for SOA of www.cnn.com.
failed
I think your debugging tool is faulty, as a dig ns cnn.com
[..]
All of the above answer to me and have the same serial for cnn.com.
Randy is looking at www.cnn.com (note the www portion) and if you would
do a 'dig +trace www.cnn.com' you would see:
www.cnn.com.3600IN NS dmtns01.turner.com.
www.cnn.com.3600IN NS dmtns02.turner.com.
;; Received 112 bytes from 207.200.73.85#53(twdns-03.ns.aol.com) in 176 ms
www.cnn.com.600 IN A 64.236.16.20
[..9 ip's..]
;; Received 157 bytes from 64.236.22.150#53(dmtns02.turner.com) in 100 ms
And dmtns0{1|2}.turner.com. don't have a SOA for www.cnn.com although
they are authoritive. They only respond to queries for A. Fortunatily
they do respond for queries, 0 records result, but it doesn't
break. They do simply drop queries asking for SOA,MX,TXT and prolly others.
Aka just another peeped up DNS loadbalancer for which the implementers
didn't read the RFCs or where the configurators decided that they can
ignore other stuff for anti-ddos or other reasons.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
Re: IP Block 99/8 (DHS insanity - offtopic)
Sean Donelan wrote: On Mon, 23 Apr 2007, Chris L. Morrow wrote: I think the strawman proposals so far were something like: 1) iana has 'root' ca-cert 2) iana signs down certs for RIR's 3) RIR's sign down certs for LIR's 4) LIR's sign down certs for 'users' (where 'users' is probably address-space users, like corporations or end-sites) This seemed not-too-insane, and would give ISP/operator type folks that ability to easily and quickly verify that: 157.242.0.0/16 is in point of fact permitted to originate by the org-id: LMU-1 with some level of authority... It's nothing really more than that. You can do online or offline verification of a trust chain. RSA, certs, etc are just the math. But the math doesn't change the trust. If the LIR/RIR directories are poorly maintained, their signatures aren't going to be any better. IMHO ISP's that are not maintaining their entries correctly should not have a place on the Internet. In IPv6 one can see it quite well actually, when one has route6 entries the prefix has more of a chance of piercing through filters than when it has none. Adding a signature to this chain of checks and enforcing BGP announcements to be signed would definitely weed out a lot of bad ISP's who can't care less as they suddenly start loosing connectivity. Do also note that, like DNS roots, anybody can setup their private signing authority and provide certs to their buddy ISP's in a similar manner. The problem in your trust chain above is the LIR's don't actually verify much about the 'users'; and its very easy to spoof the LIRs (i.e. I forgot my password) to change their directory information. And the same thing will probably be true when you ask LIRs to sign things. I lost my RSA cert, please sign a new one for me. This is also more about who is responsible for the address. Not who actually uses the address space. With hacked computers and botnets and the likes that is an unknown anyway. But when the responsible organization crosses the line a couple of times, it is easy to see where the bad ones really are. An online chain of RWHOIS delegations or a offline chain of RSA certificates (which you will still need an online CRL check), doesn't change the problems in the LIRs (or even RIRs or IANA). A lot of math won't make the answer more authoritative. What is the problem here then? You simply mark the LIR as untrustworthy when they peep up a number of times and as more and more ISP's do that they silently disappear from the Internet, at least the one where the 'trusted' ISP's are in. This is the same as de-peering ones who are not being nice to you, but now you at least know it is them being bad and not somebody just hijacking them. It's just a little step up from what already gets done. With every verification mechanism that involves trust and signing there usually is also a need for a white and a blacklist, you can manage these yourself or you can let some 3rd party do it, like what is done with many of the spam cases. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Question on 7.0.0.0/8
David Conrad wrote: [..] Why doesn't IANA operate a whois server? We do. The proper question to ask is why isn't our whois server populated with address information instead of just domain name information. I don't know the reason historically. However, today, when the topic was recently raised, concerns were expressed that IANA would be seen in competition with the RIRs and there are those that believe IANA (ICANN) should have no operational role whatsoever. With that said, IANA continues to look at adding top level (i.e., /8s for IPv4) block allocation information to the IANA whois server and this is something we're discussing with the RIRs -- I don't think anybody is particularly happy with the current state of affairs. Competition? How can it be competition when you are at the top of the food chain. Unless I am misunderstanding something completely that is the place that IANA has. IANA has all the address space. It loans chunks of this address space to the RIR's by delegating it to them. Then the RIR's delegate this to LIR's who delegate it to end-users. As such, IANA having a whois server which delegates this address space down to the RIR's would be a great thing to have and also totally logical and in no way in 'competition' with the RIR's. I am also quite sure that none of the membership of those RIR's will complain about this. Do expect people to then, correctly, point their whois client to whois.iana.org for IP addresses, as then those clients can follow the refer: headers down to the RIR's where the real data is. Why don't they publish a more detailled explanation field in each IANA allocation record so that they can explain the precise status of each block? What sort of additional information would be helpful? As mentioned above, we're preparing an XML-based alternative representation of various IANA registries which would give us a lot more flexibility than the current text based representation. Feel free to send mail privately as this might get a bit down in the weeds for NANOG. Database dumps similar to what the RIR's also are providing. eg like ftp://ftp.ripe.net/pub/stats But for IANA that would only be delegation points, thus a list of all the blocks IANA has delegated to the RIR's. Same for whois data (aka ftp://ftp.ripe.net/ripe/dbase/split) so one can simply fetch all those inet6num's in one go. Of course that doesn't apply to IANA as the RIR's have that data. In short: please publish inetnum/inet6num delegations from whois.iana.org to the RIR's using refer: headers in the data. On a similar subject, IANA is also a perfect place for an IRR root. Unfortunately only APNIC, RIPE seem to have a non-beta one. ARIN's rr.arin.net seems to be a bit underused. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
[h how come I didn't parse any operational content in this post...] Fred Heutte wrote: [..] I spent a couple hours in a hotel recently trying to untangle why using the DSL system I could see the net but couldn't get to any sites other than a few I tried at random like the BBC, Yahoo and Google. That's because they are among the few that apparently have IPv6 enabled web systems. They don't have IPv6 enabled web systems, a lot of people wished that they did. What your problem most likely was, was a broken DNS server, which, when queried for an simply doesn't respond. Most Network Operators (to keep it a bit on topic for this mailinglist) can't do anything about broken DNS servers at End User sites. Note that this has *nothing* to do with Teredo, which even doesn't activate itself when it can't get packets to be relayed. You can't thus blame Microsoft for this. The DNS server is broken, not them. I know it is always fun to blame M$ but really it isn't true. Note also that the BBC once did have a related DNS problem, that was in 2002 though and was quickly resolved: http://www.merit.edu/mail.archives/nanog/2002-04/msg00559.html These had another kind of problem, they returned NXDOMAIN, so that it looked like the requested label was not there; much better still than the simple ignore and forget of the End User DNS problems. I was once, circa 1995 or so, fairly enamored of IPv6. Now it makes me wonder just exactly what problem it is good at solving. Primarily only one: a *lot* more address space. Enough to provide our children's children children and the rest of the world with unique addressable address space. Nothing more nothing less. Don't get me wrong -- it's not the fault of IPv6 and its designers and advocates, it's that the world has moved on and other methods have been found for the questions it was designed to address. As it primarily resolves the address space problem and it solves this perfectly well, how exactly did your world move on by staying limited to 32bits and only 4 million addresses while there are many more people on this planet, not even thinking of subnets or having multiple addresses per person? Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
Chris L. Morrow wrote: [..] the STSN devices? or 'ibahn' ? One thing to keep in mind is that the DNS-LB used by Google/yahoo (in the examples above) seems to be returning a CNAME for queries, then nothing for the follow-up resolution request for a for the CNAME... So, ipv6 things may look 'broken' because they are also 'slow' (waiting to re-do much of the lookup path to get the A version) (snipped for brevity) 8--- $ dig @ns1.google.com www.google.com ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41689 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7 ;; ANSWER SECTION: www.google.com. 604800 IN CNAME www.l.google.com. $ dig @ns1.google.com www.l.google.com ;; -HEADER- opcode: QUERY, status: NOERROR, id: 44383 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7 ---8 8--- $ dig @ns5.yahoo.com www.yahoo.com. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3095 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.yahoo-ht3.akadns.net. $ dig @eur1.akadns.net www.yahoo-ht3.akadns.net. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 15024 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ---8 The Yahoo redirect is out of bailiwick and thus requires a full lookup again, the google one at least can be served by the same box. But for the rest it all seems pretty fine to me... or do you mean that those ibahn things see NOERROR and then no answers, thus wrongly cache that as label has 0 answers at all? or what I mention above with the redirect? Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
Stephen Sprunk wrote: Thus spake Jeroen Massar [EMAIL PROTECTED] But for the rest it all seems pretty fine to me... or do you mean that those ibahn things see NOERROR and then no answers, thus wrongly cache that as label has 0 answers at all? or what I mention above with the redirect? They do the same thing for requests that don't involve a CNAME, so they're either choking on the query or a NOERROR response in general; it's hard to tell which since I can only see one side of their box. I also don't know how they react when you try to contact a site that _does_ have records, since no major content site has them (which is a whole 'nother discussion). Wellps, we have www.ipv6experiment.com of course where the actual content site soon will point to 2001:4978:0:0:0:0:B00:B1E5 :) /me wonders how many spam/corpfirewalls etc will like that sentence, but hotels won't have much of an issue with that I guess, it's one of the reasons for their existence... What's weird is that they don't just return a 0-record NOERROR when you do the follow-up A query, which would be the most logical failure mode -- they return an authoritative answer of 0.0.0.1 instead. Ick. These folks really need a clue batting don't they? Of course, dealing with idiot consumers on a regular basis, their tech support folks insist the problem is on the user's machine and that it's a bug in their v6 stack, despite Ethereal captures showing the bad DNS response packets coming from their box... Argh, I can sort-of understand their way of handling it, but still, they should have fixed this by now, and their clear broken DNS is simply a real reason to avoid those hotels at all. Can somebody please sponsor a trip to any of these hotels for either two or both of the Pauls, that is Mockapetris or Vixie, and let THEM call techsupport on this!? :) At least the eh dude, I kinda like (invented DNS|coded BIND) and I really do think I sort of know what I am talking about discussion would be worth a extremely priceless rating and a good laugh for the coming years for most of the Ops community :) Remember kids: never leave home without a well known IP address where all kinds of obvious ports run your favorite tunneling mechanism :) [443 seems to be very popular for that nowadays it seems...] Long live tunnels and own infra! Greets, Jeroen -- Have broken DNS = $10 Room for a Paul = $500 Letting Paul expain DNS problem to L1 Tech = Priceless signature.asc Description: OpenPGP digital signature
Re: Question on 7.0.0.0/8
[EMAIL PROTECTED] wrote: We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We were told that this netblock should not see the light of day, 10/8 used to be a DoD address block, but it was also used exclusively in their blacker networks and similar non-connected infrastructure. The result is that 10/8 was opened up for others to use as well. Could we do similar with 7/8? What problem would that solve instead of reducing a wee tiny bit the collisions that might occur? Large networks are currently already established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would still be renumbering. For those networks it is much better to simply get a block from their RIR and use that and never have collisions. Also note that Fastweb in Italy is already using 7.0.0.0/8 inside their network for their customers, who sit behind a NAT. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Question on 7.0.0.0/8
Iljitsch van Beijnum wrote: [..] Another interesting case: 025/8 Jan 95 UK Ministry of Defense (Updated - Jan 06) [..] I tried emailing RIPE and ARIN. [EMAIL PROTECTED] returned my message unread and I have no idea what other email adddress to use, [EMAIL PROTECTED] talked at length about cleaning up the legacy A space without actually addressing the issue. Good times. Use [EMAIL PROTECTED] for all RIPE whois (DataBase Manager - dbm) related issues. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Netops list
Roland Dobbins wrote: On Mar 28, 2007, at 12:54 PM, Steve Sobol wrote: If I am seeing a routing problem, is Jared's list an appropriate place to check for contacts at the ISP with the problem? One hopes so. Come on, it usually is :) Also for all IPv6 related Operational Discussions: http://lists.cluenet.de/pipermail/ipv6-ops/ I'll also abuse this mail to spam something (already posted there): 8-- On 2007-04-01 I will release a new GRH Tool dubbed: Longest Distance Routing What it exactly will do will be shown then. Small hint: check up and fix your BGP tables. --8 Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: [cacti-announce] Cacti 0.8.6j Released (fwd)
Paul Vixie wrote: [EMAIL PROTECTED] (Jason LeBlanc) writes: After looking for 'the ideal' tool for many years, it still amazes me that no one has built it. Bulk gets, scalable schema and good portal/UI. RTG is better than MRTG, but the config/db/portal are still lacking. [..] been there, done that, got the t-shirt. is there funding available yet? like, $5M over three years? spread out over 50 network owners that's ~$3K a month. i don't see that happening in a consolidation cycle like this one, but hope springs eternal. give randy and hank the money, they'll take care of this for us once and for all. Heh, for that kind of money you can even convince me to do it ;) Greets, Jeroen (dreams about a long holiday after finishing it ;) signature.asc Description: OpenPGP digital signature
Re: Google wants to be your Internet
[ 2-in-1, before I hit the 'too many flames posted' threshold ;) ] Roland Dobbins wrote: On Jan 22, 2007, at 10:49 AM, Jeroen Massar wrote: But which address space do you put in the network behind the VPN? RFC1918!? Oh, already using that on the DSL link to where you are VPN'ing in from. oopsy ;) Actually, NBD, because you can handle that with a VPN client which does a virtual adaptor-type of deal and overlapping address space doesn't matter, because once you're in the tunnel, you're not sending/receiving outside of the tunnel. Port-forwarding and NAT (ugly, but people do it) can apply, too. How do you handle 192.168.1.1 talking to 192.168.1.1, oh I do mean a different one. Or do you double-reverse-ultra-NAT the packets !? :) One doesn't want to solve problems that way. That is only seen as creating problems. Good for a consultants wallet, but not good for the companies using it and neither good for the programmer who had to work around it in all his applications. That is the case for globally unique addresses and the reason why banks that use RFC1918 don't like it when they need to merge etc etc etc... Sure, and then you get into double-NATting and who redistributes what routes into who's IGP and all that kind of jazz (it's a big problem on extranet-type connections, too). To be clear, all I was saying is that the subsidiary point that there are things which don't belong on the global Internet is a valid one One can perfectly request address space from any of the RIR's and never ever announce or connect it to the internet. One can even give that as a reason I require globally unique address space and you will receive it from the RIR in question. One doesn't need to use globally unique address space in the Internet, it is perfectly valid to use it as a disconnected means. Simple example which nicely works: 9.0.0.0/8 That network is definitely used, but not to be found on the Internet. Also, how many military and bank networks are announced on the Internet? If they are announced, they most likely are nicely firewalled away or actually disconnected in all means possible from the Internet and just used as a nice virus trap, as those silly virusses do scan them :) and entirely separate from any discussions of universal uniqueness in terms of address-space, as there are (ugly, non-scalable, brittle, but available) ways to work around such problems, in many cases. You actually mean that you love to create all kinds of weird solutions to solve a problem that could have easily be avoided in the first place!? I don't think I would like to have your job doing those dirty things. With IPv6 and ULA's especially those mistakes fortunately won't happen that quickly any more. Saves you, me, and a load of other people a lot of headaches. Maybe you won't be able to consult for them any more and make quite some money off them, well that is too bad. And now for some asbestos action: short summary: a) use global addresses for everything, b) use proper acl's), c) toys exist that some people clearly don't know about yet ;) No further technical content below, except for a reply to a flame. (But don't miss out on the pdf mentioned for the toys ;) Jim Shankland wrote: In response to my saying: I'd love to hear the business case for why my home electrical meter needs to be directly IP-addressable from an Internet cafe in Lagos. Jay R. Ashworth [EMAIL PROTECTED] responds, concisely: It doesn't, and it shouldn't. That does *not* mean it should not have a globally unique ( != globally routable) IP address. and Jeroen Massar [EMAIL PROTECTED] presents several hypothetical scenarios. Are you trying to say that I make things up? Neat, lets counter that: http://www.sixxs.net/presentations/SwiNOG11-DeployingIPv6.pdf (yes, I know large slideset, unfortunately alexandria.paf.se where the pix came from is not available anymore and I can't find another source) Slides 50-57 show some nice toys which you can get in the Asian region already. This is thus far from hypothetical. Note the IPv6 address on that hydro controller's LCD, it can be used to water your plants. Yes, indeed, when that show was happening, it was globally addressable, just like the camera and all the other toys there. And yes, I gave the plant water using telnet :) That you don't have it, That you didn't see it yet, doesn't mean it does not exist. Note that the original goal was for electrical companies to monitor electrical meters. Jeroen brings up backyard mini-nuke plants, seeing how much the power plug in the garden is being used, etc. These may all be desirable goals, but they represent considerable mission creep from the originally stated goal. What is your point with writing this section? Trying to explain that it does not conform to your exact wishes? Or do you just want to type my name a couple of times to practice it? I know it is as difficult to pronounce as to type it ;) Dunno
Re: Google wants to be your Internet
Jim Shankland wrote: Travis H. [EMAIL PROTECTED] writes: IIRC, someone representing the electrical companies approached someone representing network providers, possibly the IETF, to ask about the feasibility of using IP to monitor the electrical meters throughout the US The response was yeah, well, maybe with IPv6. Which is nonsense. More gently, it's only true if you not only want to use IP to monitor electrical meters, but want the use the (global) Internet to monitor electrical meters. Ah, cool, an advocate of NAT. Or didn't you want to say that one can just make their own IPv4 address space and use that ? Remember that the machines checking the billing most likely has a global address and RFC1918 ain't nice. Barring getting address space, IPv4 and IPv6 will both do fine for it. I'd love to hear the business case for why my home electrical meter needs to be directly IP-addressable from an Internet cafe in Lagos. 1) You are on vacation and want to check if you actually turned on that mini-nuke plant in your garden, so that you will retain some cash on your credit card so that you can still come home. 2) You are still on vacation and want to check if your kids are not over abusing electrical power instead of being 'green' for the environment. 3) You are already on the northpole, Lagos was boring after all, and you want to check about that email you received from the electrical company, to see where the power usage was actually so high. You notice that the power plug in the garden is being used a lot, look at the webcam there and notice that your neighbor is using your power. Oh, only one case eh? :) But I guess it is nonsense. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Google wants to be your Internet
Roland Dobbins wrote: On Jan 22, 2007, at 9:38 AM, Jeroen Massar wrote: But I guess it is nonsense. This is what ssh tunnels and/or VPN are for, IMHO [..] Of course, for protecting them you should use that and firewalls and other security measures that one deems neccesary. But which address space do you put in the network behind the VPN? RFC1918!? Oh, already using that on the DSL link to where you are VPN'ing in from. oopsy ;) That is the case for globally unique addresses and the reason why banks that use RFC1918 don't like it when they need to merge etc etc etc... Fortunately, for IPv6 we have ULA's (fc00::/7), that solves that problem. /me donates coffee around. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Google wants to be your Internet
Gadi Evron wrote: On Sat, 20 Jan 2007, Jeremy Chadwick wrote: snip ISPs probably don't have an interest in BT caching because of 1) cost of ownership, 2) legal concerns (if an ISP cached a publicly distributed copy of some pirated software, who's then responsible?), They cache the web, which has the same chance of being illegal content. [..] They do have NNTP Caches though with several Terabytes of storage space and obvious newsgroups like alt.binaries.dvd-r and similar names. The reason why they don't run BT Caches is because the protocol is not made for it. NNTP is made for distribution (albeit not really for 8bit files ;), the Cache (more a wrongly implemented auto-replicating FTP server) is local to the ISP and serves their local users. As such that is only gain. Instead of having their clients use their transits, the data only gets pulled over ones and all their clients get it. For BT though, you either have to do tricks at L7 involving sniffing the lines and thus breaking end-to-end; or you end up setting up a huge BT client which automatically mirrors all the torrents on the planet and hope that only your local users use it, which most likely is not the case as most BT clients don't do network-close downloading. As such NNTP is profit, BT is not. Also, NNTP access is a service which you can sell. There exist a large number of NNTP-only services and even ISP's that have as a major selling point: access to their newsserver. Fun detail about NNTP: most companies publish how much traffic they do and even in which alt.binaries.* group the most crap is flowing. Still it seems totally legal to have those several Terabytes of data and make them available, even with the obvious names that the messages carry. The most named reason: It is a Cache and we don't put the data on it, it is automatic... yup alt.binaries.dvd.movies whatever is really not so obvious ;) Of course replace BT with most kinds of P2P network in the above of course. There are some P2P nets that try to induce some network topology though, so that you will be downloading from that person next door instead of that guy on a 56k in Timbuktoe while you are sitting on a 1Gbit NREN connect ;) But anyway what I am wondering is why ISP folks are thinking so bad about this, do you guys want: a) customers that do not use your network b) customers that do use the network Probably it is a) because of the cash. But that is strange, why sell people an 'unlimited' account when you don't want them to use it in the first place? Also if your network is not made to handle customers of type b) then upgrade your network. Clearly your customers love using it, thus more customers will follow if you keep it up and running. No better advertisement than the neighbor saying that it is great ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv6 section of ARIN Number Resource Policy (Sec 6.5.1.1.c)
Pekka Savola wrote: On Wed, 17 Jan 2007, Nicolás Antoniello wrote: A /28 prefix may have a lot of incoming traffic associated to it, so I believe the dissagregation (subnets) of the prefix should be allowed by the policy. I guess you are talking about 2800:a0::/28 which was allocated by LACNIC, and not ARIN, 2 days ago and is not in the routing tables yet: http://www.sixxs.net/tools/grh/dfp/all/?country=uy Funnily 2001:13c0::/32 is also allocated to the same organization. Which was allocated 2005-08-10 and was seen already a week later. Thus either you figured out that the /32 was too small or you are trying to have two prefixes and announce them both ;) I assume the first, but the question then is, will you return it. Also folks: please register route6 objects in either RIPE or RADB (ARIN/APNIC/LACNIC don't where possible, that makes it much easier to determine if the correct ASN are originating the correct prefix. What do you think? Do you have a similar problem? Please achieve inbound load balancing on other, less network-stressful, ways. At least one way to do so to examine what can be done to influence your upstreams' (and recursively if applicable) route preferences (e.g., using communities). Indeed. That is how it should be done. These issues should be handled by the routing protocol. Also: * ISP's are already de-aggregating their prefixes See http://www.sixxs.net/tools/grh/lg/?show=bogonsprefix=::/0 (Only run that query when you have the time to wait it is huge and it will make your firefox think it hangs ;) With loads of /35's, /40's and /48's which can easily be aggregated as they are coming from the same ASN, thus clearly they are not multihoming examples. But note that due to filtering some prefixes get really bad connectivity. As they will be filtered by the fast and speedy transits, while being accepted by the slow ones. The slow ones do announce it, thus in the end your packets will take the slow route. * What business has a RIR telling one how to do routing? RIR's should give out address space to organizations that need it and that is it. Note that Address Space != Routing. That a RIR recommends to not de-aggregate is VERY good hint from them though. But requirement is something else. For that matter, they can't stop you anyway. But other ISP's can and those are the ones one talks with and pays cash to to carry the prefixes(*). Do also note that the RIR's are community driven, as such the community makes up the rules, vote with your words if you need to. That said, ISP's that don't want de-aggregates can filter them out Examples here: http://www.space.net/~gert/RIPE/ipv6-filters.html On another note here, when S-BGP gets introduced, are the RIR's going to give certificates away which allow announcing de-aggregates of allocations? :) If they don't then that will solve this de-aggregate problem in one go. be conservative in what you send, be liberal in what you receive :) Greets, Jeroen * = Networking 101 for Evil Internet Beings: if you don't want to use the RIR's one can always setup his/her own RIR and simply pay ISP's to accept your prefix. Cash also works for creating .xxx TLD's and a lot of other things. And that is still the cool thing with the Internet, if you have enough force (cash, politics etc) or followers then at a certain point your part of the internet becomes important enough that people require it's use. signature.asc Description: OpenPGP digital signature
Re: FON Router allows anonymous web access (fwd)
Gadi Evron wrote: [..] Environment: Tested with router's standard config on 01/04/07. Runs smoothly with NSTX (http://nstx.dereference.de/nstx/ Version 1.1-beta6) and an ssh-session for connection testing without any authentication via the FON captive portal. Any smart user can get around most silly blocks, what is so special about this. This is the same deal used for getting around a large majority of 'firewalls' and of course most airport hotspots and most other places where geek people need connectivity and don't want to bother getting a silly registration card for it or pulling their visa card number from that text file they keep somewhere. Nothing new there... except that maybe these things where supposed to be really closed per default and in other cases the administrator of the box is just not doing his job correctly as the tools provided don't allow him to ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: RIS [Re: AS41961 not seen in many networks]
Randy Bush wrote: Well, the undocumented fact is that RIS does not accept multi-hop BGP peerings, which may somewhat limit its coverage. this is a good thing. as multi-hop bgp is very fragile, measurements go borkville just when you want them the most. While that is true, it does help in the cases when there is connectivity between the two BGP speakers in question. For instance GRH would not have been possible if it was not for multihop-bgp. Indeed when connectivity breaks, it is useless, but most of the time it works and then it is great to have. A better requirement for RIS could be that it would be advised to be present at an IX and peer there, otherwise offer the option of multihop-bgp so that people who are not too-well connected can also contribute to it. The ones present at the IX's are also the ones which will cause multihop to break when the IX or they themselves go down, the remote participants are most likely smaller players thus them going down and going off the system doesn't really hurt a lot, except them. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: AS41961 not seen in many networks
Sebastian Rusek wrote: Hi, Since November 2006 we announce our 3 new prefixes: [..] Could you please check your configuration or help us to isolate the problem? You could also check http://www.ris.ripe.net/ and use that tool to determine exactly which networks are not seeing you and then contact those operators to fix their setups. And for people not peering with RIS yet, PEER! (info at the url) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Home media servers, AUPs, and upstream bandwidth utilization.
Roland Dobbins wrote: I recently purchased a Slingbox Pro It's a neat toy indeed, I would almost run out to get one too was it not for the cash deficiency. I assume you got your X-mas presents early ? :) [..] What I'm wondering is, do broadband SPs believe that this kind of system will become common enough to make a signficant difference in traffic paterns, and if so, how do they believe it will affect their access infrastructures in terms of capacity... The fun part is that some ISP's 'restrain' people to use P2P and other big traffic hogs, but they (at least some :) do provide huge NNTP servers providing large local caches of truly illegal content and most of them also seem to advertise with download movies and music, now faster and faster than all the other competition. ISP's should not be classifying nor filtering any of the data that one is transmitting, especially as when they will do that people will simply start using port 80 or 443 SSL'd for everything to avoid those crap filters. I wonder when the usage of IPSEC will become more dominant as that will also nicely equal out any form of discrimination (can't call it anything else) there. Filtering default ports like 25 outbound and some other silly virus-prone things like 137-139/445 etc is okay, BUT provide a way to disable this easily. A certain Dutch ISP allows doing this using a webinterface, which is a perfect method and saves on support calls. That said ISP's should simply have a package saying 50GiB/month costs XX euros, 100GiB/month costs double etc. As that covers what their transits are charging them, nothing more, nothing less. The money then is to be made from selling a large package to a stupid user who doesn't use the traffic, or as that above mentioned ISP once said in the hallways we have a few folks doing 400Gb/month, but it's only a few and if we factor in the people doing almost nothing it equals out very well. Please note my careful putting of 'usual' and 'most' and 'some' all over the place, it might seem annoying, but that avoids all those nice responses with but we don't do that kind of arguments; there are fortunately a number of ISP's who simply can't care less what you do as long as you pay the bills, and that is what they are supposed to be doing. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Bogon Filter - Please check for 77/8 78/8 79/8
Barry Greene (bgreene) wrote: [..list of good things..] So what would be helpful are people who say I've done everything (or some of the things) off the Bogon Team page and think there is a better way. The core problem right now are that too many organizations are doing nothing to maintain policy once that policy choice has been selected. As Esmerelda the frog would say: S-BGP (*1) is the better way. Any ideas when Cisco is going to drink the cool-aid to get hooked in that and provide that to it's users? (Although one source told me that Cisco is not more the king of the core internet and that it got taken over by another vendor who should set steps in that direction first..) Of course the steps that sidr(*2) is taking is also a step in the right direction, but might be quite a slow one when people wanted this almost 10 years ago(*3) but that is the internet it seems. Running code is important, but clearly not when it could hurt people's pockets or when there is no real actual interest in solving this problem. That seems to be the real core problem: There is enough money being earned by being able to announce bogon routes and there is not enough money that can be earned back by upgrading hardware/software to implement those checks. Marketing 101 it seems, nothing technical to see here. The policy can be handled by a limited amount of organizations: IANA the RIR's, there is only 6 of them, of which APNIC, with much thanks to the efforts by Geoff Huston(*4) doing experiments already. Greets, Jeroen *1) http://www.ir.bbn.com/sbgp/ *2) http://www.ietf.org/html.charters/sidr-charter.html *3) http://www.ir.bbn.com/sbgp/s-bgp-briefing/sld003.htm *4) http://kahuna.telstra.net/presentations/2006-11-27-route-secure.pdf http://kahuna.telstra.net/presentations/2006-11-03-caida-wide.pdf and others: http://kahuna.telstra.net/presentations/index.html signature.asc Description: OpenPGP digital signature
Another bogon block: 2001:678::/29 (Was: Bogon Filter - Please check for 77/8 78/8 79/8)
[After the very short IANAL part, an operational part wrt 2001:678::/29] Robert E. Seastrom wrote: no, he's saying that a lawsuit is a useful method of forcing someone who is intentionally or negligently distributing incorrect information that other people who do not know any better then believe and use in their own networks. If that is the basis that people sue on, then I really wonder all of a sudden when somebody will sue their government, news agencies and all those nice magazines where those paparazzi stalkers are working for. But to keep this nice and operational: Just as a side example: 2001:678:1::/48 is a DNS Anycast Block. ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest doesn't list this yet, even though it was allocated 2 months ago. There was though a 2001:678::/35 block previously (which is still in the above file but not in whois anymore). GRH thus listed this falsely. Should I thus be liable for publishing information that is wrong, as GRH was listing the /48 Subnet of a big allocation, which it in effect was, as it was, according to the tool, part of the /35. grh.sixxs.net show bgp 2001:678:1::/48 BGP routing table entry for 2001:678:1::/48 Paths: (32 available, best #30, table Default-IP-Routing-Table) And that is out of about 100 peers that GRH has. As such can I ask the community, people who are maintaining routers, to check their filters and start accepting these prefixes? Thank you. As many people rely on the 'delegated-RIR-latest' files for producing their filters, I have contacted RIPE NCC to resolve that issue, most likely that will then automatically punch the appropriate holes into the automated tools which rely on it. GRH though has been updated manually already. When RIPE NCC has fixed it up, I'll follow up to ISP's that have not fixed up their filters yet, so that that number comes quite a bit closer to 100. Thanks to Simon Leinen for reporting it btw as I hadn't noticed it: am I thus liable for 'spreading false info' ? Greets, Jeroen (glad to not be in the US :) signature.asc Description: OpenPGP digital signature
Re: Bogon Filter - Please check for 77/8 78/8 79/8
Stephen Satchell wrote: Jared Mauch wrote: linking to stuff like the bogon-announce list too wouldn't be a bad idea either :) Bogon announce list? Read here: http://www.cymru.com/ And you will find: http://puck.nether.net/mailman/listinfo/bogon-announce Btw it is the first hit on google(bogon announce list) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: rbnnetwork.org
Alexander Harrowell wrote: Is hosting a phishing site and bouncing abuse reports.. Not so strange, gmail addresses are being used a lot a for spam sources. With the description you gave, I would also ignore it, it's a miracle that the spamfilter didn't drop it dead on the floor in the first place, especially as you are spamvertizing a certain website ;) Lets see what you should do different the next time you try to report something: -- Forwarded message -- From: Alexander Harrowell [EMAIL PROTECTED] Don't use gmail, use a real address, not something which everybody can create on the fly, at random and throw away again. That gives you some credit that you are not trying to fake somebody else. Having your full name instead of barbylover666 is a good part though, gmail isn't. Date: Oct 31, 2006 2:38 PM Subject: Phisher Phisher? Is that it? Lets assume you have to handle abuse@ and you get 1000 mails a day from silly automated tools, seeing 'Phisher' as the only thing in the subject from a person from gmail will simply trigger only one action: [del]. In the 'description' below you write that they are doing comment spam. Phising != comment spam. A better subject would have been: Spamvertized website at $ip in your $ispnet, AS. Having the ASN in there gives some credibility. To: [EMAIL PROTECTED] We're receiving large volumes of comments spam advertising a site hosted in your network. http://onlineinvestmentworld.com is located at 81.95.146.166, which is your netblock: inetnum:81.95.144.0 - 81.95.147.255 Who is We? Gmail? When reporting something it is actually useful to show proof somewhere, thus simply point to the websites in question. As those websites are yours you most likely also have logs of those sites, then you can also contact the ISP's who are actually spamming the comments. SNIP RIPE object They know who they are, so you don't have to repeat that. As this message, according to you, bounced, you could also have tried the admin and tech handles. Altough in this case that leads only to [EMAIL PROTECTED] Email wise you are thus out of luck, but those handles do contain phone numbers, which you can use then to resolve this. Another way, instead of calling (which might be horrible if you don't speak russian ;) is too check their peers and transits: http://www.robtex.com/as/as40989.html which tells you that it is a very small company with only one /22, they are pretty new to the game and some other things. As they are a small ISP, they clearly have a transit and you can always contact them if they don't reply to your mails or they simply drop them on the floor. If you would have done a whois on rbnnetwork.com you would have found another email address and strangely, a US address and phone number. They are not so russian as they seem like after all ;) SNIP traceroute What does a traceroute do at all? It might be handy only in the case where some IP hijack is in progress, but in that case you can always do a BGPPlay using RIPE's RIS to figure out where it came from. Last but not least: there are dedicated spam etc reporting sites. Afaik Nanog is not that place. Unless your network went down because an ISP was overloading you with traffic of course ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Need help explaining in-addr.arpa to Limelight
Tuc at T-B-O-H.NET wrote: Hi, I seem to be having a problem. Limelight has SWIP'd 69.28.185.0/24 to me, and I asked for IN-ADDR.ARPA control. I recently went to check and it seemed not to be working right. I sent them an email around 11p Eastern Sunday nite asking it to be fixed. I even included a reference to a web page on how to delegate in-addr.arpa. I received the following back : This is done, but you will need to rename the zone on your end to: tboh.185.28.69.in-addr.arpa. In case they do a: 1.185.28.69.in-addr.arpa. CNAME 1.tboh.185.28.69.in-addr.arpa. That would partially make sense, though it still wouldn't as you don't have control over tboh.x.x.x... unless they delegate that to you, but that wouldn't make sense either as they can just NS the 185 also already... Is there someone out there that might be able to help me explain this to the techs there. That you can't subdomain an in-addr.arpa like you do a domain name? Why not? Reverse DNS is just another domain, you can also stick MX records in there or have a nice website if you want ;) [EMAIL PROTECTED] can work quite well as an email address if you stick the MX's in the right spot. Not very useful but still. Quite a number of operators stick stuff like TXT records in there too to describe topology and other informational elements related to that domain. There are even some anti-spam proposals doing that afaik. That is though probably not what you want to accomplish though. According to dig the domain is currently pointing to zoneedit: ;; ANSWER SECTION: 185.28.69.in-addr.arpa. 7200IN NS ns13.zoneedit.com. 185.28.69.in-addr.arpa. 7200IN NS ns8.zoneedit.com. You'll have to insert your cruft there or have them repoint it to a dns server under your control. And remember kids, don't spam the dns; there is a better use for IP addresses by for instance hungry children with hand-winded laptops. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Blogger.com posts still fails when posting to the NANOG list!
Hi, Apparently there is still some silly [f|s]oul who has to forward NANOG to blogger and blogger still doesn't handle multipart/signed and thus very nicely and totally anonymously reports that it fails. Thank you dear person who is forwarding his subscription to NANOG to his blogger account! This has been for over three months(*) now or something, clearly it is not annoying at all to the folks running the NANOG list and the person doing it clearly gets away with it. Could the blogger folks, who are seemingly uncontactable, please please please with sugar and strawbarries and whipcream on top include at least for what address this message is getting gatewayed for so that the subscription can be yanked from the NANOG list? Of course a full header trail would be even more useful. Google seems to say that this might be the one: http://www.gossamer-threads.com/lists/nanog/users/ Dear NANOG listadmins, is there anything pointing in that direction? Simple way to find out who is the culprit: spam everybody on the list with a subject of their email address and when it bounces from blogger.com check the subject in the message and then use some very huge LART tool to get rid of it. Greets, Jeroen /rant * = http://www.merit.edu/mail.archives/nanog/msg01712.html -- Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 23472 invoked from network); 23 Oct 2006 22:45:30 - Received-SPF: neutral (gurgle.mediadesign.nl: 66.102.15.83 is neither permitted nor denied by domain of [EMAIL PROTECTED]) Received: from ftpout.blogger.com (HELO blogger.com) (66.102.15.83) by gurgle.mediadesign.nl (qpsmtpd/0.32) with ESMTP for [EMAIL PROTECTED]; Tue, 24 Oct 2006 00:45:29 +0200 Received: by blogger.com (Postfix, from userid 99) id B67D9B1C8A; Mon, 23 Oct 2006 15:52:03 -0700 (PDT) Received: from bla17.blogger.com (localhost [127.0.0.1]) by blogger.com (Postfix) with ESMTP id A0300B1C8E for [EMAIL PROTECTED]; Mon, 23 Oct 2006 15:52:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Blogger post failed From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: Mon, 23 Oct 2006 15:52:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on bla17.blogger.com X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,NO_REAL_NAME autolearn=failed version=3.0.2 X-Spam-Level: X-MD-Spam-Check-By: gurgle.mediadesign.nl X-MD-Spam-Status: No, hits=3.3 required=5.0 tests=AWL,DNS_FROM_RFC_POST,NO_REAL_NAME,SPF_NEUTRAL X-MD-Spam-Level: *** X-MD-Virus-Found: No Blogger does not accept multipart/signed files. Error code: 7.552C93 Original message: From: [EMAIL PROTECTED] Date: Mon, 23 Oct 2006 23:35:35 +0100 Subject: Re: Need help explaining in-addr.arpa to Limelight None signature.asc Description: OpenPGP digital signature
Re: IPv6 PI block is announced - update your filters 2620:0000::/23
Stephen Sprunk wrote: Thus spake Jeroen Massar [EMAIL PROTECTED] 8- IPv6 Assignment Blocks CIDR Block 2620::/23 -8 Expect blocks in between /40 and /48 there. Expect mostly /48s and /44s, given that ARIN has not defined any criteria for what justifies more than a /48. The first three are already available: 2620::/48 - U.S. Securities Exchange Commission 2620:0:10:/48 - S. D. Warren Services Co. 2620:0:20:/48 - CollabNet These have been added to GRH (http://www.sixxs.net/tools/grh/) now lets see how long it takes for them to show up in the global tables and how far their reach will be. Hallway talk: one of them was requested 6 sept, answer on the same day that it will be issued, received on 13 sept, nice work there ARIN :) Of course, some folks will announce a /44 instead since the block is reserved, but it should still only be one route. That it is reserved as a /44 doesn't mean one can announce that /48 as it is not assigned to them. Still, even if every org that qualified for an assignment today got one, you're still only looking at a couple tens of thousands of routes max. ARIN using a /23 for PIv6 is either serious overkill or we'll never need to allocate another block at work. The /23 is a good thing indeed, people won't most likely have to ever update their filters for that one. [..] IMHO, BGP will fall over and die long before we get to that many ASNs. I guess that will indeed be the case. Remember, the goal in giving people really big v6 blocks, vs. IPv4-style multiple allocations/assignments, is to reduce the necessary number of routes to (roughly) the number of ASNs. But people require Traffic Engineering, as such they might want to do some routing tricks and thus split up their /48. Only the future will tell. If PIv6 folks start announcing absurd numbers of routes within their allocation, I'd expect ISPs to start filtering everything longer than /48 -- if they don't do so from the start. Most ISP's already do this now. In effect /19 - /48 is unfiltered in most places. Greets, Jeroen PS: Anybody knows when ARIN will finally learn CIDR? :) 8--- $ whois -h whois.arin.net 2620::/48 CIDR queries are not accepted No match found for 2620::/48. 8 They clearly understand it is CIDR and the resulting record even has a CIDR field; they really should move to the RPSL based db that RIPE provides. signature.asc Description: OpenPGP digital signature
IPv6 PI block is announced - update your filters 2620:0000::/23
It's update your IPv6 filters time: http://www.arin.net/reference/ip_blocks.html 8- IPv6 Assignment Blocks CIDR Block 2620::/23 -8 Expect blocks in between /40 and /48 there. That is enough space for best-case 2^(40-23) = 131.072 routes, worst case 2^(48-23) = 33.554.432 extra routes in your routing table, I hope Vendor C can handle it by the time that happens. In order words: better start saving up those bonus points, you will be buying quite a lot of new gear if this ever comes off the ground ;) Most likely case is a bit more optimistic if one takes /44's: 2.097.152 Still a lot more than the IPv4 routing table is now. It will take time, and possibly a lot, but it could just happen... On NANOG Roland Dobbins wrote: [..sarcasm mode..] turning every host on the network into a router via a Shim-6-like mechanism isn't, either If you would follow shim6 then you would notice that there is also an option for doing it side-wide. But I guess Vendor C doesn't like that option as then they can't sell bigger fatter routers ;) (can you imagine help-desks who can barely cope with basic Windows issues trying to support Shim-6, heh?). Ever tried to ask a help-desk if they knew what IPv4, BGP, ASN or any other simple term was? ;) Most times they don't even know what 'traceroute' means. [..] Vendors, network operators and those participating in standards bodies must understand the seriousness of these issues for customers and work to address them (pardon the pun, heh). Indeed a certain Vendor C should really start working on fixing a lot of bugs quickly. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: NNTP feed.
John van Oppen wrote: we don't run one either... :) The last person I know who was running one, was in the proccess of killing it. Apparently you found some people killing it off, while there are actually companies who specialize in NNTP access. It seems that for mysterious reasons which the RIAA and other such organizations apparently don't seem to understand that these companies are also causing quite a lot of traffic to be shifted over the internet. Peeking at for instance http://www.nextfeed.nl/ reveals that there is one ISP having 40 days retention which apparently maps to 6*50 TB (that is 300 Terabytes indeed) of storage space, while there are also another having 50 days of retention, most likely mapping to somewhat like 400 Tb. On average they seem to be shifting in the vicinity of 15Tb/day though, looking at the number 14 of the top1000.org list. For hardware freaks it of course gives some nice things like the dutch newszilla installation: http://wa.ter.net/gallery2/images/newszilla That single setup already makes quite some small hosting companies drool out of both corners ;) Networking freaks will love the Core Juniper 640 handles newszilla traffic comment grin Otherwise said: if you are setting up a full-nntp-feed capable box, you'll have to dig nice and deep into that money bag but on the other hand there seems to be loads of people doing a lot of posting and reading, where else would the volume of that traffic come from? For the people trying to find peers, check: http://www.usenet.com/peering/peeringpage.cfm and of course also: http://www.top1000.org/ where even google pops up in a 4th place. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Fwd: Blogger post failed
On Mon, 2006-08-14 at 12:31 -0400, Derek J. Balling wrote: Who forwards NANOG posts to a blogger gateway? You, me, and a claw-hammer need to have a chat. Can I join in the fun? I'll bring some tubing along, Sin City style ;) Begin forwarded message: Blogger does not accept multipart/signed files. I've also mailed [EMAIL PROTECTED] about this, like two weeks ago, but I guess they are on holidays or they don't accept multipart/signed messages I guess ;) Next to the fact that it is nearly impossible to find the culprit as the stupid blogger crap doesn't list the path over which they actually received the message. Apparently other lists have had similar issues before: http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020911.html Longer, partially german version: http://www.fabiankeil.de/blog-surrogat/2006/05/23/blogger.com-netz-terroristen-teil-2.html or short: blogger.com can't care less, there seem to be a lot more of these cases when simply googling for [EMAIL PROTECTED], simply checking for people subscribed from @blogger.com might help to find the culprit though. Other routine would be to send a signed message to every single subscriber, maybe starting from the newest subscribers down and see which one pongs back with this crap. Greets, Jeroen PS: the mailto:[EMAIL PROTECTED] link on: http://www.nanog.org/listadmins.html is broken as it has mailto://[EMAIL PROTECTED], which should be without the slashes. signature.asc Description: This is a digitally signed message part
Re: ISP wants to stop outgoing web based spam
On Wed, 2006-08-09 at 06:11 -0700, Michael K. Smith - Adhost wrote: [..] My answer is based on the word startup so I'm assuming no money but I could be wrong. :-) We use the standard SpamAssassin, ClamAV setup both on ingress and egress. Currently the trend seems to be to send images containing the advert. Though there is a OCR plugin for SA, it doesn't seem to be very effective as one can rotate the text by 1% or use a silly font or some colors to easily evade it. Anybody has a better plugin to solve that part? Greets, Jeroen signature.asc Description: This is a digitally signed message part
RE: ISP wants to stop outgoing web based spam
On Wed, 2006-08-09 at 09:50 -0400, Mills, Charles wrote: I think if such a thing would exist, the verification gifs to prevent automated free yahoo and hotmail account signups would be defeated as well. You mean Captcha (http://en.wikipedia.org/wiki/Captcha) Which is not so much of an issue: http://sam.zoy.org/pwntcha/ Otherwise simply setup a resource that people want to access (always the best example on the internet: a pr0n site) and present the image there and let them answer it for you ;) Hmm maybe I should look into hooking pwntcha into SA. Greets, Jeroen (who now will receive another [EMAIL PROTECTED] response that it doesn't understand multipart/signed messages can some nanog-list-admin remove that crappy thing?) signature.asc Description: This is a digitally signed message part
Re: small group seeks european IPv6 sceptic for good time
On Fri, 2006-08-04 at 14:48 -0400, Todd Underwood wrote: folx, along with several others i've been putting together a panel for ripe/nanog about ipv6. the core contention is that there is a large, unrepresented body of operators who are sceptical as to the need for IPv6, see no market demand, see no problem it solves and see no justification for the cost. You might want to post this question to: http://lists.cluenet.de/mailman/listinfo/ipv6-ops But I guess that folks over there mostly already operate fully dualstacked networks thus won't fall in the sceptics part. The only 'sceptics' I know of are the people who: - have enough address space - don't want the hassle of learning something new - have enough clientele that can't go anywhere else - don't have nor won't get the funding to get it going The other part of the sceptics are the folks who don't like the current IPv6 multihoming situation, which is an understandable fact. balancing that is the belief that address space will be exhausted and that we need a replacement for v4. mediating the two of those is the desire to have a scalable routing system (which many people think means separating identity and location). That id/loc part actually sounds like a great solution to me... it in general doesn't sound like a great solution to ISP's who want to keep a hold on their customers though. so, the panel for nanog has already been submitted. i was hoping to do one at RIPE, too, but some of the panelists can't make it and many at RIPE took umbrage at the north americanness of all of the participants on the panel. so i come here looking for suggestions for the following: --someone rabidly pro v6 (european or not, preferably a network operator). this would make a nice addition to the panel for nanog I've forwarded this to somebody who will be in at least the US during the next NANOG, see the other mail. For a RIPE meeting just mail the above referenced IPv6 ops list and you should get a large number of replies. This is the easy part. --someone cold-heartedly anti-v6 who is a european operator Unfortunately I don't know anybody that qualifies in this category. Most European ISP's have already seen the light fortunately :) Enjoy the hunt. You could of course let the sceptics form in a US group and the pro folks in a European group and let them fight it out. Which can also be quite entertaining I guess. Btw, don't forget to announce on the list when these fights will take place and where to watch the stream for the folks who can't attend as it should be better than your average wrestling match grin suggestions welcome in private mail (i don't think that the panel is of operational significance, although the lack of market demand for anything like v6 may be). Afaik, the reasons for Lack Of Demand for IPv6 consists of: - No _accepted_ Multihoming Solution (BGP, shim6, etc) - there is enough IPv4 address space available, at least for parties they are talking to. - chicken egg: No Content - No Connectivity (*) - no direct revenue and payback thus hard to sell to management aka no real business case can be made - corporate businesses don't move too much yet (though it is looking a lot like some bigger corps are finally getting of their butts) - no funding to get the transition implemented - misaligned upgrade cycles, thus hardware not supporting it - not enough manpower/resources - already overloaded with too much other _real_ work to do - router vendors which are far from ready yet (I have nice stories about most of them, especially F recently ;) - believe that it will break their network it's also a FUD thing in parts. It would be really good indeed to know _why_ certain operators choose not to deploy IPv6 yet, or if they are, when and their reasoning for delaying it. Greets, Jeroen * = not even joking, but could somebody set up a free IPv6 p0rn service; that should considerably raise the demand for IPv6 around the globe. I have some nice statistics from users from a certain asian ISP who are looking at some cosy pictures quite often, most likely using IPv6 as the content is blocked over IPv4 as The Great Firewall doesn't support the new protocol yet ;) signature.asc Description: This is a digitally signed message part
Re: small group seeks european IPv6 sceptic for good time
On Fri, 2006-08-04 at 13:42 -0700, David Conrad wrote: Afaik, the reasons for Lack Of Demand for IPv6 consists of: [...] - Unwillingness of enterprise operators to pay the cost of migrating while remaining under the you must renumber if you change providers rule. Ack, this falls IMHO under: - No _accepted_ Multihoming Solution (BGP, shim6, etc) The other reasons I listed are quite moot in most cases btw, the one above is really the only important one that is really a showstopper for most people. ohno, not again a long discussion about this, to make sure that won't happen; I invite folks to do that fighting part on Wikipedia: http://en.wikipedia.org/wiki/Multihoming Edit and push comments in the Talk box where needed. That should make it an easy place to find the pro's/con's of methods available and also clearly index this. Don't vandalize boys and girls ;) Greets, Jeroen (Who will now again get a bounce from [EMAIL PROTECTED] cause I am so nice to pgp sign my messages...) signature.asc Description: This is a digitally signed message part
Re: [address-policy-wg] 91.192/10 to be used for PI assignments to End Users
On Mon, 2006-07-10 at 13:50 +0200, leo vegoda wrote: Dear Colleagues, At recent RIPE Meetings, we have reported a steady rise in requests from our members for Provider Independent (PI) address space for End User networks. Any link to the slides which might contain the expected increase for the coming years? Especially the estimated number of routes that will newly be announced using BGP because of this would be something nice to see. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Best practices inquiry: tracking SSH host keys
On 6/28/06, Phillip Vandry [EMAIL PROTECTED] wrote: SSH implements neither a CA hierarchy (like X.509 certificates) nor a web of trust (like PGP) so you are left checking the validity of host keys yourself. Still, it's not so bad if you only connect to a small handful of well known servers. You will either have verified them all soon enough and not be bothered with it anymore, or system administrators will maintain a global known_hosts file that lists all the correct ones. The answer to your question: RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints http://www.ietf.org/rfc/rfc4255.txt You will only need to stuff the FP's into SSHFP DNS RR's and turn on verification for these records on the clients. Done. In combo with DNSSEC this is a (afaik ;) 100% secure way to at least get the finger prints right. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
On Wed, 2006-06-07 at 11:01 -0700, Josh Karlin wrote: Check out the IAR for Potential Prefix Hijacks and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. I don't know how long the routes were announced, but they seem to be gone now. Or maybe the IAR is horribly broken, in which case I will be lynched :) You are the broken part, due to the mere simple fact that you accept those routes. That your uplinks are accepting them also means that you are not paying them enough so that they don't accept them either. But in ARIN land you have an excuse, more or less, as there is not a real 'good' routing database. In RIPE land we at least have route+route6 objects in the RIPE database where one can filter on, but that is only for RIPE. A sane and complete routing information database would already considerably help here. RADB is nice but does not help much to make the info complete. Also anybody can then still announce the prefix with the correct source ASN and other nasty tricks. In the end, the complete solution to most of these issues will be in the form of S-BGP (http://www.ir.bbn.com/sbgp/) and similar solutions. And the IETF is fortunately working on this: http://www.ietf.org/html.charters/sidr-charter.html It might take some time still, but it will come one day and then these issues are gone. At the moment you'll just have to trust your peers and try to get them to implement a sane policy on what kind of announcements they accept or not. Greets, Jeroen signature.asc Description: This is a digitally signed message part
ipv6 @ sprint, somebody home?
[EMAIL PROTECTED]: host kay.sprintlink.net[199.0.233.8] said: 553 5.3.0 [EMAIL PROTECTED]... User Unknown (in reply to RCPT TO command) It's must be 6/6/6 that it ain't working. I guess they are scared that IPv6 might scare their fisherprice routers ;) Anybody a *working* contact so that they can also be nicely reminded of the fact that the 6bone has come to an end and that they should nicely ask their paying customers to stop announcing 6bone space? http://www.sixxs.net/tools/grh/lg/?=prefixfind=3ffe::/16 And http://www.sprintv6.net/ doesn't contain any contact info before you say google it. Then again the following url clearly shows their 'interrest' http://www.sprintv6.net/aspath/bgp-page-complete.html Last change on the tree detected on Sun DEC 11 2005, h.22:50 Fisherprice, fisherprice /sarcastic mode Greets, Jeroen -- Just in case, yes [EMAIL PROTECTED] is whois 3ffe:2900::/24 : ipv6-site:SPRINT origin: AS6175 descr:SprintLink 6bone Reston, VA, US country: US prefix: 3FFE:2900::/24 ... contact: RJR2-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: [EMAIL PROTECTED] changed: [EMAIL PROTECTED] 20010117 changed: [EMAIL PROTECTED] 20010423 changed: [EMAIL PROTECTED] 20020925 source: 6BONE And no I am not mailing their ipv6-support addy which doesn't respond ;) PS: Happy Slayer Day: http://www.nationaldayofslayer.org !!! signature.asc Description: This is a digitally signed message part
[OT] Re: Troubles with HE's Tunnelbroker
On Tue, 2006-05-16 at 18:42 -0400, Dan Mahoney, System Admin wrote: I know at least some people here (srs?) use HE.net's tunnelbroker service. Has anyone else been experiencing issues? I have three different tunnels that I've noticed are down (to various data centers), and calling their support department (and emailing) thusfar have proved to be less than helpful. extremely shameless plug http://www.sixxs.net/pops/occaid/ /extremely shameless plug Greets, Jeroen signature.asc Description: This is a digitally signed message part
RIPE IP Anti-Spoofing Task Force (Was: private ip addresses from ISP)
On Wed, 2006-05-17 at 15:14 +0100, Ivan Groenewald wrote: [..] If you mean you are getting traffic destined for RFC1918 space, then make sure you aren't announcing those networks to your upstreams by accident. Poor upstream configs/filters could allow stuff like that to escape to peers of the upstream. (stranger things have happened) [..] On a related note, RIPE has started an IP Anti-Spoofing Task Force, see http://www.ripe.net/ripe/tf/anti-spoofing/ for more information. Greets, Jeroen -- RIPE IP Anti-Spoofing Task Force == IP source address spoofing is the practice of originating IP datagrams with source addresses other than those assigned to the host of origin. In simple words the host pretends to be some other host. This can be exploited in various ways, most notably to execute DoS amplification attacks which cause an amplifier host to send traffic to the spoofed address. There are many recommendations to prevent IP spoofing by ingress filtering, e.g. checking source addresses of IP datagrams close to the network edge. At RIPE-52 in Istanbul RIPE has established a task force that promotes deployment of ingress filtering at the network edge by raising awareness and provide indirect incentives for deployment. Document ripe-379 provides the task force charter and the initial time-line. The mailing list archive is at http://www.ripe.net/ripe/maillists/archives/spoofing-tf/2006/index.html The task force web page is at http://www.ripe.net/ripe/tf/anti-spoofing/ The task force is co-chaired by Nina Hjorth Bargisen (NINA1-RIPE) and Daniel Karrenberg (DK58). signature.asc Description: This is a digitally signed message part
Re: [Way OT] Re: Geo location to IP mapping
On Wed, 2006-05-17 at 08:09 -1000, Scott Weeks wrote: - Original Message Follows - From: Jeff Rosowski [EMAIL PROTECTED] I just tried that, says I'm 100 miles south of where I really am. That's quite a long way out in a small country like England. Only 100 miles? I entered the address of a box I have in Virginia, and it says it's in California. Well at least it got the country right. One of the geolocation thingies said my addresses were in Amsterdam. That's only 10,000 miles from Hawaii. 2500 miles more and that's exactly the opposite side of the planet... ;-) Try http://www.hostip.info it is reasonable accurate in most cases and hell it is for free. It depends what you need it for of course but it is far better than nothing. 64.29.76.9, your mauigateway.com pops up correctly as Honolulu. 205.166.249.10 is guessed to be somewhere random in the US. The problem with this one is that they are still gathering data and they depend on user input, but it looks pretty accurate to what I have found out. Most of these kind of databases rely on user input though. I am quite sure that Google, using their search thing and especially Orkut has quite some info on this. Shopping Sites like Ebay and Amazon of course get their shipping info for free and thus can pretty much pinpoint the city correctly after $x percentage of customers bought from there. Problem in the end is of course when there is a huge pool and the end-users change a lot, but then the country is accurate enough already. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: IPv6 Transit?
On Mon, 2006-04-10 at 16:25 +0100, Mat Sharpe wrote: Hi, Does anyone have any info on IPv6 deployment at the Tier-1 / Tier-1.5 level? We are multi-homed to both Level3 and Abovenet in the UK and Level3 only in the US. The big question with IPv6, from a provider perspective, is of course: what kind of address space do you have and if none what kind do you require. Or otherwise put: how do you want to 'multihome' (oh not that discussion again ;) Level3 did have a promising sounding beta program last year but that seems to have stalled. Abovenet apparently have no schedule to deploy v6 at the moment. I haven't seen a connection request from Level3 towards GRH yet, thus I think it is indeed mostly non-existent (correct me if I am wrong ;). I do hope for them they resolve that sooner or later though. I would like to be able to v6 enable our network but without a transit provider that’s going to prove a bit tricky. Try to get native connectivity where possible, when not, you can always throw a tunnel to the upstream. Do try to keep your tunnel to match up with your existing infrastructure as closely as possible. Also see http://ip6.de.easynet.net/ipv6-minimum-peering.txt for more details on that subject. Doc is already becoming of age but works pretty well. Next to that you might want to check out a list like: http://lists.cluenet.de/mailman/listinfo/ipv6-ops which contains a good deal of of the global IPv6 operational folks, usually nice and quiet but when you yell you will get an answer. Any thoughts appreciated! Check for yourself, who has at least some connectivity and what kind of routes they are carrying, which can tell things about the connectivity they provide by looking at GRH: http://www.sixxs.net/tools/grh/ I know that a number of folks at least had good experiences with amongst others (alpha order): Cable Wireless (1273), Easynet (4589), Global Crossing (3549), NTT (2914), Sprint (6175), Tiscali (3257), UPC/Aorta (6830), Verio (2914). Most of these you can see and checkup in GRH. Of course real-life experience can only be told by the folks actually buying their services also a lot depends on where one is located. P.S. I hope I’m not about to re-start the who is/is not a Tier-1 / Tier-2 argument! :) Just tie them together into the Internet and all is fine ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On Sat, 2006-03-25 at 13:30 +0100, JP Velders wrote: [..] This isn't about processes, it's about something that has been around for a while, many reply on and keeps *** up. Where it simply can't. What world do you live in were everything is done perfect ? If you don't like sendmail because of its history or that it can contains flaws, vote with your feet and choose something that you do think can be trusted to do a better job, is more secure, is more actively developed and is developed more securely then sendmail. [*] Indeed, and it is is not like there are no alternatives and of course one can always roll it's own ;) And one even didn't have to pay for it, but complaining, and not helping out by providing patches or research is always the easy way out. /me chose postfix btw, but mostly also because the config is much simpler ;) Rolling my own would also be an option, the ones out there work fine already and so what that they have bugs, no way that one can code bugfree, just make sure that you can upgrade in time. Heck, if I were to have kids one day and would like them to get to school safely by car, I'd like to have something short of a tank to be absolutely certain. Instead I'll probably make them aware of the risks, give them good protection and bicyle helmets... Now if I were a head of state or something, I'd probably have people to get me that tank... Note the have people... I guess you mean something like a 400.000 EUR tractor (vendor-C term): http://www.planet.nl/planet/show/id=1740280/contentid=620223/sc=aa2928 The thing is, that might help for the collision case or a small bomb, but one can still walk up to the guy when he gets out and shoot him directly in the head or try to cut it off as has been demonstrated twice before in that country. Bit futile thus to protect yourself with such spendings when it doesn't cover the obvious cases. Analogous, starting over using a new product might introduce other security risks and of course never forget the migration path which in larger installs includes training and upgrades, problem shooting and then finding out that new bugs exist in the new code. Even the folks who moved over from SSH.com to OpenSSH have found out that they had to upgrade a large number of times, some times even with very troublesome vulnerabilities, in the end causing most people to rate-limit port 22 or to move it to another port altogether because of the automated scanning happening. Greets, Jeroen (Fortunately it was not my tax money that bought that tractor :) signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
[Pekka, thanks for the Shim6 Summary paper ;) ] On Wed, 2006-03-01 at 14:58 -0800, Owen DeLong wrote: Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Vaporware part is true, upto now, operational value is to be seen. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Greets, Jeroen (who simply would like a policy where endsites that want it could request a /48 or /40 depending on requirements from a dedicated block which one day might be used for identity purposes and not pop up in the bgp tables or whatever we have then anymore) I would, for one. Policy proposal 2005-1 (I am the author) comes reasonably close to that. It will be discussed at the ARIN policy meeting in Montreal in April. Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing address space now while being able to use it differently later when it is needed. Though as Joe Abley also mentioned (and I also quite a number of times already ;) anyone with even a vague definition of a plan for 200 customers can get a /32 IPv6 without a problem. Just check the GRH list for companies in your neighbourhood who did get it. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote: Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Yes, I am well aware of 32bit ASNs. However, some things to consider: 1.Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. True. If we would take the 170k routes that are in BGP at the moment then a 18bits address space is enough to give every route a dedicated ASN. The issue is that there are way more people who might want to multihome than that, just take the number of businesses on this planet, add some future growth and we'll end up using the 24th bit too quite quickly. Which is, according to some people who do routing code, no problem at all. Like shim6, see first then believe. 2.In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. Paper/draft/description/website? :) Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing address space now while being able to use it differently later when it is needed. Though as Joe Abley also mentioned (and I also quite a number of times already ;) anyone with even a vague definition of a plan for 200 customers can get a /32 IPv6 without a problem. Just check the GRH list for companies in your neighbourhood who did get it. True, but, until recently, I was being told that ARIN insisted that the 200 customers had to be non-related third parties. E.g. Chevron couldn't use all their different business units as 200 customers of Chevron Corporate IT. It appears based on some recent allocations that they may have relaxed that stance. It might have been that ARIN was a bit stricter, the other RIR's though have never given any real problems as far as I know. The few ones that I heared of that couldn't get it, either didn't try or didn't want to lie about their plans. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
On Wed, 2006-03-01 at 09:05 -0800, David Barak wrote: [..] Is it easier to scale N routers, or scale 1*N hosts? If we simply moved to an everyone with an ASN gets a /32 model, we'd have about 30,000 /32s. It would be a really long time before we had as many routes in the table as we do today, let alone the umpteen-bazillion routes which scare everyone so badly. Today indeed, but you are missing the point that IPv6 should last for the couple of next decennia. In IPv4 the starters also got a nice /8 as a bonus and the result: new small entities complaining that the first ones got the cool stuff and they can't have any. You might have noticed the 32-bit ASN talk. This is there for a reason: ASN's will go to 32bit mode. Can you say 4 million routes? :) Simple isn't always good. The KISS principle doesn't always work... The current 30k in-use ASN's (afaik they are even less) will and can explode when that means you can get easy address space. Btw, this is policy talk, you might want to bring that to ARIN PPML or the various other lists. If you want to propose a PI policy, then please make a decent proposal and send the relevant RIR group. That endsites require PI is inevitable, but the way those routes end up in the routing tables and the amount of address space each endsite is getting should be relevant to need, not to the fact that you got an ASN. (Which would mean I would qualify for 2x /32's... which is very silly as the couple of /48's I use is way more than enough. Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. Greets, Jeroen (who simply would like a policy where endsites that want it could request a /48 or /40 depending on requirements from a dedicated block which one day might be used for identity purposes and not pop up in the bgp tables or whatever we have then anymore) signature.asc Description: This is a digitally signed message part
