You are here: Home > Publications > RIPE Labs > Marco Hogewoning > The Future of the IPv6 CPE Survey - More Input Needed

The Future of the IPv6 CPE Survey - More Input Needed

Marco Hogewoning — 24 Jan 2011
After 3 updates and a lot of progress on IPv6 in general, it is time to think about the next version of the IPv6 CPE survey. With an increased deployment of IPv6, we are seeking a way to make it easier for you to provide feedback and to present the data in a more structured way.

Introduction

Sorry it took a bit longer to publish the recent update of the IPv6 CPE matrix . Being busy with changing jobs, some urgent family business and the holiday season unfortunately meant that some things had to be pushed back.

But we didn't sit still completely: we read your comments on RIPE Labs and the mails you sent and thought about the future of this document and the way we publish updates. The current method is very time consuming and not always entirely fair: How do we fit a free text response into a single coloured box and how do we value it? Is a single comment sufficient to draw a conclusion about a certain product or version? How do we handle conflicting end user evaluations? What works for us might not work for you and vice versa. Some standards are still being worked on, others are new and only have seen limited deployment. As more and more people start converting their networks, the number of varieties will most likely increase even further. How do we cater for these slight variations when publishing the results?

Another important factor is the fact that by changing jobs, I lost access to my testbed. I still have some DSL lines with native dual-stack available, so I can do basic testing. This is a great solution when stuff works. But when it doesn't, it is hard to troubleshoot and debug if you don't have access to the remote end. So even more as before, we are dependent on other people to help us with testing and providing us with the results. If we want to be able to keep this going, more than ever this has to become a community project .

Building the survey together with you

To make it easier for you to respond and for us to gather and publish the data, we decided to turn this into a proper survey that we are planning to distribute as widely as possible. This will enable us to provide real statistical analysis of the feedback. Of course we still allow lots of room for free text and comments.

As the title states, we are seeking input on this:

  • What questions do you want us to ask?
  • Which is that one feature we should include?
  • What things do you find less interesting and could be removed?
Unfortunately, we will not be able to include every detail in the survey. We will strive to find the right balance between the number of questions and the time it will take you to respond.

We already received some suggestions for additional items and features. Although not really related to IPv6, we are planning to include questions about DNSsec support. Would someone be willing to write a short how-to on what to test and how to do this from the more popular OS flavours (windows/OS X/*nix)? We also plan to include more details on transitioning techniques like 6RD, DS-lite and others.

So, the floor is yours. If you have any comments or suggestions about what to include or not to include in this survey, please do not hesitate to leave a comment under this article or to contact us at labs _at_ ripe _dot_ net

We are aiming to announce the survey in a couple of weeks. By then we hope to have a better idea what type of information would be most useful for you. Both, the survey and the results will be published here on RIPE Labs. So stay tuned!

5 Comments

Anonymous says:
24 Jan, 2011 04:15 PM
When comparing products one also need to make sure that the DNS support also works. Having it all in one table is useful.
EDNS, TCP. Are ULA used to advertise the DNS servers?

ULA support: Prefix generation and memory across restarts? Learn from upstream via PD? automatic site border/internal router detection (same ULA /48 prefix on both interfaces is internal)? Is it added to the PD response?
Anonymous says:
25 Jan, 2011 05:15 AM
I would recommend documenting:
- what is the router's default hint for PD, and is it configurable
- does the router accept PD larger or smaller than asked?
- what is the default prefix on the router's LAN port
- does the router support prefix sub-delegation
Anonymous says:
27 Jan, 2011 03:38 PM
Hi Frank,

I understand your comments. However I have the feeling this information will be very hard to get for an average user. Especially finding out what the default hint is and wether it accepts something else might be hard to get when you have no access to the ISP backend.
Anonymous says:
25 Jan, 2011 11:15 AM
I would suggest you measure compliance with the individual requirements in:
https://datatracker.ietf.org/[…]/

(and yes I am biased. ;-))
Anonymous says:
27 Jan, 2011 03:40 PM
We will try and follow some parts, however I'll try and aim this slightly more to a 'user level' trying to get at much feedback as possible. Sticking to the draft to close might get into details people can't retrieve.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.