Re: IPv4 address length technical design
On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote: IEEE 802 was expected to provide unique numbers for all computers ever built. Internet was expected to provide unique numbers for all computers actively on the network. Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. Which brings the question, are we expected to ever run out of the 48 bits for mac-addresses? Of course there are exceptions, but in most cases you can probably start recycling them after a certain period. And that period could even become shorter over time, I mean what are the chances you find a iPhone 1 in your network these days? Marco
Re: Trouble with IPv6 setup on Quagga
I am having trouble with Quagga in setting up IPv6 BGP. So far it was failing with external providers. Just now I gave it a try to setup BGP session (IPv6 only) within our ASN between two routers. From our other end router I see there is no acconcement, while I see blocks being announced via Quagga. Also strange enough is that the number of blocks I account - they all come as withdrawl routes on other router as soon as Quagga is turned on. I recall some issues with the value of the next-hop in the BGP messages in the past. Haven't been around Quagga in recent times, don't know if this is still the case. If possible you might want to catch a BGP packet with tcpdump and verify the value in there makes sense to the other side. Got bitten by this before and took me ages to figure out the other side was dropping my updates because the next-hop couldn't be resolved. Marco
IPv6 CPE Survey - Initial Results on RIPE Labs
[apologies for duplicates] Dear colleagues, Since we published the IPv6 customer premise equipment (CPE) survey during the RIPE 62 meeting, we received more than 100 responses. This new article on RIPE Labs shows some interesting initial results: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-results-may-2011 The survey is still open. If you are using an IPv6 capable CPE and have not yet filled in the survey, we would like to encourage you to do so. The survey can be found here: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate Kind Regards, Marco Hogewoning Mirjam Kuehne RIPE NCC
New IPv6 survey released on labs.ripe.net
Hi There, We just released a new version of the IPv6 CPE survey. After lots of feedback on the previous editions, we are now doing a proper survey. Based on the responses we receive in this survey we will be able to compile a new edition of our matrix and provide some more statistical background on what is happening in the market. Remember we are totally depending on your feedback to continue this work. The more responses we receive, the easier it gets for us to provide regular updates on which CPE are available on the market and how good they are. So if you have an IPv6 capable router or modem in your house, or you are busy testing them. Please take the time to fill out the survey and help other people to find the device that fits their need. Please see https://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate for further details and a link to the survey. Thanks, MarcoH
Re: PPPOE vs DHCP - RIPE Database
On Jan 27, 2011, at 8:03 PM, Peter Dambier wrote: Hi, I have not seen this in the discussion yet. http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 CPE support does not seem to be very broad yet. As far as I can see there is almost PPPoE only for IPv6 in Europe. As long as there is an ADSL interface they usually support both, goes for major vendors as well as some smaller ones. In Germany cable is a mess by regulation. So no cable/dhcp. There used to be a DTAG monopoly with aDSL only and PPPoE only. Most ISPs still rely on the DTAG infrastructure. That is why very PPPoE biased. There is a high concentration of AVM in the CPE with Infineon chipsets in both DSLAM and DSL-Modem / Router Part of the DTAG modems seem to be 7570 based and for what I have been told by German friends these can be flashed to the standard production releases. Not of much use for native, but you will get tunnel support in the box. Marco
Re: IPv6: numbering of point-to-point-links
While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. I personally don't any benefit in using /126 subnets. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. Grtx, Marco
Re: Low end, cool CPE.
On 12 nov 2010, at 02:41, Leo Bicknell wrote: I've run into a number of low end CPE situations lately where I haven't found anything that does what I want, but I have to believe it is out there. I'm hoping NANOG can help. snip What is the state of the art, and who has it? shameless plug Have a look at http://labs.ripe.net/Members/mirjam/ipv6-cpe-surveys/ if you want some pointers on IPv6 support. As always feedback is more than welcome, I'll try and publish a new one in a few weeks. /shameless plug Frank Bulk maintains something similiair on the arin wiki at http://www.getipv6.info/index.php/Broadband_CPE MarcoH
Re: Low end, cool CPE.
All of this on a $70 box, with a very fast CPU, and 5 GigE ports. Currently playing with a little ADSL box made by Gennet (Athens, Greece). They have a beta which includes v6 support. Still some work to do but it looks very promising and the basics work (PPP dual stack, dhcpv6 PD, DNS). Firewall is under development and they have a nasty bug in the wlan driver which needs fixing so it's supports v6. http://broadband.gennetsa.com/oxygen_router.html Groet, MarcoH
Re: end-user ipv6 deployment and concerns about privacy
On 18 aug 2010, at 09:35, Hannes Frederic Sowa wrote: On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning mar...@marcoh.net wrote: On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote: prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A What does facebook have to do with it ? Ever heard of cookies ? Facebook as an example of a company whose founder stated that privacy is old-fashioned. Cookies sit on another network-layer I am currently not talking about. They can be removed more easily, most simply by reinstalling your computer. The user *can* do something about cookies. Yeah but given the amount of NAT and dynamic addresses around in v4 land. I think it's highly unlikely you are better of tracking v4 addresses instead of pushing cookies, especially as most 2.0 sites require a login anyway. Groet, MarcoH
Re: end-user ipv6 deployment and concerns about privacy
On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote: prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A What does facebook have to do with it ? Ever heard of cookies ? MarcoH
Re: BCP38 exceptions for RFC1918 space
On 15 aug 2010, at 20:05, Randy Bush wrote: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) and this is a good thing? rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. I cannot agree more with this. If you want PMTU use non-private space, there is enough really :) And saving a /24 by renumbering your core into RFC 1918 won't save you from the coming run out. MarcoH
Re: IPv6 Server Load Balancing - DSR
Brocade basically sucks when it comes to loadbalancing IPv6, the old serveriron platform is EOL and a complete mess which offers some IPv6 support, but not much. The new ADX platform seems to be in a pre-alfa stage at the moment. So normally I would say stand clear, however we do run a (larger) usenet platform on v6 which uses DSR and that part works on the serveriron, running a pre-relase of the 11.0.0f software. Must admit we don't do anything fancy, it's all unprotected and statically routed, ACLs are all done on the reals and on the Juniper in front of the serveriron etc. But it seems to hold, haven't heard any complains yet. But be warned this is a really specifc subset of features. For regular operations like web we still have loads and loads of issues. Basically the other choice is F5. We are busy setting up a PoC with A10, who claim IPv6 support. Hopefully in a few weeks time they can be added to the list of potential suppliers. Other then these two I haven't come across any dedicated stuff and what's left is Linux/BSD based solutions. MarcoH
Re: Addressing plan exercise for our IPv6 course
On 23 jul 2010, at 01:33, Matthew Walster wrote: On 22 July 2010 14:11, Alex Band al...@ripe.net wrote: There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing. /64 is too small, especially when sensornetworks take off you probably want multple ranges. In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one. Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum. So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing. First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day. Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need more did the rest. So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway. So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk that I lose business because the shop across the road does offer /56 or even /48. Which brings me into the economics, we are in a hurry. We need to deploy and we need to deploy yesterday. In fact if you are not running IPv6 by now, you are too late. So I have the choice of creating a really complicated deployment scheme in which I can assign variable subnet lenghts to customers without breaking aggregation and without annoying them with renumbering. One-size-fits-all makes life easy and saves an huge pile of money and not only money but it saves time, time I need, beacuse we are already a bit late. In short, why a /48 'Because we can!'. We had about 15 years to design a proper scheme, we failed. Now we can discuss a redesign, but then we need to squeeze another 10 years out of IPv4. MarcoH
Re: Addressing plan exercise for our IPv6 course
Home wifi router vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. This will greatly help in deploying IPv6...here is another NAT because we said NATs would disappear. MarcoH
Re: Addressing plan exercise for our IPv6 course
However, even then, there is no guarantee that the common denominator CPE for this service wont have NAT66 features, maybe even turned on by default. I've tested a lot of CPE's and haven't come across one that supports NAT66, they all do support DHCPv6 prefix delegation and actually most of them require it to work as most can't bridge between the WAN and LAN on the same /64. MarcoH
Re: Addressing plan exercise for our IPv6 course
On 21 jul 2010, at 19:22, Simon Perreault wrote: On 2010-07-21 12:57, Alex Band wrote: We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ I'm curious to hear if you think it's clear and useful. Useful, yes. But it should be clearer that not all address plans are equally good. It's not just a matter of filling in the blanks with something that will work. Every address plan will turn out to be a custom job anyway. Primary goal of this exercise is to show the basics and to show how you can get a lot of aggregation done without wasting a lot of space. Making people familiar with the way subnets are split up and the very basics of counting to 16. I'm also working on a more extensive half day workshop which contains a lot more scenarios and for instance show how to fit this same network into a /48 PI assignment instead of the /32 PA. If you are bored with this one already, go ahead and try :) For instance, would one be expected to follow RFC 3531? For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. As far as customer assignments is concerned, I would simply stick to the /48 and not make any reservation for future growth beyond that, i should probably cater for 99% of your cases and if they really run out I can probably handle a second assignment/route for another one (or leave them the choice to renumber into a /47). In fact part of this exercise is meant to teach people how to avoid such disasters as running 'out of space' by being really inefficient. The only way where I see this becoming relevant is when trying to make subassignments from a /48. But as far as PI is concerned, and that would be the most likely case, in RIPE region you are not allowed to make subassignments from within a PI block. The other one would be subassignments from a PA block, which under the same policy can easily be made a few bits bigger and if I would encounter a customer who would actually subassign large numbers of customers from within a PA assignment. I would recommend becoming an LIR themselves and get a /32. MarcoH
Re: v6 bgp peer costs?
On 21 jul 2010, at 21:08, Zaid Ali wrote: I currently have a v4 BGP session with AS 701 and recently requested a v6 BGP session to which I was told a tunnel session will be provided (Same circuit would be better but whatever!). Towards the final stage in discussions I was told that it will cost $1500. I find this quite ridiculous and it will certainly not motivate people to move to v6 if providers put a direct price tag on it. I am going through a bandwidth reseller though so I am not sure who is trying to jack me here. Has anyone here gone through a similar experience? I think the main question here would be, what they would charge for a change to a v4 session. Most likely they just decided that setting up the tunnel and configuring BGP takes time and since time is money they decided to charge for you. Seems like a reasonabe rule of business, why should it be free ? At the same time, the same set of economics will probably find you somebody who will do this for less and maybe even is happy to take your business and setup v4/v6 dual stack for free. So get a quote from a competitor, call back 701 and offer them the choice of setting up the tunnel or loose a customer. My personal preference would be to leave and find somebody who can do native all the way. MarcoH
Re: Addressing plan exercise for our IPv6 course
On 21 jul 2010, at 21:50, Simon Perreault wrote: On 2010-07-21 14:47, Marco Hogewoning wrote: For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. Not disagreeing, but here's a tool to make it easier: http://www.ipv6book.ca/allocation.html Nice tool but they just learn a trick instead of understanding what is going on. Anyway, left or right there is this huge lack of knowledge and a maximum of 12 months to fix it. So whatever gets it going. MarcoH
Re: IPv6 consumer perception
On 18 jun 2010, at 18:04, Zed Usser wrote: With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems. http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent-100617/ It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed. The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off. Why do people still think consumers 'want IPv6', they want IPv6 as much as they want IPv4. They don't know what an IP addresses is, let alone will grasp the whole idea there are 2 kinds. All they want is their googles, facebooks, twitters and the occasional download to work (of course nobody would admit to filesharing). And it's our job to make it so, wether it's via IPv6 or CGN. In the end they won't have much choice and if we do our jobs correctly, 95 % of them won't even notice. Just my 2 cents, MarcoH
Re: Home CPE choice
On 1 apr 2010, at 02:04, Nick Hilliard wrote: On 31/03/2010 23:55, Charles N Wyble wrote: What good off the shelf solutions are out there? Should one buy the high end d-link/linksys/netgear products? I've had bad experiences with those (netgear in particular). Some people have said that the Fritz!box is quite good. No idea if it's approved for use in the US. They have a very rich VoIP implementation and are really good for the less technical user. But for more eloborate setups they are a bit rigid, telnet to the box and you void warranty etc. Got a few hundred thousand in the field and most people seem to be happy with them. A limited set of IPv6 features is available in beta for some models, very basic interface to support various flavours of native connectios and tunnels. Small firewall interface to punch some pinholes (bit buggy still, being worked on). Enough for your average connection demands. As far as I know they aren't certified for US. Most of the boxes come with ISDN (the have german origins) and DECT base station, so next to the regular WiFi there is a lot of other stuff that needs changing an certification for the US market. My guess however is that those things are primairly driven by demand and if you order a truckload things can be fixed. At home I run cisco, but I guess that's due to my background. It's stable, flexible and I'm used to the interface. From a consumer perspective I'm really impressed by the latest Draytek Vigor (2130n). Pretty amazing RG which has a rich and easy to use future set and has a full and working IPv6 box on board. Unfortunately this doesn't include a VoIP client or DSL interface, both are being worked on I was told. It's build around a linux stack so everything is there: routing, firewalling. Mostly via the webinterface some only via cli (ssh/telnet). SNMP is included. For the DSL there is a workaround using the Vigor 120 box, which can tie DSL to ethernet and even is able to translate PPPoA into PPPoE. With the latest firmware it can also handle IPv6 on those PPP sessions. And since it's standard PPPoE out of the back it's also an easy fix for other RGs. Tested it yesterday together with an airport express and worked perfectly. Only problem I found was the airport seems to lack IPv6 support on it's PPPoE stack, which I was testing for. Enough for the plugging of the vendors :) Shameless plug for myself: I'm compiling a list of IPv6 ready CPE to be presented at RIPE-60, any hints and tips on what is out there and experiences so far are welcome off list. I'm about to send a simple questionair to known vendors, if you happen to be a CPE manufacturer and want to be included please contact me. Thansk, MarcoH
Re: IP4 Space
1.Why don't providers use /31 addresses for P2P links? This works fine per rfc 3021 but nobody seems to believe it or use it. Are there any major manufacturers out there that do not support it? 99.999% of my customers are on /32 anyway. I could probably get a handfull of addresses (/25) back by renumbering the backbone links . But this will not save the world and they will most likely be used more rapidly as I can reclaim them. MarcoH
Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN
On 24 okt 2009, at 14:36, Suresh Ramasubramanian wrote: On Sat, Oct 24, 2009 at 2:48 PM, Marco Hogewoning mar...@marcoh.net wrote: On Oct 24, 2009, at 9:00 AM, Suresh Ramasubramanian wrote: \ http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 With more on that: http://www.ripe.net/news/rbn.html I am glad this ugly situation has been resolved - and I do wish the resolution gets better coverage than this. It finally hit the press as well: http://www.pcworld.com/businesscenter/article/174651/uk_police_smooth_over_rift_with_internet_registry.html MarcoH
Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN
On Oct 24, 2009, at 9:00 AM, Suresh Ramasubramanian wrote: http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 With more on that: http://www.ripe.net/news/rbn.html Press coverage this week portrayed the RIPE NCC as being involved with the criminal network provider Russian Business Network (RBN). Any connection with criminal activity, or with RBN itself, is completely unfounded. The press coverage arose from a speech given by the Serious Organised Crime Agency (SOCA) in the UK. SOCA has since contacted the RIPE NCC with an apology. The RIPE NCC will continue to work with SOCA and other bodies to ensure criminal investigations can be carried out in an efficient manner within established laws and guidelines. MarcoH
Re: ISP customer assignments
On Oct 13, 2009, at 9:56 PM, Joe Abley wrote: On 2009-10-13, at 14:46, Matthew Petach wrote: I allocate a /64, but currently I configure only a /127 subnet on the actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). We run roughly the same, although we skip the whole globalscope address on the PPP, running localscope only works for the CPE we tested so far. MarcoH
Re: IPv6 internet broken, cogent/telia/hurricane not peering
On Oct 12, 2009, at 6:09 PM, Patrick W. Gilmore wrote: It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are big. The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status. I never thought HE would be one of those networks. Do we have any proof it's HE rejecting peering or is it that Cogent en Telia alike that are to proud to ask and think they can have a piece of the pie as they did with v4 ? MarcoH
IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering)
On Oct 12, 2009, at 9:14 PM, Jack Bates wrote: Dan White wrote: Reputation lists will just be on the /64, /56 and /48 boundaries, rather than IPv4 /32. And then people will scream because someone setup a layout that hands out /128 addresses within a /64 pool. There is that chance yes especially from access networks which use RA. As this thread has drifted off topic any way, would it for instance be a good idea to simply not accept mail from hosts that clearly use autoconfig ie reject all smtp from EUI-64 addresses. Of course not a wise idea for your own outbound relays which should handle mail from your customers but on the incoming side it might as well save a lot of headache and there is no need to keep track of which /64 are access networks. Just a few cents, MarcoH
Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering)
On Oct 12, 2009, at 9:40 PM, Jeroen Massar wrote: Marco Hogewoning wrote: [..] As this thread has drifted off topic any way, would it for instance be a good idea to simply not accept mail from hosts that clearly use autoconfig ie reject all smtp from EUI-64 addresses Can you please *NOT* suggest people *STUPID* ideas like filtering on arbitrary bits inside an address!? Thank you. I was just testing out how others feel about this... (Who indeed is not calling Marco stupid, as he is one of those people who is not stupid, he sometimes just has a wrong idea, just like me ;) Just testing the waters, the solution you suggested is more practical but you know as well as i do that there are those people out there who just filter out any inetnum object which matches *dsl* or *dhcp* which is about the same. MarcoH
Re: IPv6 internet broken, cogent/telia/hurricane not peering
Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole. You are publishing records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy. May I suggest to vote with your feet and take your business somewhere else. They obviously are not interested in you, your traffic or your money. MarcoH
Re: Does Internet Speed Vary by Season?
On Oct 7, 2009, at 6:44 AM, Hank Nussbacher wrote: http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion I'm not sure the effects are so big compared to the actual speed that they are noticable for the average user. We also don't have any proper data available but we do (operating in NL) notice from time to time that periods with loads of rain can have influence on the stabillity and speed of DSL lines especially in older areas of towns where they still have paper/lead covered cabling instead of more modern PVC isolation. This as more visible when everybody still used 56k dialup.This may as well be a very local effect, the western part of our country is largely at or even below sealevel and very wet already. However as these effects might get you a few kilobits extra from time to time that effect is not visible in overall usage statisctics, as soon as the sun comes out we see traffic levels drop to only rise again near september when everybody is back to school and the office. As far as traffic levels go, it's the rainy winter nights which make it into the recordbooks. Grtx, Marco
Re: Drop in IPv6 traffic
On 9 jul 2009, at 12:24, Mikael Lind wrote: Hi, I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 service last night and it seems to be the same on AMS-IX. Has anyone else seen the same? Any idea why? Multiple options, but it must have something todo with a free usenet service. We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I notice the drop is hours later and much bigger (se the graph at https://www.ams-ix.net/technical/stats/sflow/) . If you have trouble reaching newszilla6.xs4all.nl at port 119 please drop me a note as you might accidently got filtered and I'm happy to resolve this. From the looks of it one of our colleagues who also run a free usenet box have some issues as well, news.ipv6.eweka.nl isn't responding, which may well be the only cause of this little drop. Groet, MarcoH
Re: Drop in IPv6 traffic
Hi Patrick , On 9 jul 2009, at 16:10, Patrick W. Gilmore wrote: On Jul 9, 2009, at 9:58 AM, michiel.muhlenbau...@atratoip.net wrote: Hi Jeroen others, Yep, looks like we are doing a great portion of AMSIX's IPv6 traffic and our (free) IPv6 service was affected because of an internal error last night around 00.30 am. Michiel, Thank you for the information. Could you let us know if XS4All's free v6 news feed went to zero, or was just dropped by some percentage? Please note Michiel isn't from XS4ALL :) We (XS4ALL) did not have any outage on the usenet service, everything is still running and passing traffic. The only thing we did was adjust some filters so if you are depend on more specifics and not announcing the /32 you might have been dropped from the table around 15:00 GMT. The remaining traffic at ams-ix matches our internal graphs, so I guess I'm the only bulk sender at the moment. I ask because the AMS-IX is frequently used as an example that v6 is being heavily adopted. If it is all one source for one application, that is important information to the people fighting for v6 adoption. Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 Gbps still includes some of your traffic, it is very impressive. There are 3 open usenet servers at amsterdam that I know off: - XS4ALL (at newszilla6.xs4all.nl) - Highwinds/Eweka (news.ipv6.eweka.nl) - XSnews I think we, once again, have proof 99% of the ams-ix traffic. The remaining bit possibly is google and the traffic on this mailinglist (and ripe.net). As an exercise we could see if spikes in nanog activity can be matched to spikes in the v6 traffic :) Groet, MarcoH
Re: Checking bogon status of new address space
On May 8, 2009, at 2:44 PM, Frank Bulk wrote: Please set up a pingable IP address for each new netblock and post it to NANOG with a request to have us ping it. It's not automated, but it's a good start. Frank You might also want to have a look at the RIPE NCC's beacon stuff: http://www.ripe.net/ris/docs/beacon.html I do recall them to use this mechanism to test new iana assignments (/ 8) they got. Grtx, Marco
