From robert at ripe.net Thu Mar 5 12:30:34 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 05 Mar 2015 12:30:34 +0100 Subject: [atlas] Mistakenly sent "please register your probe" emails Message-ID: <54F83E5A.30601@ripe.net> Dear RIPE Atlas users, As part of our regular development schedule, the development team rolled out a new version of the infrastructure components yesterday. As a side-effect, due to a mistake on our end, some users received emails urging them to register their probe(s), even though this has already been done. If you got such a mail although you've done your part, then please ignore this mail. Our apologies for the confusion. Regards, Robert Kisteleki From mgalante at ripe.net Tue Mar 10 13:52:55 2015 From: mgalante at ripe.net (Michela Galante) Date: Tue, 10 Mar 2015 13:52:55 +0100 Subject: [atlas] Internet Exchange Nepal (NPIX) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called np-ktm-as45170 and it is hosted by the Internet Exchange Nepal (NPIX) in Kathmandu, Nepal, and sponsored by APNIC. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From pvlaar at afilias.info Thu Mar 12 18:31:03 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 12 Mar 2015 18:31:03 +0100 Subject: [atlas] Please set your NIC handle for your RIPE Atlas anchor In-Reply-To: <20150311115906.27384.12342@janus.atlas.ripe.net> References: <20150311115906.27384.12342@janus.atlas.ripe.net> Message-ID: <5501CD57.1090802@afilias.info> Dear RIPE Atlas staff, I'm a little confused. I need to add a NIC handle, you say. "What is a NIC handle? A NIC handle is the unique identifier of a person. It is basically the person's unique ID and it helps to keep different people with the same name apart from each other. Whenever a person object is referenced in another object, they are referenced by their NIC handle ("nic-hdl:") and not by their name. See an example person object" How can a handle meant for a person be used for a machine? Is this correct? Thanks, Paul Vlaar Afilias On 11/3/15 12:59 PM, RIPE Atlas (no reply) wrote: > Dear Paul Vlaar, > > We noticed that you haven't added the NIC handle for your RIPE Atlas > anchor yet. Could you please add it as soon as possible? > > NIC handles are objects in the RIPE Database that contain contact > information. Having this information available for all anchors will > make it easier for other anchor hosts or members of the community to > communicate with one another by finding the appropriate technical or > administrative contacts. > > If you don't already have a NIC handle, you can learn more about what > it is and how to create one in the RIPE Database here: > http://www.ripe.net/lir-services/new-lir/first-steps-as-a-ripe-ncc-member#create-your-first-person-object > > > Once you have a NIC handle, you can enter it on the RIPE Atlas > website under ?My Atlas? > ?Anchors? > "View". > > For any questions or issues with the creation of your NIC handle, > please contact ripe-dbm at ripe.net. > > Kind regards, > > Michela Galante RIPE Atlas Team RIPE NCC atlas at ripe.net > -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 From pvlaar at afilias.info Thu Mar 12 19:04:40 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 12 Mar 2015 19:04:40 +0100 Subject: [atlas] Please set your NIC handle for your RIPE Atlas anchor In-Reply-To: <5501CD57.1090802@afilias.info> References: <20150311115906.27384.12342@janus.atlas.ripe.net> <5501CD57.1090802@afilias.info> Message-ID: <5501D538.4000108@afilias.info> Please ignore my last e-mail to the list. That was meant for . One bit of relevant discussion perhaps: when I fill out my personal NIC handle at "Home > Data & Tools > RIPE Atlas > Manage RIPE Atlas anchor: ", it doesn't appear to stick when I revisit that page. Anyone else have that problem? ~paul From ben.choy at hkirc.hk Fri Mar 13 03:16:31 2015 From: ben.choy at hkirc.hk (Ben Choy) Date: Fri, 13 Mar 2015 02:16:31 +0000 Subject: [atlas] Probe #1047 Message-ID: Dear RIPE, Our probe #1047 has been playing up lately eg. keep dropping out after a few hours even after power cycle. Any chance of getting a replacement if we sent it back. BTW, it is one of the ?Old? v1. Cheers. [hkirc] Benjamin Choy Project Manager (System & Network) Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk http://?????.?? Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk http://????.?? Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy at hkirc.hk [cid:image002.png at 01CEAE2D.C3DA7B80] The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. PROTECT OUR ENVIRONMENT - think before printing! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 8783 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 3903 bytes Desc: image002.png URL: From bortzmeyer at nic.fr Sun Mar 15 22:18:07 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 15 Mar 2015 22:18:07 +0100 Subject: [atlas] Exact semantics of DNS' use_probe_resolver Message-ID: <20150315211806.GA23955@laperouse.bortzmeyer.org> The DNS-specific option use_probe_resolver is mentioned in but with little indication of the semantics. My experience is that some probes (with the default retry=0) return several responses, with the same "prb_id", but different "from". I assume it means the probe had several resolvers configured and tried them all. Am I correct? It may question some conclusions of . Is there an option to switch to the more typical behaviour of a DNS client (try the first resolver configured and switch to the second if the first does not reply)? From benvaux at gmail.com Mon Mar 16 07:11:45 2015 From: benvaux at gmail.com (Ben Vaux) Date: Mon, 16 Mar 2015 10:11:45 +0400 Subject: [atlas] Probe #1047 Message-ID: I had my Probe drop out a few times, I replaced the Apple USB Power Supply with a new one and it seem better now. Best regards, Ben Vaux From: Ben Choy Date: Friday, 13 March 2015 06:16 To: "ripe-atlas at ripe.net" Subject: [atlas] Probe #1047 Dear RIPE, Our probe #1047 has been playing up lately eg. keep dropping out after a few hours even after power cycle. Any chance of getting a replacement if we sent it back. BTW, it is one of the ?Old? v1. Cheers. Benjamin ChoyProject Manager (System & Network)Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk http://?????.?? Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk http://????.?? Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy at hkirc.hk The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.PROTECT OUR ENVIRONMENT - think before printing! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 8783 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 3903 bytes Desc: not available URL: From philip.homburg at ripe.net Mon Mar 16 12:11:26 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 16 Mar 2015 12:11:26 +0100 Subject: [atlas] Exact semantics of DNS' use_probe_resolver In-Reply-To: <20150315211806.GA23955@laperouse.bortzmeyer.org> References: <20150315211806.GA23955@laperouse.bortzmeyer.org> Message-ID: <5506BA5E.3020101@ripe.net> Hi Stephane, On 2015/03/15 22:18 , Stephane Bortzmeyer wrote: > The DNS-specific option use_probe_resolver is mentioned in > but with > little indication of the semantics. > > My experience is that some probes (with the default retry=0) return > several responses, with the same "prb_id", but different "from". I > assume it means the probe had several resolvers configured and tried > them all. The semantics of 'use_probe_resolver' is that the probe will send a DNS query to all resolvers listed in /etc/resolv.conf that match the particular IP version of the measurement. I assume that if you want just one result, you can extract that during processing the results. Philip From BECHA at ripe.net Tue Mar 17 11:41:37 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 17 Mar 2015 11:41:37 +0100 Subject: [atlas] Please set your NIC handle for your RIPE Atlas anchor In-Reply-To: <5501D538.4000108@afilias.info> References: <20150311115906.27384.12342@janus.atlas.ripe.net> <5501CD57.1090802@afilias.info> <5501D538.4000108@afilias.info> Message-ID: <550804E1.8000702@ripe.net> Hi all, On 12-mrt.-15 19:04, Paul Vlaar wrote: > Please ignore my last e-mail to the list. That was meant for at ripe.net>. We replied to Paul privately. Regards, Vesna From BECHA at ripe.net Tue Mar 17 12:35:59 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 17 Mar 2015 12:35:59 +0100 Subject: [atlas] Visualising RIPE Atlas Anchor Measurements In-Reply-To: <55081173.8070900@ripe.net> References: <55081173.8070900@ripe.net> Message-ID: <5508119F.7020105@ripe.net> Dear colleagues, Salim Gasmi, one of the RIPE Atlas anchor hosts, visualised the measurements collected by the RIPE Atlas anchor. This monitoring page is publicly available and allows to analyse topology changes and helps debugging network issues. Please find more details on RIPE Labs: https://labs.ripe.net/Members/salim_gasmi/visualising-ripe-atlas-anchor-measurements Kind regards, Vesna From bortzmeyer at nic.fr Tue Mar 17 15:23:29 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Mar 2015 15:23:29 +0100 Subject: [atlas] Exact semantics of DNS' use_probe_resolver In-Reply-To: <5506BA5E.3020101@ripe.net> References: <20150315211806.GA23955@laperouse.bortzmeyer.org> <5506BA5E.3020101@ripe.net> Message-ID: <20150317142329.GA3222@nic.fr> On Mon, Mar 16, 2015 at 12:11:26PM +0100, Philip Homburg wrote a message of 20 lines which said: > I assume that if you want just one result, you can extract that > during processing the results. OK, implemented in 9091fc624345fc9cddf6f2070dca1f51a27fbac2 From bortzmeyer at nic.fr Tue Mar 17 16:15:08 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Mar 2015 16:15:08 +0100 Subject: [atlas] Wrong IP prefix values accepted? Message-ID: <20150317151508.GA11604@nic.fr> It seems there is no protection against wrong prefixes? See measurement #1897909, which started with JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix foobar', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 3, 'type': 'prefix', 'value': 'foobar'}]} From bortzmeyer at nic.fr Tue Mar 17 16:58:59 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Mar 2015 16:58:59 +0100 Subject: [atlas] Wrong IP prefix values accepted? In-Reply-To: <20150317151508.GA11604@nic.fr> References: <20150317151508.GA11604@nic.fr> Message-ID: <20150317155859.GA16856@nic.fr> On Tue, Mar 17, 2015 at 04:15:08PM +0100, Stephane Bortzmeyer wrote a message of 4 lines which said: > It seems there is no protection against wrong prefixes? See > measurement #1897909, which started with JSON: Also, I do not understand the algorithm used to reject prefixes with the message "Your selected prefix is not covered by our network." I tried to ask probes in the prefix 88.0.0.0/8 (with the Web interface) and it was rejected with the above message despite the fact that probes 88.186.234.47, 88.179.43.37, etc do exist. From bortzmeyer at nic.fr Tue Mar 17 17:25:33 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Mar 2015 17:25:33 +0100 Subject: [atlas] Wrong IP prefix values accepted? In-Reply-To: <20150317151508.GA11604@nic.fr> References: <20150317151508.GA11604@nic.fr> Message-ID: <20150317162533.GA20591@nic.fr> On Tue, Mar 17, 2015 at 04:15:08PM +0100, Stephane Bortzmeyer wrote a message of 4 lines which said: > It seems there is no protection against wrong prefixes? Last (I promise) remark about prefix selection. I cannot do it from the API. From the Web interface, I can select the prefix 88.176.0.0/12 and it works. But from the API, while it is accepted (I get a number, #1897919), he measurement later fails. My JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix 88.176.0.0/12', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 5, 'type': 'prefix', 'value': '88.176.0.0/12'}]} The status when querying: {u'id': 7, u'name': u'Failed'} From dquinn at ripe.net Tue Mar 17 18:48:14 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 17 Mar 2015 18:48:14 +0100 Subject: [atlas] Wrong IP prefix values accepted? In-Reply-To: <20150317151508.GA11604@nic.fr> References: <20150317151508.GA11604@nic.fr> Message-ID: <550868DE.9020309@ripe.net> I've just gone over your cases here and wanted to let you know that at least one of these was the unfortunate result of a typo on my part :-( I've since fixed it, and that fix will go out tomorrow as it's coming up on 1900h here in Amsterdam. Unfortunately, the issue of rejecting should-be-valid prefixes was not as simple a problem and that's going to take a little longer to fix. We have a few people tasked now with fixing this. It's a known problem with how we handle comparing IPs to prefixes in our database and we hope to have that working in production tomorrow as well -- though it may take a smidge longer than that. Thanks for finding these, and for reporting it. Though next time, please report bugs to atlas-bugs at ripe.net :-) From bortzmeyer at nic.fr Tue Mar 17 21:08:26 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Mar 2015 21:08:26 +0100 Subject: [atlas] Wrong IP prefix values accepted? In-Reply-To: <550868DE.9020309@ripe.net> References: <20150317151508.GA11604@nic.fr> <550868DE.9020309@ripe.net> Message-ID: <20150317200826.GA9187@nic.fr> On Tue, Mar 17, 2015 at 06:48:14PM +0100, Daniel Quinn wrote a message of 14 lines which said: > Though next time, please report bugs to atlas-bugs at ripe.net :-) OK but I wasn't sure it was a bug, I thought it may be worth a discussion. Good luck for the fix and don't worry, it's not an emergency. From astracha at ripe.net Thu Mar 19 11:58:18 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 19 Mar 2015 11:58:18 +0100 Subject: [atlas] SwissIX Internet Exchange (Glattbrugg, Switzerland) has joined RIPE Atlas Anchors Message-ID: <98C0B863-7C1B-4B47-A575-C8BA6FC6CB0B@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ch-gtg-as20612 and it is hosted by SwissIX Internet Exchange in Glattbrugg, Switzerland Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From klaus.mailinglists at pernau.at Fri Mar 20 17:14:52 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Fri, 20 Mar 2015 17:14:52 +0100 Subject: [atlas] Feedback about the new webinterface Message-ID: <550C477C.2050109@pernau.at> Hi! First, thanks for the new web interface. I really like how you show the most important parts of the results, e.g. decoding the NSID for DNS measurements, and showing the traceroute with editable geolocation. Nevertheless I have some feedback: On https://atlas.ripe.net/probes/, when I search for probes matching "6939", I get the results in a list view of matching probes. In the list view, I can see the probe's ASN. But when the result set is small (e.g. 2 probes only), I do not get a "list view" but view with bigger "thumbnails", but missing the ASN information. Also viewing the details of a probe does not reveal the probes ASN. Similar with IP addresses. When viewing the results of a measurement on the map, if a click on a probe I get the probe's IP addresses. But when watching a probe's details I can not see the IP addresses of the probe. For me it is strange to get the probe's IPs and ASN not when watching the probe's details. This is quite some interesting info when selecting probes or when analyzing why the result from a certain probe was bad. Thanks Klaus From ethemcoskun at nevada.unr.edu Tue Mar 24 05:55:30 2015 From: ethemcoskun at nevada.unr.edu (Ibrahim Coskun) Date: Mon, 23 Mar 2015 21:55:30 -0700 Subject: [atlas] Paris-traceroute flow identifier Message-ID: Hello, This is Ibrahim Ethem Coskun from University of Nevada, Reno. I'm currently working on an Internet Measurement project with Professor Mehmet Hadi Gunes. We are modifying paris-traceroute's source code and set the flow identifier of each packet (both sending and returning packets) to a constant value for every traces. So that, we want a trace to follow the same path whenever we traceroute the same target. However, I get the below warning messages from each probe : paris-traceroute -T 500 -i -l -M 5 -p icmp -r 44000 -a hopbyhop -n " + target_ip [WARN](TracertImpl.cc, 335)ICMP reserved words 0 0 0 0 0 [WARN](TracertImpl.cc, 330)Bad return flow id 0xd24e from 4.69.152.80 So, what does this warning mean, I checked the source code but couldn't find and information regarding this issue, I also email paris-traceroute team, but no responses. I googled my question and found a similar question emailed to to you ( https://www.ripe.net/ripe/mail/archives/ripe-atlas/2012-July/000534.html). I would be very pleased if you can answer my question. Thank you; -------------- next part -------------- An HTML attachment was scrubbed... URL: From astracha at ripe.net Wed Mar 25 10:26:10 2015 From: astracha at ripe.net (Alastair Strachan) Date: Wed, 25 Mar 2015 10:26:10 +0100 Subject: [atlas] CarrierColo / IPB GmbH in (Berlin, Germany) has joined RIPE Atlas Anchors Message-ID: <88B3C829-BD54-4E6C-84F3-5705F27652C2@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-ber-as20647 and it is hosted by CarrierColo / IPB GmbH in Berlin, Germany. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From philip.homburg at ripe.net Wed Mar 25 17:31:02 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 25 Mar 2015 17:31:02 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? Message-ID: <5512E2C6.7030205@ripe.net> Dear community members, The RIPE Atlas team has a question what to do with probes that have only a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 address. The question is whether to treat those probes as IPv6 capable or not. It is known that about 10% of the RIPE Atlas probes that have IPv6 addresses do not actually have IPv6 connectivity. This was documented by St?phane Bortzmeyer in his RIPE Labs article "How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)?" (https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong) As a way of dealing with this problem, the RIPE Atlas system now tags probes that have broken IPv6. Any probe that has an IPv6 address (other than link local) but cannot reach the global internet is tagged as "IPv6 Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) At the moment, around 2800 probes are connected and have an IPv6 address. Of those probes, around 350 (12.5%) are tagged that IPv6 doesn't work. Of those 350 probes, 114 have the surprising condition that the connect system call fails immediately with the error 'Network is unreachable.' Those 114 probes have two things in common, they have only a ULA address and the do not have a default route. It is the lack of default route that causes the connect system call to fail immediately. This feature (ULA and no default route) is specified in RFC-7084 (IPv6 CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes.") The surprising thing is that for some probes this condition persists for many months. For the Atlas project, the question is how we should treat these probes. Currently they are regarded as having broken IPv6 connectivity. However, an alternative is to consider those probes as having no IPv6 at all. Broader questions are: are CPEs doing the right thing here. Should a CPE announce a ULA on the local LAN even if there hasn't been any IPv6 internet connectivity for a very long time? It is already complex enough for normal users to understand that there is always a link local IPv6 address even if there is no IPv6 connectivity. Now we have to add ULA to that group as well. So the question to the community, should RIPE Atlas treat ULAs in the same way as RFC-1918, addresses that should be ignored unless a valid global address can be found elsewhere. Or should we keep the current approach where ULAs are treated just like other global IPv6 addresses and consider the probe host's network setup to be broken? Philip From furry13 at gmail.com Wed Mar 25 19:05:31 2015 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 25 Mar 2015 19:05:31 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: On Wed, Mar 25, 2015 at 5:31 PM, Philip Homburg wrote: > The RIPE Atlas team has a question what to do with probes that have only > a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 > address. The question is whether to treat those probes as IPv6 capable > or not. > As a way of dealing with this problem, the RIPE Atlas system now tags > probes that have broken IPv6. Any probe that has an IPv6 address (other > than link local) but cannot reach the global internet is tagged as "IPv6 > Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) > > At the moment, around 2800 probes are connected and have an IPv6 > address. Of those probes, around 350 (12.5%) are tagged that IPv6 > doesn't work. Of those 350 probes, 114 have the surprising condition > that the connect system call fails immediately with the error 'Network > is unreachable.' > > Those 114 probes have two things in common, they have only a ULA address > and the do not have a default route. It is the lack of default route > that causes the connect system call to fail immediately. > > This feature (ULA and no default route) is specified in RFC-7084 (IPv6 > CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT > advertise itself as a default router with a Router Lifetime greater than > zero whenever all of its configured and delegated prefixes are ULA > prefixes.") The surprising thing is that for some probes this condition > persists for many months. One of the possible reasons might be that a home network does not have IPv6-enabled uplink but ULAs are used for internal connectivity. I actually did it at my place at some point, when I wanted to have Ipv6-enalbed LAN but my ISP did not provide me with v6 connectivity. 114 out of 350 does look like a lot (on the other hand a lot of probes are hosted by network people who love to play with their home networks; ) I do hope that this situation is not caused by ISPs using ULAs.... > For the Atlas project, the question is how we should treat these probes. > Currently they are regarded as having broken IPv6 connectivity. However, > an alternative is to consider those probes as having no IPv6 at all. What difference does it make? > Broader questions are: are CPEs doing the right thing here. Should a CPE > announce a ULA on the local LAN even if there hasn't been any IPv6 > internet connectivity for a very long time? It is already complex enough > for normal users to understand that there is always a link local IPv6 > address even if there is no IPv6 connectivity. Now we have to add ULA to > that group as well. If ULA is configured in a CPE, then it should be announced in RAs. As long as it does not break v6 for users (and it should not as there is not default route), it's fine. > So the question to the community, should RIPE Atlas treat ULAs in the > same way as RFC-1918, addresses that should be ignored unless a valid > global address can be found elsewhere. Or should we keep the current > approach where ULAs are treated just like other global IPv6 addresses > and consider the probe host's network setup to be broken? But wait, if a probe has RFC1918 addresses only you do not mark it as 'no v4 connectivity', right? If a probe has a address of a global scope (v4 or v6) but could not reach the outside world it means the connectivity is broken. So IMHO it makes slightly more sense to mark ULA-only probes as having broken connectivity. But, again, could you please clarify what is the difference between two tags from practical perspective? -- SY, Jen Linkova aka Furry From rm at romanrm.net Wed Mar 25 19:04:49 2015 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 25 Mar 2015 23:04:49 +0500 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: <20150325230449.058eb5fb@natsu> On Wed, 25 Mar 2015 17:31:02 +0100 Philip Homburg wrote: > At the moment, around 2800 probes are connected and have an IPv6 > address. Of those probes, around 350 (12.5%) are tagged that IPv6 > doesn't work. Of those 350 probes, 114 have the surprising condition > that the connect system call fails immediately with the error 'Network > is unreachable.' > > Those 114 probes have two things in common, they have only a ULA address > and the do not have a default route. It is the lack of default route > that causes the connect system call to fail immediately. ULA-only is not a breakage that needs to be fixed. The network simply has no connectivity with the global IPv6 Internet. However it might very well have links to other such "islands" managed by the user, by the means of a VPN over IPv4 Internet or some other technology such as private leased L2 links. E.g. using ULA addressing can be a comfortable way to start deploying IPv6 in a set of geographically diverse offices of a company, in case some of them don't have IPv6 from ISPs locally, and if the company is not large enough to afford/warrant the expense and bureaucracy of getting their own globally-routable IPv6 space assignment, at least initially. Browsers and other client software will not try the ULA IP as outgoing bind address to connect to dual-stacked websites and services on the global Internet, so it does not cause any user-visible breakage either. > This feature (ULA and no default route) is specified in RFC-7084 (IPv6 > CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT > advertise itself as a default router with a Router Lifetime greater than > zero whenever all of its configured and delegated prefixes are ULA > prefixes.") The surprising thing is that for some probes this condition > persists for many months. Nothing really surprising about this. There is simply no IPv6 offered by the ISP, and many ISPs still do not begin to deploy IPv6 and only promise (if even that) for months and years. > For the Atlas project, the question is how we should treat these probes. > Currently they are regarded as having broken IPv6 connectivity. However, > an alternative is to consider those probes as having no IPv6 at all. No globally reachable IPv6, that's correct. > Broader questions are: are CPEs doing the right thing here. Should a CPE > announce a ULA on the local LAN even if there hasn't been any IPv6 > internet connectivity for a very long time? Yes I believe they do. Link-local address aren't supposed to be used directly, e.g. you can't expect to be able to load a website served from an LL IPv6 in a browser. And imagine some future IPv6-only client device. With ULA it could access local services of the user's LAN (for example files shared from a NAS), if there is no need for it to access anything on the Internet. Trying to use LLs for this and lugging around "%interface" everywhere is not an acceptable answer. Also routers these days come with something like "Open http://192.168.0.1/ in the web browser to configure" -- this causes a problem if the user's local network already uses the 192.168.0.0/24 as their network prefix, and moreover, the 192.168.0.1 IP is already taken for some production server (which seemed like a pretty logical thing to do addressing-wise at the time). Maybe in the future they could come with some random "http://[fd12:3456::1]/" ULA default IP instead, with the router also automatically RA'ing that ULA network on first power-up. The actual prefix could be random per router model or per manufacturer, ensuring little to no collisions. > So the question to the community, should RIPE Atlas treat ULAs in the > same way as RFC-1918, addresses that should be ignored unless a valid > global address can be found elsewhere. ULA (and not LL) are the perfect equivalent of RFC-1918 space. Even though no one should [even think to] set up NAT from/to them to GUA, there are still uses for a private prefix, for example due to it being totally ISP-independent and unchanging, allowing to set up static ACLs and DNS records. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed Mar 25 19:19:30 2015 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 25 Mar 2015 13:19:30 -0500 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: If those probes with ULA, aren?t able to connect to v6 Internet, for example using NPT, then should be considered as non-IPv6 enabled. IPv6 is not broken, is just meant for LAN connectivity. If ?broken? for you mean no-Internet connectivity, then is broken ;-) And yes, the CPE is doing the right thing, it has been configured to use an ULA to allow LAN IPv6 connectivity. Regards, Jordi -----Mensaje original----- De: Philip Homburg Responder a: Fecha: mi?rcoles, 25 de marzo de 2015, 11:31 Para: "ripe-atlas at ripe.net" , Asunto: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? >Dear community members, > >The RIPE Atlas team has a question what to do with probes that have only >a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 >address. The question is whether to treat those probes as IPv6 capable >or not. > >It is known that about 10% of the RIPE Atlas probes that have IPv6 >addresses do not actually have IPv6 connectivity. This was documented by >St?phane Bortzmeyer in his RIPE Labs article "How Many RIPE Atlas Probes >Believe They Have IPv6 (But Are Wrong)?" >(https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-b >elieve-they-have-ipv6-but-are-wrong) > >As a way of dealing with this problem, the RIPE Atlas system now tags >probes that have broken IPv6. Any probe that has an IPv6 address (other >than link local) but cannot reach the global internet is tagged as "IPv6 >Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) > >At the moment, around 2800 probes are connected and have an IPv6 >address. Of those probes, around 350 (12.5%) are tagged that IPv6 >doesn't work. Of those 350 probes, 114 have the surprising condition >that the connect system call fails immediately with the error 'Network >is unreachable.' > >Those 114 probes have two things in common, they have only a ULA address >and the do not have a default route. It is the lack of default route >that causes the connect system call to fail immediately. > >This feature (ULA and no default route) is specified in RFC-7084 (IPv6 >CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT >advertise itself as a default router with a Router Lifetime greater than >zero whenever all of its configured and delegated prefixes are ULA >prefixes.") The surprising thing is that for some probes this condition >persists for many months. > >For the Atlas project, the question is how we should treat these probes. >Currently they are regarded as having broken IPv6 connectivity. However, >an alternative is to consider those probes as having no IPv6 at all. > >Broader questions are: are CPEs doing the right thing here. Should a CPE >announce a ULA on the local LAN even if there hasn't been any IPv6 >internet connectivity for a very long time? It is already complex enough >for normal users to understand that there is always a link local IPv6 >address even if there is no IPv6 connectivity. Now we have to add ULA to >that group as well. > >So the question to the community, should RIPE Atlas treat ULAs in the >same way as RFC-1918, addresses that should be ignored unless a valid >global address can be found elsewhere. Or should we keep the current >approach where ULAs are treated just like other global IPv6 addresses >and consider the probe host's network setup to be broken? > >Philip > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From remaker at gmail.com Thu Mar 26 06:40:51 2015 From: remaker at gmail.com (Phillip Remaker) Date: Wed, 25 Mar 2015 22:40:51 -0700 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: My vote: Devices with ULA only should be regarded as having no IPv6 at all unless an active test can demonstrate connectivity (as in, through an NPTv6 device) RIPE Atlas acts as a connectivity observatory. A ULA is the equivalent of an unconnected node. It is not broken; it is, by design, limited to local connectivity, and should always be that way. If a device has no global IPv6 address, it should be regarded as IPv6 incapable, not IPv6 broken. The situation where my probes have ULA: An upstream Linksys router supports IPv6 and provides a ULA. Since it has no connectivity from the MSO, it does not provide a global address. It may provide site-local IPv6 routing, but never IPv6 Internet routing. Therefore, it should be regarded as not IPv6 capable. There may be an NPTv6 gateway that will provide IPv6 connectivity for ULA devices, but I will argue that this is less common that the home router providing unrouteable ULA. However, that case NPTv6 should be readily detectable. RE: Are CPEs doing the right thing - the HOMENET IETF group is very concerned about that question, and actively wrestling with it. https://datatracker.ietf.org/wg/homenet/documents/ On Wed, Mar 25, 2015 at 9:31 AM, Philip Homburg wrote: > Dear community members, > > The RIPE Atlas team has a question what to do with probes that have only > a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 > address. The question is whether to treat those probes as IPv6 capable > or not. > > It is known that about 10% of the RIPE Atlas probes that have IPv6 > addresses do not actually have IPv6 connectivity. This was documented by > St?phane Bortzmeyer in his RIPE Labs article "How Many RIPE Atlas Probes > Believe They Have IPv6 (But Are Wrong)?" > ( > https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong > ) > > As a way of dealing with this problem, the RIPE Atlas system now tags > probes that have broken IPv6. Any probe that has an IPv6 address (other > than link local) but cannot reach the global internet is tagged as "IPv6 > Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) > > At the moment, around 2800 probes are connected and have an IPv6 > address. Of those probes, around 350 (12.5%) are tagged that IPv6 > doesn't work. Of those 350 probes, 114 have the surprising condition > that the connect system call fails immediately with the error 'Network > is unreachable.' > > Those 114 probes have two things in common, they have only a ULA address > and the do not have a default route. It is the lack of default route > that causes the connect system call to fail immediately. > > This feature (ULA and no default route) is specified in RFC-7084 (IPv6 > CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT > advertise itself as a default router with a Router Lifetime greater than > zero whenever all of its configured and delegated prefixes are ULA > prefixes.") The surprising thing is that for some probes this condition > persists for many months. > > For the Atlas project, the question is how we should treat these probes. > Currently they are regarded as having broken IPv6 connectivity. However, > an alternative is to consider those probes as having no IPv6 at all. > > Broader questions are: are CPEs doing the right thing here. Should a CPE > announce a ULA on the local LAN even if there hasn't been any IPv6 > internet connectivity for a very long time? It is already complex enough > for normal users to understand that there is always a link local IPv6 > address even if there is no IPv6 connectivity. Now we have to add ULA to > that group as well. > > So the question to the community, should RIPE Atlas treat ULAs in the > same way as RFC-1918, addresses that should be ignored unless a valid > global address can be found elsewhere. Or should we keep the current > approach where ULAs are treated just like other global IPv6 addresses > and consider the probe host's network setup to be broken? > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bs at stepladder-it.com Thu Mar 26 09:26:40 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Thu, 26 Mar 2015 08:26:40 +0000 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: (Jen Linkova's message of "Wed, 25 Mar 2015 19:05:31 +0100") References: <5512E2C6.7030205@ripe.net> Message-ID: <87twx8uptr.fsf@stepladder-it.com> Hi folks, Jen Linkova writes: >> So the question to the community, should RIPE Atlas treat ULAs in the >> same way as RFC-1918, addresses that should be ignored unless a valid >> global address can be found elsewhere. Or should we keep the current >> approach where ULAs are treated just like other global IPv6 addresses >> and consider the probe host's network setup to be broken? > > But wait, if a probe has RFC1918 addresses only you do not mark it as > 'no v4 connectivity', right? > If a probe has a address of a global scope (v4 or v6) but could not > reach the outside world it means the connectivity is broken. So IMHO > it makes slightly more sense to mark ULA-only probes as having broken > connectivity. just wondering: If I use RFC1918 addresses with IPv4 I might still have Internet access through a NAT gateway. If I have only ULA, then I may reasonably expect there's no NAT, so there's a fundamental difference here. However, I personally *do* run my stuff through a firewall setup including application level gateways. So it might be argued that my ULA-only devices still have (some rather limited sort of) Internet access anyway. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ From pierky at pierky.com Thu Mar 26 10:24:54 2015 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Thu, 26 Mar 2015 10:24:54 +0100 Subject: [atlas] =?utf-8?q?What_to_do_with_RIPE_Atlas_probes_that_have_onl?= =?utf-8?q?y_a_ULA_as_IPv6_address=3F?= In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: Hi, On 2015-03-25 17:31, Philip Homburg wrote: > The RIPE Atlas team has a question what to do with probes that have > only > a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 > address. The question is whether to treat those probes as IPv6 capable > or not. [...] > Currently they are regarded as having broken IPv6 connectivity. > However, > an alternative is to consider those probes as having no IPv6 at all. do you think it is worth considering to use different tags in order to describe different aspects? For example an "ipv6-ula-only" tag and an "ipv6-global-internet-reachability" tag. Assigning the "IPv6 Doesn't Work" tag just on the basis of the ULA-only criteria would exclude those (few?) probes having ULA but also global IPv6 reachability, perhaps through some kind of NAT (NPTv6). Different tags may offer a finer granularity on the probes selection process, for example it would allow to run tests on probes with ULA behind an IPv6 NAT box. It also allows to have statistics on ULA usage. At the same time it would be still possible to run measurements on "global-only" probes by selecting ipv6-global-internet-reachability and explicitly filtering out ipv6-ula-only. Regards, -- Pier Carlo Chiodi http://pierky.com From astracha at ripe.net Thu Mar 26 10:39:13 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 26 Mar 2015 10:39:13 +0100 Subject: [atlas] FranceIX ( Paris, France) has joined RIPE Atlas Anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fr-par-as57734 and it is hosted by FranceIX in Paris, France. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From tjc at ecs.soton.ac.uk Thu Mar 26 10:23:23 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 26 Mar 2015 09:23:23 +0000 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87twx8uptr.fsf@stepladder-it.com> References: <5512E2C6.7030205@ripe.net> <87twx8uptr.fsf@stepladder-it.com> <3BD718AB-F4EA-4E13-A589-652C793F8E43@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 08:26, Benedikt Stockebrand wrote: > > Hi folks, > > Jen Linkova writes: > >>> So the question to the community, should RIPE Atlas treat ULAs in the >>> same way as RFC-1918, addresses that should be ignored unless a valid >>> global address can be found elsewhere. Or should we keep the current >>> approach where ULAs are treated just like other global IPv6 addresses >>> and consider the probe host's network setup to be broken? >> >> But wait, if a probe has RFC1918 addresses only you do not mark it as >> 'no v4 connectivity', right? >> If a probe has a address of a global scope (v4 or v6) but could not >> reach the outside world it means the connectivity is broken. So IMHO >> it makes slightly more sense to mark ULA-only probes as having broken >> connectivity. > > just wondering: If I use RFC1918 addresses with IPv4 I might still have > Internet access through a NAT gateway. If I have only ULA, then I may > reasonably expect there's no NAT, so there's a fundamental difference > here. > > However, I personally *do* run my stuff through a firewall setup > including application level gateways. So it might be argued that my > ULA-only devices still have (some rather limited sort of) Internet > access anyway. It would seem this is a good platform from which to see what types of connectivity devices with ULAs have, e.g. to get a guesstimate of NPTv6 deployment. Tim From pk at DENIC.DE Thu Mar 26 13:12:52 2015 From: pk at DENIC.DE (Peter Koch) Date: Thu, 26 Mar 2015 13:12:52 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> Message-ID: <20150326121252.GR12291@x28.adm.denic.de> On Thu, Mar 26, 2015 at 10:24:54AM +0100, Pier Carlo Chiodi wrote: > behind an IPv6 NAT box. It also allows to have statistics on ULA usage. Atlas should be used as an Internet measurement tool, not as a reconnaissance mechanism for the hosts' networks. ULA only equals "no IPv6" in my opinion. -Peter From rm at romanrm.net Thu Mar 26 13:45:15 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 17:45:15 +0500 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326121252.GR12291@x28.adm.denic.de> References: <5512E2C6.7030205@ripe.net> <20150326121252.GR12291@x28.adm.denic.de> Message-ID: <20150326174515.06a51dfa@natsu> On Thu, 26 Mar 2015 13:12:52 +0100 Peter Koch wrote: > On Thu, Mar 26, 2015 at 10:24:54AM +0100, Pier Carlo Chiodi wrote: > > > behind an IPv6 NAT box. It also allows to have statistics on ULA usage. > > Atlas should be used as an Internet measurement tool, not as a reconnaissance > mechanism for the hosts' networks. ULA only equals "no IPv6" in my opinion. This is still within the scope of determining "are we on the Internet". If the probe only has an ULA, but gets a default (or a 2000::/3, etc) route, and a connection request to a GUA IP succeeds, then yes we are, nonwithstanding through which perverse NAT66 means the host has chosen to provide the connectivity. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aprado at topnet.it Thu Mar 26 13:53:49 2015 From: aprado at topnet.it (Antonio Prado) Date: Thu, 26 Mar 2015 13:53:49 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: <5514015D.8080403@topnet.it> On 3/25/15 5:31 PM, Philip Homburg wrote: > So the question to the community, should RIPE Atlas treat ULAs in the > same way as RFC-1918, addresses that should be ignored unless a valid > global address can be found elsewhere. Or should we keep the current > approach where ULAs are treated just like other global IPv6 addresses > and consider the probe host's network setup to be broken? hi, as atlas measures internet connectivity and reachability, as ula addresses should not be routable in internet, probes with (just) ula addresses should be ignored (and not considered as broken) -- antonio From lists at quux.de Thu Mar 26 14:09:03 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 14:09:03 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326121252.GR12291@x28.adm.denic.de> (Peter Koch's message of "Thu, 26 Mar 2015 13:12:52 +0100") References: <5512E2C6.7030205@ripe.net> <20150326121252.GR12291@x28.adm.denic.de> Message-ID: <87zj6zhpn4.fsf@pc8.berlin.quux.de> Peter Koch writes: > Atlas should be used as an Internet measurement tool, not as a reconnaissance > mechanism for the hosts' networks. ULA only equals "no IPv6" in my opinion. I think it might be interesting to see what breaks (and what not) when ULA and some form of address translation is used. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From lists at quux.de Thu Mar 26 14:23:34 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 14:23:34 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> (Philip Homburg's message of "Wed, 25 Mar 2015 17:31:02 +0100") References: <5512E2C6.7030205@ripe.net> Message-ID: <87vbhnhoyx.fsf@pc8.berlin.quux.de> Philip Homburg writes: > Dear community members, > > The RIPE Atlas team has a question what to do with probes that have only > a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 > address. The question is whether to treat those probes as IPv6 capable > or not. BTW: Are there any probes with site-local IPv6 addresses (fec0::/10). Yes I know site local is deprecated for many years (RFC3879 is from 2004) but some people still haven't noticed[1]. I also found some while checking the Alexa list for odd AAAA records[2]. Jens [1] Last year I bought this book http://www.ciscopress.com/store/cisco-asa-all-in-one-next-generation-firewall-ips-and-9781587143076 and most of the IPv6 chapter explains site-local addressing. The book was published in 2014. [2] http://blog.quux.de/?p=1829 - I'll try update and improve this list next week -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From philip.homburg at ripe.net Thu Mar 26 14:26:14 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 14:26:14 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150325230449.058eb5fb@natsu> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> Message-ID: <551408F6.5030809@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for all the responses. In this mail, I'll try to respond to multiple replies. On 2015/03/25 19:04 , Roman Mamedov wrote: > ULA-only is not a breakage that needs to be fixed. The network > simply has no connectivity with the global IPv6 Internet. However > it might very well have links to other such "islands" managed by > the user, by the means of a VPN over IPv4 Internet or some other > technology such as private leased L2 links. Note that the probes I'm talking about combine two issues: they have only ULA addresses and they don't have a default route. Without a default route, no IPv6 traffic will leave the probe (except for traffic targeting other node in the onlink /64). > Browsers and other client software will not try the ULA IP as > outgoing bind address to connect to dual-stacked websites and > services on the global Internet, so it does not cause any > user-visible breakage either. I forgot that RFC-6724 (Default Address Selection for Internet Protocol Version 6) now explicitly lists ULAs, so indeed they would not do any harm in trying to reach a dual-stack target. > Nothing really surprising about this. There is simply no IPv6 > offered by the ISP, and many ISPs still do not begin to deploy IPv6 > and only promise (if even that) for months and years. But is that a good reason for a CPE to start announcing IPv6 prefixes? > And imagine some future IPv6-only client device. With ULA it could > access local services of the user's LAN (for example files shared > from a NAS), if there is no need for it to access anything on the > Internet. Trying to use LLs for this and lugging around > "%interface" everywhere is not an acceptable answer. Link local was supposed to solve the 'dentist office' problem where there is no router. So that scenario is now dead? On 2015/03/25 18:25 , Dickinson, Ian wrote: > The answer IMHO is to treat ULAs in the same way as RFC1918 - ULA > is not just another global address. > The IPv6 is not broken, but is simultaneously not available - so treat it as having no IPv6 at all unless it has a global address. Yes. The most generic way of dealing of dealing with this problem is to look for a global address, i.e. for a probe with just a ULA to see if it can perform any kind of operation that requires the use of a global address. If that is successful then declare the probe as IPv6 capable. That should be future proof in case somebody wants to deploy NAT66. On 2015/03/25 19:05 , Jen Linkova wrote:> On Wed, Mar 25, 2015 at 5:31 > One of the possible reasons might be that a home network does not > have IPv6-enabled uplink but ULAs are used for internal > connectivity. I actually did it at my place at some point, when I > wanted to have Ipv6-enalbed LAN but my ISP did not provide me with > v6 connectivity. > > 114 out of 350 does look like a lot (on the other hand a lot of > probes are hosted by network people who love to play with their > home networks; ) Good question. I sort of assumed it would be done automatically by the router. Otherwise I would get a tunnel. I'll if I can find out more. > I do hope that this situation is not caused by ISPs using ULAs.... I assume we can rule that out because there is no default route. >> For the Atlas project, the question is how we should treat these probes. >> Currently they are regarded as having broken IPv6 connectivity. However, >> an alternative is to consider those probes as having no IPv6 at >> all. > > What difference does it make? The difference is that these probes get a full load of IPv6 measurements which all fail (and cannot succeed while there is no default route). It may inflate IPv6 brokenness numbers. > If ULA is configured in a CPE, then it should be announced in RAs. As long as it > does not break v6 for users (and it should not as there is not > default route), it's fine. I wonder if this will cause problems with server software in the future. I.e. a server finds a ULA and announces it one way or another. And a host on a different site that also has ULA tries to use the address and fails. Next iteration, the server software explicitly ignores ULAs. >> So the question to the community, should RIPE Atlas treat ULAs in >> the same way as RFC-1918, addresses that should be ignored unless >> a valid global address can be found elsewhere. Or should we keep >> the current approach where ULAs are treated just like other >> global IPv6 addresses and consider the probe host's network setup >> to be broken? > > But wait, if a probe has RFC1918 addresses only you do not mark it > as 'no v4 connectivity', right? If a probe has a address of a > global scope (v4 or v6) but could not reach the outside world it > means the connectivity is broken. So IMHO it makes slightly more > sense to mark ULA-only probes as having broken connectivity. But, > again, could you please clarify what is the difference between two > tags from practical perspective? At the moment, IPv4 and IPv6 are treated differently. For IPv4 the assumption is that lots of probes are behind NAT so the system tracks local and global addresses. For IPv6, the current assumption is that all addresses are global and there is no NAT. Note that in general, a probe that has a RFC-1918 address also has a default route. I'm not really aware of any exceptions. Whereas in this case there is no default route. So it is quite clear that there is no IPv6 connectivity. On 2015/03/26 6:40 , Phillip Remaker wrote: > My vote: Devices with ULA only should be regarded as having no IPv6 > at all unless an active test can demonstrate connectivity (as in, > through an NPTv6 device) Sounds like a good way forward to me. On 2015/03/26 9:26 , Benedikt Stockebrand wrote:> Hi folks, > just wondering: If I use RFC1918 addresses with IPv4 I might still > have Internet access through a NAT gateway. If I have only ULA, > then I may reasonably expect there's no NAT, so there's a > fundamental difference here. Maybe the best way is to create feature-parity with IPv4 and support IPv6 NAT as well. That would make both protocols from a RIPE Atlas point of view more symmetric. On 2015/03/26 10:24 , Pier Carlo Chiodi wrote: > do you think it is worth considering to use different tags in order > to describe different aspects? For example an "ipv6-ula-only" tag > and an "ipv6-global-internet-reachability" tag. > > Assigning the "IPv6 Doesn't Work" tag just on the basis of the > ULA-only criteria would exclude those (few?) probes having ULA but > also global IPv6 reachability, perhaps through some kind of NAT > (NPTv6). My proposal would mark probes that have only ULA but also lack a default route as not IPv6 capable. Without a default route, the probe is never going to perform any IPv6 measurements even if there would be a NAT box. For probes that have ULA and do have a default route, it might be worth tagging them. Though at the moment it is just dynamically determined that IPv6 doesn't work based on actual measurements. On 2015/03/26 13:12 , Peter Koch wrote: > On Thu, Mar 26, 2015 at 10:24:54AM +0100, Pier Carlo Chiodi wrote: >> behind an IPv6 NAT box. It also allows to have statistics on ULA usage. > > Atlas should be used as an Internet measurement tool, not as a reconnaissance > mechanism for the hosts' networks. ULA only equals "no IPv6" in my opinion. I agree that RIPE Atlas should not try to measure the probe host's local network. But do we want to rule out support for NAT66? Or rule out support for NAT66 at the moment and then support when it is in actual use? Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUUCPYACgkQ23LKRM64egK31wCfX8Aq3Xh/+sPcVaYY5f4ew6Z2 xrIAn3Iwn0ri7gpkKkv9mEEmDeO2SW4l =3CFu -----END PGP SIGNATURE----- From rm at romanrm.net Thu Mar 26 14:31:00 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 18:31:00 +0500 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5514015D.8080403@topnet.it> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> Message-ID: <20150326183100.52b8ce28@natsu> On Thu, 26 Mar 2015 13:53:49 +0100 Antonio Prado wrote: > On 3/25/15 5:31 PM, Philip Homburg wrote: > > So the question to the community, should RIPE Atlas treat ULAs in the > > same way as RFC-1918, addresses that should be ignored unless a valid > > global address can be found elsewhere. Or should we keep the current > > approach where ULAs are treated just like other global IPv6 addresses > > and consider the probe host's network setup to be broken? > > hi, > > as atlas measures internet connectivity and reachability, > as ula addresses should not be routable in internet, RFC-1918 addresses too. > probes with (just) ula addresses should be ignored By that logic probes with just RFC-1918 IPs should not attempt any IPv4 measurements either. NAT66 is not (and should not be) common, however there is no harm in doing an inobtrusive check to see if it's deployed, or to collect stats on the scale of such deployments. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philip.homburg at ripe.net Thu Mar 26 14:41:04 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 14:41:04 +0100 Subject: [atlas] Paris-traceroute flow identifier In-Reply-To: References: Message-ID: <55140C70.9010508@ripe.net> Hi Ibrahim, On 2015/03/24 5:55 , Ibrahim Coskun wrote: > Hello, > This is Ibrahim Ethem Coskun from University of Nevada, Reno. I'm > currently working on an Internet Measurement project with Professor > Mehmet Hadi Gunes. We are modifying paris-traceroute's source code and > set the flow identifier of each packet (both sending and returning > packets) to a constant value for every traces. RIPE Atlas contains a complete re-implementation of the paris-traceroute concept that does not share any code with the original. That said, we publish our measurement source code, so you can try that as well. Our source can be found at https://atlas.ripe.net/get-involved/source-code/ and here is an article describing how it is structured: https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code Philip From philip.homburg at ripe.net Thu Mar 26 14:53:23 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 14:53:23 +0100 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87vbhnhoyx.fsf@pc8.berlin.quux.de> References: <5512E2C6.7030205@ripe.net> <87vbhnhoyx.fsf@pc8.berlin.quux.de> Message-ID: <55140F53.2040604@ripe.net> On 2015/03/26 14:23 , Jens Link wrote: > BTW: Are there any probes with site-local IPv6 addresses (fec0::/10). Yes I > know site local is deprecated for many years (RFC3879 is from 2004) but > some people still haven't noticed[1]. I also found some while checking the > Alexa list for odd AAAA records[2]. It looks like there are 11 probes that (also) have a site local address. It looks like some 6to4 device is causing it. Philip From aprado at topnet.it Thu Mar 26 15:26:58 2015 From: aprado at topnet.it (Antonio Prado) Date: Thu, 26 Mar 2015 15:26:58 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326183100.52b8ce28@natsu> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> Message-ID: <55141732.6010707@topnet.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/26/15 2:31 PM, Roman Mamedov wrote: > By that logic probes with just RFC-1918 IPs should not attempt any > IPv4 measurements either. roman, I don't compare v6 to v4. atlas should deal with ipv4 (nat44) in a different manner than ipv6 (nat66) - -- antonio -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlUUFzIACgkQuwElOCdao3/ttgCfVEIH6hIJX/lCR0+cIbQpncSA 8VYAnjaMsr47z+/qEMp/WW9d20SLWo0K =St9D -----END PGP SIGNATURE----- From ghane0 at gmail.com Thu Mar 26 15:37:35 2015 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 26 Mar 2015 22:37:35 +0800 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326183100.52b8ce28@natsu> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> Message-ID: On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov wrote: > > NAT66 is not (and should not be) common, however there is no harm in doing > an > inobtrusive check to see if it's deployed, or to collect stats on the > scale of > such deployments. I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at list.ak.cx Thu Mar 26 15:49:38 2015 From: ak at list.ak.cx (Andre Keller) Date: Thu, 26 Mar 2015 15:49:38 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> Message-ID: <55141C82.50205@list.ak.cx> Hi, On 26.03.2015 15:37, Sanjeev Gupta wrote: > I am part of a team deploying IPv6 in S E Asia, for enterprises in > their offices. As we do not have clarity on who the ISP will be, and > this will change frequently till v6 availability stabilises, use of > ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; > the NAT66 means that if the upstream IPv6 prefix address changes, all > the PCs do ot end up with new addresses. Why would you bother with NAT66 in this case? I mean using ULA for local traffic (like printing, filesharing, building control etc.) seems fine to me. For global connectivity you could just use SLAAC or DHCPv6 as an additional address? Does it really matter, if these additional addresses change from time to time? Regards Andr? From erey at ernw.de Thu Mar 26 15:42:39 2015 From: erey at ernw.de (Enno Rey) Date: Thu, 26 Mar 2015 15:42:39 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <551408F6.5030809@ripe.net> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> Message-ID: <20150326144239.GM61405@ernw.de> Hi, On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I forgot that RFC-6724 (Default Address Selection for Internet > Protocol Version 6) now explicitly lists ULAs, so indeed they would > not do any harm in trying to reach a dual-stack target. this would assume that a) the probes are supposed to follow RFC 6724. are they? b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind] that said I concur with the approach laid out in an earlier mail by Philip: "RIPE Atlas acts as a connectivity observatory. A ULA is the equivalent of an unconnected node. It is not broken; it is, by design, limited to local connectivity, and should always be that way. If a device has no global IPv6 address, it should be regarded as IPv6 incapable, not IPv6 broken." best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From ghane0 at gmail.com Thu Mar 26 16:03:51 2015 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 26 Mar 2015 23:03:51 +0800 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <55141C82.50205@list.ak.cx> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <55141C82.50205@list.ak.cx> Message-ID: On Thu, Mar 26, 2015 at 10:49 PM, Andre Keller wrote: > > > On 26.03.2015 15:37, Sanjeev Gupta wrote: > > I am part of a team deploying IPv6 in S E Asia, for enterprises in > > their offices. As we do not have clarity on who the ISP will be, and > > this will change frequently till v6 availability stabilises, use of > > ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; > > the NAT66 means that if the upstream IPv6 prefix address changes, all > > the PCs do ot end up with new addresses. > > Why would you bother with NAT66 in this case? I mean using ULA for local > traffic (like printing, filesharing, building control etc.) seems fine > to me. For global connectivity you could just use SLAAC or DHCPv6 as an > additional address? Does it really matter, if these additional addresses > change from time to time? The idea is to stay in known territory, and replicate what the client 's team knows first. With ULA and a NAT66 device, their network policies can be implemented "the way we have always done this"'; ie all outgoing allowed (mapped onto a unique global address, with the lower 64 bits the same), and all incoming blocked except where authorised. With IPv4, they use NAT and PAT. With IPv6, they no longer need to do PAT. At sometime in future, once they have experience with v6, hopefully a better-thought-out firewall policy can be implemented. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Mar 26 16:30:33 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 16:30:33 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326144239.GM61405@ernw.de> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326144239.GM61405@ernw.de> Message-ID: <55142619.6020107@ripe.net> On 2015/03/26 15:42 , Enno Rey wrote: > On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote: >> I forgot that RFC-6724 (Default Address Selection for Internet >> Protocol Version 6) now explicitly lists ULAs, so indeed they would >> not do any harm in trying to reach a dual-stack target. > > this would assume that > > a) the probes are supposed to follow RFC 6724. are they? > b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind] My statement was meant to reflect on whether announcing ULAs when there is only IPv4 internet connectivity would harm a 'normal' internet user. It was not meant to make a statement about the probes. Probes are complicated in this aspect. For some parts of the probe functionality the stub resolver in the c library is used. This is uClibc except on anchors where it is glibc. Then there are measurements where the probe has to resolve a name as part of the measurement. In that case, the stub resolver in libevent is used. Finally, for most of the measurements the probe receives IP addresses and not DNS names, so there is no issue with destination selection. For all measurements it is up to the Linux kernel to select a suitable source address. Note that all measurements are explicitly directed to measure either IPv4 or IPv6, so there can be no confusion there. Philip From lists at quux.de Thu Mar 26 16:43:31 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 16:43:31 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <55141C82.50205@list.ak.cx> (Andre Keller's message of "Thu, 26 Mar 2015 15:49:38 +0100") References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <55141C82.50205@list.ak.cx> Message-ID: <87384rhiho.fsf@pc8.berlin.quux.de> Andre Keller writes: > Why would you bother with NAT66 in this case? I mean using ULA for local > traffic (like printing, filesharing, building control etc.) seems fine > to me. For global connectivity you could just use SLAAC or DHCPv6 as an > additional address? Using both ULA and global addresses may / will confuse some operating systems and applications. I haven't seen it for my self but while researching this topic for a customer all I found was "DO NOT DO THIS IT WILL BREAK THINGS!" Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From rm at romanrm.net Thu Mar 26 17:51:01 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 21:51:01 +0500 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87384rhiho.fsf@pc8.berlin.quux.de> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <55141C82.50205@list.ak.cx> <87384rhiho.fsf@pc8.berlin.quux.de> Message-ID: <20150326215101.52d5f65b@natsu> On Thu, 26 Mar 2015 16:43:31 +0100 Jens Link wrote: > Using both ULA and global addresses may / will confuse some operating > systems and applications. I haven't seen it for my self but while > researching this topic for a customer all I found was "DO NOT DO THIS IT > WILL BREAK THINGS!" Nope it will absolutely not. Whatever you have been reading, was written either by a somewhat misinformed person (putting it mildly), or you maye have misread/misunderstood something. Feel free to provide any links to where this is claimed. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rm at romanrm.net Thu Mar 26 17:53:01 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 21:53:01 +0500 Subject: [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <551408F6.5030809@ripe.net> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> Message-ID: <20150326215301.336620ef@natsu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 26 Mar 2015 14:26:14 +0100 Philip Homburg wrote: > > Nothing really surprising about this. There is simply no IPv6 > > offered by the ISP, and many ISPs still do not begin to deploy IPv6 > > and only promise (if even that) for months and years. > > But is that a good reason for a CPE to start announcing IPv6 prefixes? Sure, why not. Nobody is surprised when a CPE with no Internet uplinks configured or operating still provides DHCPv4 server to the LAN, giving out RFC-1918 IPs. > > And imagine some future IPv6-only client device. With ULA it could > > access local services of the user's LAN (for example files shared > > from a NAS), if there is no need for it to access anything on the > > Internet. Trying to use LLs for this and lugging around > > "%interface" everywhere is not an acceptable answer. > > Link local was supposed to solve the 'dentist office' problem where > there is no router. They really don't. Barely any (if any at all) client software supports explicitly specifying the interface identifier along with the IP or hostname, or does so in a consistent manner. LL IPs are not usable in any form by the user, aside from pinging from the command line (and even then, it's bothersome to not forget to specify the interface all the time). Even if there's some mDNS in operation, the proverbial dentist still can't be expected to be typing "http://printer.local%eth0/" into their web browser (assuming that would have been supported in the first place...) - -- With respect, Roman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlUUOW0ACgkQTLKSvz+PZwjsGgCcCLYysHqeJwNK+LrcTiFXwtFf BmQAn2d3QetdCRGw8mRh7Aq0FW8gww6Q =G6jE -----END PGP SIGNATURE----- From furry13 at gmail.com Thu Mar 26 18:10:59 2015 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 26 Mar 2015 18:10:59 +0100 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326215101.52d5f65b@natsu> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <55141C82.50205@list.ak.cx> <87384rhiho.fsf@pc8.berlin.quux.de> <20150326215101.52d5f65b@natsu> Message-ID: On Thu, Mar 26, 2015 at 5:51 PM, Roman Mamedov wrote: > On Thu, 26 Mar 2015 16:43:31 +0100 > Jens Link wrote: > >> Using both ULA and global addresses may / will confuse some operating >> systems and applications. I haven't seen it for my self but while >> researching this topic for a customer all I found was "DO NOT DO THIS IT >> WILL BREAK THINGS!" > > Nope it will absolutely not. This is a very strong statement ;) >Whatever you have been reading, was written > either by a somewhat misinformed person (putting it mildly), or you maye have > misread/misunderstood something. Or those people have to deal with hosts which did not implemented RFC6724 and used default address selection algorithm as it is defined in RFC3483. -- SY, Jen Linkova aka Furry From rm at romanrm.net Thu Mar 26 18:33:25 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 22:33:25 +0500 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <55141C82.50205@list.ak.cx> <87384rhiho.fsf@pc8.berlin.quux.de> <20150326215101.52d5f65b@natsu> Message-ID: <20150326223325.421294f0@natsu> On Thu, 26 Mar 2015 18:10:59 +0100 Jen Linkova wrote: > >> researching this topic for a customer all I found was "DO NOT DO THIS IT > >> WILL BREAK THINGS!" > > > > Nope it will absolutely not. > > This is a very strong statement ;) Because it is true; and verified personally by usage of ULA+GUA for years on diverse server and client devices and operating systems. Not "something I read on the Internet". > >Whatever you have been reading, was written > > either by a somewhat misinformed person (putting it mildly), or you maye have > > misread/misunderstood something. > > Or those people have to deal with hosts which did not implemented > RFC6724 and used default address selection algorithm as it is defined > in RFC3483. Perhaps you meant https://tools.ietf.org/html/rfc3484; and even by that RFC, the "longest-matching prefix" rule 8 would prevent ULA from being selected over GUA as the outgoing address for connection to a GUA IP in case when the node has both (as in the situation we're discussing now), since fc00::/7 has zero matching leading bits with 2000::/3. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From klaus.mailinglists at pernau.at Fri Mar 27 09:30:23 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Fri, 27 Mar 2015 09:30:23 +0100 Subject: [atlas] probes on VMs Message-ID: <5515151F.3080504@pernau.at> Hi! I just found an old thread about virtual probes: https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000849.html I second the problems of virtual hosts and that the results may not as good as other probes result, but there is a big advantage for virtual probes - I can host them in the cloud. For example, I just wanted to debug routing issues from the Microsoft Cloud in Brazil to our server. Unfortunately there are no probes in this Cloud's AS. With a virtual probe it would be quite easy. I order an VM with Microsoft, and have my probe in the chosen datacenter. The probe could be tagged with "VM" to show that it is running on shared resources. Of course the VM will produce extra costs, but there may be sponsors, and the smallest VM is usually enough. For example , one possibility would be, that the sponsor donates the money, e.g. 10-20? per month, and chooses the cloud location. RIPE will then rent the VMs and run the probes. With several sponsors we could get a nice cloud coverage, and we could deploy probes in networks where the provider does not want to hosts physical probes. regards Klaus From jon.brewer at gmail.com Fri Mar 27 11:34:36 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Fri, 27 Mar 2015 11:34:36 +0100 Subject: [atlas] probes on VMs In-Reply-To: <5515151F.3080504@pernau.at> References: <5515151F.3080504@pernau.at> Message-ID: I have non-atlas probes at all EC2 centres. Definitely support virtualised Atlas. On Friday, March 27, 2015, Klaus Darilion wrote: > Hi! > > I just found an old thread about virtual probes: > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000849.html > > I second the problems of virtual hosts and that the results may not as > good as other probes result, but there is a big advantage for virtual > probes - I can host them in the cloud. > > For example, I just wanted to debug routing issues from the Microsoft > Cloud in Brazil to our server. Unfortunately there are no probes in this > Cloud's AS. With a virtual probe it would be quite easy. I order an VM > with Microsoft, and have my probe in the chosen datacenter. The probe > could be tagged with "VM" to show that it is running on shared resources. > > Of course the VM will produce extra costs, but there may be sponsors, > and the smallest VM is usually enough. For example , one possibility > would be, that the sponsor donates the money, e.g. 10-20? per month, and > chooses the cloud location. RIPE will then rent the VMs and run the > probes. With several sponsors we could get a nice cloud coverage, and we > could deploy probes in networks where the provider does not want to > hosts physical probes. > > regards > Klaus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.mailinglists at pernau.at Fri Mar 27 12:04:21 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Fri, 27 Mar 2015 12:04:21 +0100 Subject: [atlas] Create new measurement from old measurment Message-ID: <55153935.9050109@pernau.at> Hi! Is there a simple way in the webinterface to start a new measurement identical to an old one? (just duplicate them with new start-stop settings, in my case I want to duplicate one-off measurements) Thanks Klaus From tjc at ecs.soton.ac.uk Fri Mar 27 14:44:24 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:44:24 +0000 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326144239.GM61405@ernw.de> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326144239.GM61405@ernw.de> Message-ID: Hi, > On 26 Mar 2015, at 14:42, Enno Rey wrote: > > On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I forgot that RFC-6724 (Default Address Selection for Internet >> Protocol Version 6) now explicitly lists ULAs, so indeed they would >> not do any harm in trying to reach a dual-stack target. > > this would assume that > > a) the probes are supposed to follow RFC 6724. are they? > b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind] If RFC 6434 (IPv6 Node Requirements) is being followed then RFC 6724 (as RFC 3484-bis) MUST be followed. But older implementations may only support RFC 3484. Further, some implementations appear to do other things (as I believe OS X does, with its preferences for IPv4 vs IPv6). Tim From tjc at ecs.soton.ac.uk Fri Mar 27 14:46:56 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:46:56 +0000 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 14:37, Sanjeev Gupta wrote: > > On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov > wrote: > > NAT66 is not (and should not be) common, however there is no harm in doing an > inobtrusive check to see if it's deployed, or to collect stats on the scale of > such deployments. > > I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses. Technically, I think you mean NPTv6, as per RFC 6296. It?s disappointing but not unexpected that sites are doing this. The homenet approach is that hosts are multi-addressed with ULA and globals. They use ULAs internally, which provides a decent level of renumbering protection, and globals externally. Having a single IP address is IPv4 thinking. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Fri Mar 27 14:49:36 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:49:36 +0000 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326215301.336620ef@natsu> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326215301.336620ef@natsu> <202B3D0B-6B29-4506-A322-4A0FAC147BE8@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 16:53, Roman Mamedov wrote: > > Signed PGP part > On Thu, 26 Mar 2015 14:26:14 +0100 > Philip Homburg wrote: > > > > Nothing really surprising about this. There is simply no IPv6 > > > offered by the ISP, and many ISPs still do not begin to deploy IPv6 > > > and only promise (if even that) for months and years. > > > > But is that a good reason for a CPE to start announcing IPv6 prefixes? > > Sure, why not. Nobody is surprised when a CPE with no Internet uplinks > configured or operating still provides DHCPv4 server to the LAN, giving out > RFC-1918 IPs. > > > > And imagine some future IPv6-only client device. With ULA it could > > > access local services of the user's LAN (for example files shared > > > from a NAS), if there is no need for it to access anything on the > > > Internet. Trying to use LLs for this and lugging around > > > "%interface" everywhere is not an acceptable answer. > > > > Link local was supposed to solve the 'dentist office' problem where > > there is no router. > > They really don't. Barely any (if any at all) client software supports > explicitly specifying the interface identifier along with the IP or hostname, > or does so in a consistent manner. LL IPs are not usable in any form by the > user, aside from pinging from the command line (and even then, it's bothersome > to not forget to specify the interface all the time). Indeed. > > > Even if there's some mDNS in operation, the proverbial dentist still can't be > expected to be typing "http://printer.local%eth0/" into their web browser > (assuming that would have been supported in the first place?) With the work in the IETF dnssd WG, such service discovery may happen over a wider scope (multi-link), see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00 . But the address advertised would then be greater scope too. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ghane0 at gmail.com Fri Mar 27 17:12:41 2015 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Sat, 28 Mar 2015 00:12:41 +0800 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: On Fri, Mar 27, 2015 at 9:46 PM, Tim Chown wrote: > > Technically, I think you mean NPTv6, as per RFC 6296. > It?s disappointing but not unexpected that sites are doing this. > The homenet approach is that hosts are multi-addressed with ULA and > globals. They use ULAs internally, which provides a decent level of > renumbering protection, and globals externally. > Having a single IP address is IPv4 thinking. > Tim, thank you for the reference, we are using something close-to-but-not RFC6296. The reason we are not saying "RFC 6296" is that in the design that is being implemented, we do not want to claim compliance at all with a standard, but ask the client if he understands and approves of the design. We had an issue in an earlier implementation when the Windows server team was worried that nodes with two IPv6 addresses might pollute and confuce dynamic updates in the AD DNS. No one wanted to test this, rather than delay the IPv6 rollout, we dropped global IPs in the internal network. I am a vice-chair of the IPv6 Forum Singapore Chapter, and my focus is to roll out more and more IPv6. Numbers, Sir, not Quality! -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo at google.com Fri Mar 27 18:56:13 2015 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 27 Mar 2015 12:56:13 -0500 Subject: [atlas] [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: On 27 Mar 2015 9:13 am, "Sanjeev Gupta" wrote: >> Technically, I think you mean NPTv6, as per RFC 6296. >> It?s disappointing but not unexpected that sites are doing this. >> The homenet approach is that hosts are multi-addressed with ULA and globals. They use ULAs internally, which provides a decent level of renumbering protection, and globals externally. >> Having a single IP address is IPv4 thinking. > > Tim, thank you for the reference, we are using something close-to-but-not RFC6296. That's not a recommended deployment strategy. A much better strategy is the one recommended by RFC 7368. Bear in mind that RFC 6296 is classified as experimental, and to my knowledge is not used by any other ISP in this way. IIRC it was originally rushed through the prices due to a very unique situation in Japan, and even there it is used to convert between two different global prefixes, not ULA. Using NPTv6 will break applications, such as video chat clients, which are built on the assumption that IPv6 does not use NAT and thus in IPv6 implement only firewall traversal but not NAT traversal. That assumption is true in the vast majority of IPv6 deployments, so those apps may never support this more of operation. Also - if you're using ULAs, be aware that ULAs are specified to be globally unique, i.e. all the ULA prefixes used in your network should be different from all the ULA prefixes used elsewhere in the world. ULA achieves this by requiring that ULA prefixes be generated randomly to avoid collisions. If you're not doing this, you may encounter other forms of breakage. "It works like this in IPv4" doesn't means it will work in IPv6. In IPv4, virtually everybody uses NAT. In IPv6, virtually nobody does. Why can't you provide global IPv6 addresses? Most IPv6 deployments have to deal with IPv6 prefix changes, and none that I'm aware of have chosen to use ULA as a result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.mailinglists at pernau.at Sat Mar 28 14:22:45 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Sat, 28 Mar 2015 14:22:45 +0100 Subject: [atlas] probes on VMs In-Reply-To: <5515151F.3080504@pernau.at> References: <5515151F.3080504@pernau.at> Message-ID: <5516AB25.8010905@pernau.at> Although I still like the idea of virtual probes, I found out that it wouldn't help me in this case, as Microsoft's cloud block ICMP traffic. :-( regards Klaus On 27.03.2015 09:30, Klaus Darilion wrote: > Hi! > > I just found an old thread about virtual probes: > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000849.html > > I second the problems of virtual hosts and that the results may not as > good as other probes result, but there is a big advantage for virtual > probes - I can host them in the cloud. > > For example, I just wanted to debug routing issues from the Microsoft > Cloud in Brazil to our server. Unfortunately there are no probes in this > Cloud's AS. With a virtual probe it would be quite easy. I order an VM > with Microsoft, and have my probe in the chosen datacenter. The probe > could be tagged with "VM" to show that it is running on shared resources. > > Of course the VM will produce extra costs, but there may be sponsors, > and the smallest VM is usually enough. For example , one possibility > would be, that the sponsor donates the money, e.g. 10-20? per month, and > chooses the cloud location. RIPE will then rent the VMs and run the > probes. With several sponsors we could get a nice cloud coverage, and we > could deploy probes in networks where the provider does not want to > hosts physical probes. > > regards > Klaus > > From colinj at mx5.org.uk Sat Mar 28 14:30:54 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 28 Mar 2015 13:30:54 +0000 Subject: [atlas] probes on VMs In-Reply-To: <5515151F.3080504@pernau.at> References: <5515151F.3080504@pernau.at> Message-ID: <1EADCD46-73C1-41D0-ACD8-5BD113F39418@mx5.org.uk> As one who supported this in the first place I think definitely should be taken up a due to cost saving and b due to power savings. the virtual machine may affect measurement times to a extent but you need to understand that there maybe virtual routers/virtual firewalls in the network path so don?t blame just the source vm machine also virtual probes could help to identify vm environment performance problems Colin > On 27 Mar 2015, at 08:30, Klaus Darilion wrote: > > Hi! > > I just found an old thread about virtual probes: > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000849.html > > I second the problems of virtual hosts and that the results may not as > good as other probes result, but there is a big advantage for virtual > probes - I can host them in the cloud. > > For example, I just wanted to debug routing issues from the Microsoft > Cloud in Brazil to our server. Unfortunately there are no probes in this > Cloud's AS. With a virtual probe it would be quite easy. I order an VM > with Microsoft, and have my probe in the chosen datacenter. The probe > could be tagged with "VM" to show that it is running on shared resources. > > Of course the VM will produce extra costs, but there may be sponsors, > and the smallest VM is usually enough. For example , one possibility > would be, that the sponsor donates the money, e.g. 10-20? per month, and > chooses the cloud location. RIPE will then rent the VMs and run the > probes. With several sponsors we could get a nice cloud coverage, and we > could deploy probes in networks where the provider does not want to > hosts physical probes. > > regards > Klaus > > From gary at garygapinski.com Sun Mar 29 09:33:32 2015 From: gary at garygapinski.com (Gary Gapinski) Date: Sun, 29 Mar 2015 07:33:32 +0000 Subject: [atlas] NAT conntrack invalid ICMP(v4) type 11 code 0 packets dropped by edge router Message-ID: <5517AACC.70107@garygapinski.com> An HTML attachment was scrubbed... URL: From BECHA at ripe.net Sun Mar 29 23:49:12 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Sun, 29 Mar 2015 23:49:12 +0200 Subject: [atlas] Short and immediate report from the RIPE Atlas hackathon Message-ID: <55187358.1000503@ripe.net> We had the first RIPE Atlas hackathon! Three days of intensive coding, cooperating, learning, connecting and having fun (& surviving massive power outage on Friday in Amsterdam) - - and the results have bee impressive! Ten final projects have been presented, and four have been chosen as worthy of the awards: 1. Disco: Combining the visalization of disconnection-events with localized Twitter feed & live weather data 2. Spatial Bucketing of RIPE Atlas Probes on Map Projections (aka Picketty ? making the global probe selection more equal) 3. Traceroute stability check & BGP+traceroute (two projects sharing the 3rd place) We had 24 participants & 1 no-show, 6 jury members and 11 support staff (coincidentally: 42!) On behalf of the community, we are grateful to Comcast for sponsoring prizes and travel expenses, hackerspace Technologia Incognita for the inspiring location on Friday, and to RIPE NCC for the office facilities during the weekend, staff support, food & drinks & amazing data & tools & platform of RIPE Atlas. On behalf of the organizers (RIPE NCC & Comcast), we are grateful to everyone who took part & contributed, as well as to their family & employers, who let them get away for the weekend of combined work&fun. Longer and more detailed report will follow, once we all get some sleep & collect our notes from tweets, IRC, mailing list & pieces of papers. Cheers, Vesna From axel.pawlik at ripe.net Mon Mar 30 07:09:31 2015 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 30 Mar 2015 07:09:31 +0200 Subject: [atlas] Short and immediate report from the RIPE Atlas hackathon In-Reply-To: <55187358.1000503@ripe.net> References: <55187358.1000503@ripe.net> Message-ID: <5518DA8B.806@ripe.net> Thanks Vesna, for this short report; I thought about it when I went to bed yesterday :-) Wonderful! Sounds like a really great event, and what an auspicious number that... Great initiative, can't wait to see the results. cheers, Axel On 29/03/2015 23:49, Vesna Manojlovic wrote: > We had the first RIPE Atlas hackathon! > > Three days of intensive coding, cooperating, learning, connecting and > having fun (& surviving massive power outage on Friday in Amsterdam) - > - and the results have bee impressive! > > Ten final projects have been presented, and four have been chosen as > worthy of the awards: > > 1. Disco: Combining the visalization of disconnection-events with > localized Twitter feed & live weather data > > 2. Spatial Bucketing of RIPE Atlas Probes on Map Projections (aka > Picketty ? making the global probe selection more equal) > > 3. Traceroute stability check & BGP+traceroute (two projects sharing the > 3rd place) > > We had 24 participants & 1 no-show, 6 jury members and 11 support staff > (coincidentally: 42!) > > On behalf of the community, we are grateful to Comcast for sponsoring > prizes and travel expenses, hackerspace Technologia Incognita for the > inspiring location on Friday, and to RIPE NCC for the office facilities > during the weekend, staff support, food & drinks & amazing data & tools > & platform of RIPE Atlas. > > On behalf of the organizers (RIPE NCC & Comcast), we are grateful to > everyone who took part & contributed, as well as to their family & > employers, who let them get away for the weekend of combined work&fun. > > Longer and more detailed report will follow, once we all get some sleep > & collect our notes from tweets, IRC, mailing list & pieces of papers. > > Cheers, > Vesna > > > > From dquinn at ripe.net Mon Mar 30 11:20:15 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 30 Mar 2015 11:20:15 +0200 Subject: [atlas] Create new measurement from old measurment In-Reply-To: <55153935.9050109@pernau.at> References: <55153935.9050109@pernau.at> Message-ID: <5519154F.5010706@ripe.net> We don?t really have a means of a completely /copying/ a measurement, but we do allow for re-selection of probes used for a previous measurement. In other words: Using the UI * Go to Create a new measurement * Define the same parameters (packets, size, etc.) as your older measurement * Select ?Reuse a set from an old measurement? * In the window that appears, type in the measurement id you wish to duplicate and then give the number of probes you want to use from that selection. To use all of them, you must give the total number of probes in that measurement. Using the API This is a lot easier, as you simply have to modify the |probes| value in your POST request. Say for example that your original measurement looked like this: | { "definitions": [ { "target": "example.com", "af": 6, "packets": 3, "size": 48, "description": "Ping measurement to example.com", "interval": 240, "resolve_on_probe": false, "type": "ping" } ], "probes": [ { "type": "area", "value": "WW", "requested": 50 } ], "is_oneoff": false } | Assuming that the old measurement had id |123456789|, The new one would be a near-copy save for the |probes| section: | { "definitions": [ { "target": "example.com", "af": 6, "packets": 3, "size": 48, "description": "Ping measurement to example.com", "interval": 240, "resolve_on_probe": false, "type": "ping" } ], "probes": [ { "type": "msm", "value": "123456789", "requested": 50 } ], "is_oneoff": false } | Note however that like every measurement you create, there?s no way to guarantee that every probe you request will be available. Especially for one-offs, if the probe is down or overly busy, such selected probe(s) won?t be allocated to your measurement. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Mon Mar 30 15:27:22 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 30 Mar 2015 15:27:22 +0200 Subject: [atlas] Create new measurement from old measurment In-Reply-To: <5519154F.5010706@ripe.net> References: <55153935.9050109@pernau.at> <5519154F.5010706@ripe.net> Message-ID: <55194F3A.2020508@ripe.net> One addendum to my explanation: we do have a ticket in our queue to enable outright cloning of measurements, so this will happen in the future. For now though, the method I outlined here should handle what you need. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Mar 30 17:23:18 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 30 Mar 2015 17:23:18 +0200 Subject: [atlas] NAT conntrack invalid ICMP(v4) type 11 code 0 packets dropped by edge router In-Reply-To: <5517AACC.70107@garygapinski.com> References: <5517AACC.70107@garygapinski.com> Message-ID: <55196A66.2060809@ripe.net> On 2015/03/29 9:33 , Gary Gapinski wrote: > I recently observed a (ICMP type 11 code 0) packet for which the > reported rejection was for ctr-nue13.atlas.ripe.net, for which target > there are several active measurements on the probe. An extract of recent > logs for the related address yielded > > Mar 27 13:43:18 edge kernel: [WAN_LOCAL-2-D]IN=eth0 OUT= MAC=24:a4:3c:05:20:a3:00:01:5c:45:9a:41:08:00 SRC=4.68.111.17 DST=76.188.130.183 LEN=96 TOS=0x00 PREC=0x00 TTL=58 ID=3881 PROTO=ICMP TYPE=11 CODE=0 [SRC=76.188.130.183 DST=78.46.48.134 LEN=68 TOS=0x00 PREC=0x00 TTL=1 ID=57079 PROTO=UDP SPT=20494 DPT=33441 LEN=48 ] > > Is this simply an unfortunate consequence of probe measurement artifacts > arriving outside of the 30-second conntrack window, or is my local > configuration adversely affecting such measurements? It seems to affect hop 9 of the traceroute to ctr-nue13. It is hard to say if the packet was really 30 seconds late or not. Philip From astrikos at ripe.net Mon Mar 30 18:10:32 2015 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 30 Mar 2015 18:10:32 +0200 Subject: [atlas] probes on VMs In-Reply-To: <1EADCD46-73C1-41D0-ACD8-5BD113F39418@mx5.org.uk> References: <5515151F.3080504@pernau.at> <1EADCD46-73C1-41D0-ACD8-5BD113F39418@mx5.org.uk> Message-ID: <55197578.7010400@ripe.net> Hi, thanks for bringing this up again. We will have to consider our options and come up with a way forward with this. We will let you know soon with our implementation plan. Kind Regards, Andreas Strikos RIPE NCC On 28/03/15 14:30, Colin Johnston wrote: > As one who supported this in the first place I think definitely should be taken up a due to cost saving and b due to power savings. > > the virtual machine may affect measurement times to a extent but you need to understand that there maybe virtual routers/virtual firewalls in the network path so don?t blame just the source vm machine > > also virtual probes could help to identify vm environment performance problems > > Colin > >> On 27 Mar 2015, at 08:30, Klaus Darilion wrote: >> >> Hi! >> >> I just found an old thread about virtual probes: >> https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000849.html >> >> I second the problems of virtual hosts and that the results may not as >> good as other probes result, but there is a big advantage for virtual >> probes - I can host them in the cloud. >> >> For example, I just wanted to debug routing issues from the Microsoft >> Cloud in Brazil to our server. Unfortunately there are no probes in this >> Cloud's AS. With a virtual probe it would be quite easy. I order an VM >> with Microsoft, and have my probe in the chosen datacenter. The probe >> could be tagged with "VM" to show that it is running on shared resources. >> >> Of course the VM will produce extra costs, but there may be sponsors, >> and the smallest VM is usually enough. For example , one possibility >> would be, that the sponsor donates the money, e.g. 10-20? per month, and >> chooses the cloud location. RIPE will then rent the VMs and run the >> probes. With several sponsors we could get a nice cloud coverage, and we >> could deploy probes in networks where the provider does not want to >> hosts physical probes. >> >> regards >> Klaus >> >> > From BECHA at ripe.net Tue Mar 31 11:57:17 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 31 Mar 2015 11:57:17 +0200 Subject: [atlas] New on RIPE Labs: Amsterdam Power Outage as Seen by RIPE Atlas In-Reply-To: <55195CE0.7050805@ripe.net> References: <55195CE0.7050805@ripe.net> Message-ID: <551A6F7D.2000104@ripe.net> Dear colleagues, As you might have heard, there was a power outage last week Friday in the north of The Netherlands, a country with a very high density of RIPE Atlas probes. This density provides us with some interesting data and visualisation. You can find more details on RIPE Labs: https://labs.ripe.net/Members/andreas_strikos/amsterdam-power-outage-as-seen-by-ripe-atlas Kind regards, Vesna From colinj at mx5.org.uk Tue Mar 31 16:14:09 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 31 Mar 2015 15:14:09 +0100 Subject: [atlas] New on RIPE Labs: Amsterdam Power Outage as Seen by RIPE Atlas In-Reply-To: <551A6F7D.2000104@ripe.net> References: <55195CE0.7050805@ripe.net> <551A6F7D.2000104@ripe.net> Message-ID: Very interesting. I managed to see the same type of heatmap outage info from a core radius server outage of a large isp in uk for adsl auth Colin > On 31 Mar 2015, at 10:57, Vesna Manojlovic wrote: > > Dear colleagues, > > As you might have heard, there was a power outage last week Friday > in the north of The Netherlands, a country with a very high density > of RIPE Atlas probes. > > This density provides us with some interesting data and visualisation. > > You can find more details on RIPE Labs: > > https://labs.ripe.net/Members/andreas_strikos/amsterdam-power-outage-as-seen-by-ripe-atlas > > Kind regards, > Vesna > > > > > From didonato at dia.uniroma3.it Tue Mar 31 20:24:19 2015 From: didonato at dia.uniroma3.it (Valentino Di Donato) Date: Tue, 31 Mar 2015 20:24:19 +0200 Subject: [atlas] Prototype of "Traceroute-consistency-check" completed Message-ID: <551AE653.8000908@dia.uniroma3.it> Hello everybody, just to be fair I completed my prototype with the idea reported in my presentation. Everything is on github here: https://github.com/vdidonato/Traceroute-consistency-check This is just a snapshot: Best, Valentino -- Valentino Di Donato Department of Engineering Roma Tre University Phone: +39.06.57333215 Fax: +39.06.57333612 www.dia.uniroma3.it/~didonato didonato at dia.uniroma3.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hgjihfba. Type: image/png Size: 173187 bytes Desc: not available URL: