[ipv6-wg] RIPE 61 - IPv6 WG minutes - draft

Dear IPv6 working group,

These are the draft minutes from the IPv6 working group session at the
RIPE 61 meeting in Rome.

Please send any comments/corrections within the next 4 weeks.

Thanks!

--
Shane, Marco, and David
IPv6-wg chairs

-------

Minutes from RIPE 61
Working Group: IPv6
Status: Draft
Revision Number: 1

RIPE 61 IPv6 Working Group
Rome, 16 November 2010, 16:00 – 18:00
Co-Chairs: David Kessens, Marco Hogewoning, Shane Kerr

A: Administrative Matters

The session started on time. Shane Kerr welcomed the attendees and 
mentioned that it was his first time as co-chair of the IPv6 Working 
Group, while also introducing his co-chairs David Kessens and Marco 
Hogewoning. Since there were quite a few items on the agenda and the 
session could be running late, he proposed to go ahead and start with 
the first presentation.

There were no questions or comments from the audience.

B. Experiences From an IPv6-only World

Ari Keränen from Ericsson presented the work he conducted together with 
his colleague Jari Arkko about measurements in an IPv6-only environment, 
with IPv4 connectivity switched off completely.

The presentation is available at:
http://ripe61.ripe.net/presentations/140-ripe_rome_jari.pdf

A speaker from the audience commented on the fact that their company had 
tried an IPv6-only setup on the server side and they encountered several 
issues, the biggest being DNS. Investigating the problem, it turned out 
that a certain percentage of the visitors could not resolve IPv6 
addresses when that was the only option, therefore being unable to 
access the site even though the connection was fine.

Ari found the problem interesting, and replied that whether on the 
client or the server side, it was important to enable communication 
between the old and the new Internet on all levels. Also, trying to 
force a specific technology on the users would not be feasible; having 
only Google and Facebook work for them may go unnoticed by half but 
would certainly make the others unhappy.

Shank Kerr asked whether all the traffic for the experiment was directed 
through NAT64.

Ari replied that there were only a handful of people involved, and they 
had used his particular home network as one part of the setup, which 
meant that not everything could be switched over since some devices did 
not support IPv6.

Shane explained that the reason for his question was that since 
everything ended up translated to IPv4, it would be difficult to discern 
how much of the traffic was intended for the v4 or the v6 network.

Ari answered that there are different configurations of NAT64, so v4 
could be deployed only on the outside. A lot of their users were 
actually in this mode when accessing v4 destinations, however on the v6 
Internet they could attain end-to-end IPv6 connectivity. It worked well 
for their purposes, but perhaps that had something to do with their 
years of experience running dual-stack configurations.

Shane agreed and thanked Ari for his presentation.

C. Detecting (and fixing!), IPv6 Dualstack Brokenness

Tore Anderson from Redpill Linpro gave a presentation about his 
company's experience providing networking for customers and testing for 
broken IPv6 clients.

The presentation is available at:
http://ripe61.ripe.net/presentations/162-ripe61.pdf

Shane Kerr commented he had been following their work for a few months 
and it was very cool.

D. The Results on Introducing Native IPv6 at XS4ALL

Marco Hogewoning introduced himself as one of the co-chairs of the 
Working Group, and then presented an experiment his company, XS4ALL, is 
conducting running native IPv6 on a residential DSL network.

The presentation is available at:
http://ripe61.ripe.net/presentations/128-MH-RIPE61-IPv6-XS4ALL.pdf

Lorenzo Colitti from Google commented that the results were interesting, 
especially the fact that only ten percent of the users actually managed 
to get online using IPv6 -- probably the router firmware was to blame 
and an upgrade would have fixed it. However, the more important 
question, seeing as this was only a small-scale residential deployment, 
was how would this scale from 300 to 300,000 users -- since that is what 
the industry will have to do in the next couple of years.

Marco answered that at a certain point they will probably feel confident 
enough to have it on by default for all customers, and that that would 
be the biggest hurdle. The major block that prevents them from doing 
that is currently the amount of CPE's with broken (non-IPv6-ready) 
firmware, and those have a lifespan of around two to three years. That 
would mean that in the next three years most of that installed base 
would be replaced, and if they were confident enough that it wouldn't 
break anything they would "push the button" and turn it on for all their 
250,000 customers.

Henk Uijterwaal from the RIPE NCC commented that he was actually one of 
the 300 users involved in the experiment, and he had the system working 
but then the rest of his family started to complain about things not 
working, like the telephone. The conclusion would be that not every 
combination of hardware, modems and phones would work.

Marco replied that since the firmware they used on the modems in order 
to facilitate the experiment was new, it fixed some things -- like IPv6 
functionality -- but broke others in the process, like the VoIP system 
used by the phone. He also added that there was a benefit there, when 
people at home that can't do much about fixing the technical problems 
will push their vendors to do it and they in turn will start taking IPv6 
seriously.

Lorenzo Colitti was interested to find out how long it took for the 
whole project to be implemented, from the design phase onwards.

Marco answered that the design phase was completed in 2008. It took some 
time, mostly because they needed to test things properly. From a 
man-hour point of view it was pretty low, however they ran into issues 
with lawful requirements for interception under Dutch law -- they had to 
stall the project while waiting for the government systems to be fixed.

Lorenzo rephrased the question to ask how long it would take if someone 
was in Marco's position and was asked by their manager to implement IPv6 
on their network as soon as possible for all users.

Marco answered that without checks and in a hurry it could be done in a 
week, but in order to do a proper job it could take anywhere from three 
to six months. Since more and more vendors are implementing IPv6 in 
their equipment, the problem remains having enough deployment to iron 
out all the bugs, since there is very little feedback on what breaks. 
When the deployment will reach a lot of people, it will be a lot harder 
for the vendor to ignore bugs and more pressure to fix things.

Lorenzo concluded that it would then take around six months plus some 
time to make sure everything runs fine, and then asked if Marco's team 
was still pursuing this project.

Marco said that indeed they keep working on it, the technical 
infrastructure and basics being taken care of, but things like reverse 
delegation, for example, needs to be fixed. They also have some services 
that are not yet deployed on IPv6, but mostly what they do now is wait 
for the vendors to come up with quality firmware -- the network side is 
pretty much done.

There were no more questions or comments.

E. RIPE NCC Stats

Emile Aben from the RIPE NCC presented various statistics compiled using 
the data available to the NCC.

The presentation is available at:
http://ripe61.ripe.net/presentations/145-2010-11.ripe-61.ipv6-where-are-we.pdf

Emile also demonstrated a new service offered by the RIPE NCC where 
anyone can compare the penetration of IPv6 in specific countries or regions:
http://v6asns.ripe.net/v/6

Randy Bush inquired whether there were any privacy issues with the new 
service, since it included data about people visiting the website.

Emile answered that since the IP addresses of visitors would not be 
published there should be no concerns, but legal advice will be sought 
regarding that just in case.

Emile continued by presenting the current status of the "RIPEness" 
project and associated statistics.

A member of the audience asked if suggestions for the fifth star were 
still being accepted. Emile replied yes, and the audience member said 
that his suggestion would be to call the helpdesk of the ISP and ask "I 
have an IPv6 question", and if the answer would be "Yes, how can I help 
you?", then the fifth star should be awarded.

An audience speaker commented that this was the kind of material that 
decision makers like to look at, and asked if there was a disclaimer 
that this was easily measured external behaviour and of course being 
IPv6 ready, included lots of things that usually are not externally 
visible so that no new project will go along if it doesn't come with an 
explanation about how it would work with IPv6 or what the transition was.

Emile answered that they didn't currently have such a disclaimer, but it 
was a good suggestion to put it on; however it would be hard to get the 
necessary data.

Lorenzo Colitti from Google commented that the 2% figure of IPv6 
penetration was ten times higher than the number Google had derived from 
their own measurement -- which was 0.2%. They had also measured 0.1% in 
the beginning of January, which coincided with the 100% growth seen on 
the RIPE NCC statistics. Therefore, he asked that a very big disclaimer 
be put on these results since it was the kind of thing decision makers 
look at, and the population visiting the ripe.net site was highly 
self-selecting and far more likely to have IPv6 than the average user.

Emile agreed, mentioning that the ripe.net measurement was actually just 
one of several conducted, and the other sites had results closer to the 
Google number, far below 1%.

Lorenzo expressed his concern that the people seeing higher numbers 
would become complacent while ignoring the far worse reality.

Geoff Huston from APNIC commented that APNIC had been doing similar 
measurements, and their website presented the same bias towards 
technical visitors. Also, their services tended to be accessed by the 
same people repeatedly, so the measurement would have a very limited 
base. On the other hand, they had recently run the same measurement on a 
gaming site, which resulted in numbers that made the 0.2% seem extremely 
low. He then urged entities making measurements not to keep them closed, 
but open them towards the community, as biased or incomplete as they may 
be, since it is the only way to understand what is truly happening and 
the more data published, the better.

He than shared the interesting fact that of the v6 visitors coming to 
their site, around 70% were running 6to4, so whether the technical 
community liked 6to4 or not it was very widely used and a simple routing 
addition like routing 2002/16 through a local relay would help those 
users. Another surprising discovery was the very low usage rates of 
Teredo, it's slow speed compared to the alternatives and the fact that 
it broke connectivity when installed locally.

Shane Kerr intervened to announce that the discussion was running a 
little late and urged the participants to hurry up.

A member of the audience commented that they had checked their RIPEness 
status and they did not have the fourth star because they were not 
advertising EU blocks since they had no EU customers. They were however 
advertising US blocks, which meant they had a fully working v6 network 
that was not counted properly, and there probably were quite a few 
others in the community in the same situation.

Emile responded that the issue would be looked into.

Tore Anderson from Redpill Linpro commented in response to Geoff Huston 
that their numbers were available on their website, all that was needed 
was for someone to take them and create a graphic or statistic. Talking 
about Teredo, he explained that it is only done by Windows by default, 
some CPE implementing it but only a few. Also, Windows Internet 
Connection Sharing does not share it out using RA's, which means only 
applications running on Windows will try and use Teredo. As a final 
note, newer versions of Windows implement RFC3484, which de-preferred 
Teredo, so that would be one reason for the very low Teredo traffic 
measured.

Geoff Huston replied that the test they did targeted Teredo hosts by 
being IPv6 only -- even if it was de-preferred in dual-stack, if a 
resource would only advertise AAAA records then it would force IPv6 
usage and that's why they saw some answers rather than none at all.

Lorenzo Colitti added one final comment that when it came to numbers, it 
would be easy to publish statistics and graphs if that is what the 
community needs. He also expressed the fact that many in the industry 
are secretly hoping for 6to4 to go away, but the situation is not 
decided yet.

There were no more questions or comments.

F. Native IPv6 via xDSL – How to Tweak Your LNS

The following presentation was by Fredy Künzler from Init Seven AG, with 
practical examples and technical details about implementing IPv6 on a 
xDSL infrastructure.

The presentation is available here:
http://ripe61.ripe.net/presentations/160-Native-IPv6-via-xdsl-how-to-tweak-your-LNS_v0.3.pdf

Martin Levy from Hurricane Electric asked what the response of the 
telecom provider was when they asked for v6 support.

Fredy replied that they did not ask, since the telecom was not needed.

Martin asked for confirmation that the provider's collaboration was not 
required for such a setup on DSL, and Fredy confirmed that it was 
completely transparent.

Martin then continued by inquiring as to what the average telecom answer 
was when asking for v6. Fredy could not answer that question and 
requested members of the public to respond. A member of the audience 
commented that the usual response was that they mistake it for a 
question about TV and try to sell a TV bundle.

Lorenzo Colitti asked the same question he posed to Marco earlier -- how 
would they scale the setup from the 12 current users to the total number 
of supported users.

Fredy could not answer, explaining that was not their main focus in 
their business, and they did not have the high number of users as to 
have a scaling issue.

Marco Hogewoning intervened to answer Martin's previous question. He 
said the response from their telecom provider was "Cool, let us know how 
it works so we can copy it off". Martin asked whether the telecom 
actually owned Marco's company, to which he replied affirmative.

A member of the audience gave another response to Martin, keeping in 
mind that the situation was probably different in the European compared 
to the US market. He explained that the telecom provides the copper and 
a PPPoE service, which is then switched over L2TP to the ISP, so the 
layer 3 protocol is usually transparent; there were some bugs in 
equipment that prevented things from functioning correctly, but for the 
most part it was transparent for the telecom.

Another member of the audience noted that there was an issue with BT in 
the UK and the previously mentioned bugs, which was still not corrected 
because officially they do not support IPv6. Because of that such a 
deployment would be difficult in the UK, at least with BT as the provider.

A member of the audience commented that while he was a core network 
expert with expertise into the architectural aspects and less with the 
access network issues, he was quite positive there were large spots 
where actually transparent access was not available.

There were no further questions or comments.

G. Requirements for IPv6 in ICT Equipment

Jan Žorž and Sander Steffann gave a presentation about their proposal 
for a formal document published by the RIPE community that would help 
governments and other institutions to select IPv6-capable devices and to 
devise tenders and auctions in a way that would ensure future equipment 
procured would be IPv6 capable.

The presentation is available at:
http://ripe61.ripe.net/presentations/307-Jan_Zorz-IPv6WG-requirements-in-ICT.pdf

After Jan presented the proposal, he mentioned that there had been two 
consecutive versions of the draft and some response from the community. 
While items were added, the last call for discussion would end the 
following day, then the Chairs would decide if a new last-call was 
needed. He asked the audience if they thought the idea was useful and 
needed as a recommendation.

David Kessens introduced himself as one of the co-chairs of the Working 
Group and noted that the current thinking of the IPv6 Co-Chairs was that 
the following day they would have more information from the comments 
gathered after the session and then they would be better able to make a 
decision.

Jan thanked David and then asked Sander to present his own view on the 
issue.

Sander commented that he had heard from a lot of organisations wanting 
to deploy v6 but lacking the experience in the field that such a 
proposal would be appreciated. The recommendation was clear in what a 
device should support, by making it a requirement for v6 to perform on 
par with v4, while also including a section about the knowledge and 
skills necessary of the integrator. As such, it would constitute a good 
document to standardise v6 requests around.

Constanze Bürger from the German Ministry of the Interior commented in 
support of the proposal that from a Government point of view it was much 
appreciated and welcome since the vendors do not provide the necessary 
information, while Governments themselves do not know what to ask for. 
She also proposed improvements to the requirements, by going into more 
details than the RFC level, like a matrix that would match legal 
requirements and policies in the EU.

David Kessens intervened to ask for brevity since the time was already 
short, and proposed that further discussion regarding improvements 
should be continued on the mailing list or in person after the session 
ended.

Constanze reiterated their support and the necessity of the proposal.

Sander thanked her for the support and the input received and mentioned 
that he would like to see the proposal go through the process as quickly 
as possible, and perhaps implement further changes in a second version, 
since this was an open, ongoing process.

There were no further questions or comments.

This proposal is now a published RIPE Document:
http://www.ripe.net/ripe/docs/ripe-501.html

H. Update on Policy Proposal 2010-06

For the last presentation in the session, Marco Hogewoning returned to 
the stage together with Remco van Mook to present a policy proposal 
currently in the draft stage.

The presentation is available at:
http://ripe61.ripe.net/presentations/309-MH-RIPE61-2010-006.pdf

After giving the presentation, Marco explained that since he was one of 
the proposers, he would not do any Chair processing in this case, 
leaving it to David and Shane to make all the decisions.

Wilfried Woeber from ACOnet/Vienna University asked if there was any 
reason for doing the same statistics that were done on IPv4 with IPv6 
(like percentage of the usage of a block of addresses compared to the 
number of consumers or end points). He expressed the opinion that 
something like that would not be needed with IPv6 since there would be 
no real shortage.

Marco answered that at a certain point HD ratios need to be calculated, 
but it's more a matter of implementation. Since in the v4 case the 
statistics were not part of the policy and just a means of showing the 
usage of addresses, it was a good idea to copy that over to v6. Of 
course, if the consensus would be that there was no such need it could 
be amended.

Wilfried explained that he was referring to the dynamic component of DSL 
addresses and other surrounding issues, while admitting he had not 
studied the policy in detail.

Marco said that on the v4 version it was specifically stated "broadband 
user", and that implied 24/7 usage since a provider could not assign 
2,000 addresses with only 500 customers unless making another 
assignment. While such a policy was reasonable with IPv4, it would still 
work with IPv6, since a procedure was needed to have someone who was 
running out of a /32 be able to justify another one instead of simply 
asking for a /28 -- otherwise everyone could simply be assigned a /28 
from the beginning.

Wilfried commented that at the time he was working on an address plan 
for a large customer, and it looked like they would not use the same 
size for all end points but instead define three sized groups. He would 
have liked to see a mechanism to document such issues within the 
framework of the proposal.

Marco answered that the proposal text was only finished in that 
afternoon and it should be coming out, they were just waiting for the 
RIPE NCC to conduct an impact analysis. Afterwards it would be pushed to 
the mailing list. In the proposed version, it stated that one can nest 
objects but only up to one level -- that was to prevent people from 
going into the /128 level while allowing for instance a number of /48's 
to be grouped and another separate /48 to be split up in /64's.

David Kessens reiterated that Marco would not be involved in the 
discussions and decisions regarding this proposal, and that the current 
status was waiting for the RIPE NCC to conduct an impact analysis and 
then the document should be published, since it was already discussed 
quite a bit and it did not stir too many controversies. There would be a 
two-week review phase and another last call after that before the 
process will be finalised.

Marco remarked that they would involve multiple Working Groups and their 
Chairs in the discussion, the Database WG and Address Policy WG since it 
concerned them as well.

There were no other questions or comments.

As the presentations ended at 18:05, Shane Kerr thanked everyone present 
and asked for an open mike session. He also reminded the attendees that 
the session was already overtime.

Marco Hogewoning reminded the attendees of the mailing list for the IPv6 
Working Group:
http://www.ripe.net/mailman/listinfo/ipv6-wg

The address to contact the Working Group Co-Chairs:
ipv6-wg-chairs at ripe.net

Randy Bush commented that for the ones that have been around Internet 
technology for a while to notice the progress, things have really 
changed in the past few months, and even though we may not see 80% 
deployment of IPv6 it is on people's minds and the next months should be 
very interesting. He also praised Marco for his presentation.

Shane Kerr officially ended the session at 18:09 by wishing everyone a 
good night.