[ipv6-wg] Draft minutes of RIPE63

Dear colleagues,

Attached are the draft minutes of our working group session in Vienna at the RIPE63 Meeting. Please review them and if you have any corrections or comments, please post them to this list before Friday the 27th of January COB. If we haven't received any comments or corrections by that date, we will assume consensus and will ask the RIPE NCC to publish these as final.

Again many thanks to the RIPE NCC for their support in scribing the session.

Marco Hogewoning




RIPE 63
Scribe: Mirjam Kuehne
WG chairs: David Kessens, Shane Kerr, Marco Hogewoning
Date: 1 November 2011, 16:00 - 17:30
IPv6 WG meeting (first session)

Marco Hogewoning opens the IPv6-WG

1. Administrivia:

- Minutes of RIPE 61 have been circulated
- There was no IPv6-WG session at RIPE 62
- Thanks to the RIPE NCC for taking minutes at RIPE 63

2. Renumbering IPv6 - IETF 6RENUM WG
(Tim Chown, Wes George; presented by Shane Kerr)

The Address Policy WG asked the IPv6-WG for some advice about 
renumbering. Trying to avoid renumbering could be a reason for 
organisations to request PI space. Renumbering is considered to be 
difficult. But if renumbering would be very easy, then this wouldn't be 
a good reason for PI space (there might be others however).

The IETF 6RENUM WG is working on this topic. It was formed after a BoF 
at IETF 81.

There was some previous work done on IPv6 renumbering (see RFC 4192, RFC 
5887 and draft-chown-v6ops-renumber-thinkabout-05). The current work of 
the 6RENUM WG is focused on renumbering for enterprise networks, not ISP 
networks. But enterprises all get their Internet connectivity from 
somewhere - from ISPs. Many of them are in the RIPE community. Tim Chown 
is looking for feedback from this community. The first 6RENUM WG draft 
documents internal triggers to renumber. There is also a document 
providing a gap analysis.

Q&A:

James Blessing commented that IF you design your network properly in the 
first place, renumbering is fairly straightforward - it is still work, 
but it's straightforward.

Marco was wondering if it would help if this group would come up with a 
BCP about network design. Shane thought this would be a good idea 
(people usually appreciate RIPE BCPs).

Gert Doering (Spacenet and IPv6 user for many years) agreed with James: 
A large part of the pain can be avoided with a good network design. 
Don't hardcode IP addresses etc. A BCP document listing the dos and 
don'ts would be useful. On the other hand, we don't want to overlap with 
the IETF WG (would have to check that this is not part of their charter).

Marco emphasised that the IETF 6RENUM WG is mostly focused on enterprise 
networks. He suggested that the RIPE IPv6-WG could fill the gap and 
provide some documentation for ISPs.

Gert said he obviously thought about this also, because it is related to 
address policy.

Gert said he spent some thought on that as well, because obviously 
touches on Address Policy. Like I if he’s a small ISP and not 
multi‑homed yet but wants independent addresses and why not just 
renumber if you change upstream and?

One of the really painful things about renumbering an ISP network is you 
have to renumber your customers and that works for end users that are 
fully automated provisioned, like prefix delegation and stuff so there 
is no boxes to be touched and the box auto configures everything on 
connection anyway but it doesn't work at all for business ISPs where you 
have many configured firewalls and everything, so renumbering an ISP 
with business customers is nearly impossible. Gert said he’s done it two 
times and that it's nearly impossible. So this might be the reason why 
they have excluded ISPs from this scope. On the other hand, some parts 
of the ISPs are just an enterprise network, like server housing, DNS 
servers, firewalls and stuff, so there is overlap again.


Shane said there was a couple of different things going on, one being 
able to provide recommendations to people who are doing network design, 
maybe even in the case where you have customers perhaps recommending 
prefix delegation or whatever. But the other issue is the 
recommendations on the policy space, maybe clarifying in which cases PI 
space makes sense, for instance a small ISP with downstream customers or 
something like that.

Gert said that better defining the problem space, would certainly help 
making appropriate policy. Documenting different use cases could be 
helpful.

James commented that according to current policy, having PI IPv6 address 
space stops you from giving addresses to customers.

Gert said that this is correct and that it's an artefact of the history 
of PI address space policy. This will be discussed more in the Address 
Policy WG.

Maksym Tulyuk (AMS-IX) reported that at AMS-IX they renumbered from PI 
to PA IPv6 space and that this was not a big problem.

Marco clarified that this was a migration of a service network, not a 
customer network.

Benedikt Stockebrand said that when it comes to renumbering, the biggest 
problem is all the legacy equipment and configurations. You need to 
figure out first what the network is supposed to be doing before you 
renumber it.

Shane asked the audience if IPv6 provides any benefits at all when it 
comes to renumbering?

Benedikt said it is important that people realise how to pay for this in 
the long run.

Aaron Hughes (6connect) reported that in the ARIN region, a best current 
operational practices track was started. The first document described 
subnetting IPv6 for ISPs. We also said that they'd be happy to work on 
documentation for enterprises as well. These topics are discussed on the 
following mailing list: 
bcp-discuss at bind.com <mailto:bcp-discuss at bind.com
>


Aaron said he’d send more information to the RIPE IPv6-WG mailing list.

Jan Zorz wondered why the IETF created the 6RENUM WG.

Shane responded that it might be a little early to present their work 
since the WG has just started.

Gert responded to Shane's earlier question that renumbering in IPv6 is 
easier, because all stacks know how to handle multiple addresses at the 
same time. But from a planning point of view, it is the same.

ACTION WG chair: to send mail to the mailing list asking if there are 
volunteers to start on a renumbering BCP for ISPs and if people know if 
there is already work being done in this area.

3. Replacing ripe-501 (Jan Zorz, Sander Steffann)

See "Requirements for IPv6 in ICT Equipment": 

http://www.ripe.net/ripe/docs/ripe-501


ripe-501 was published a year ago and has already been translated into 
ten languages.Since then many requests for changes were received.

The document was a great success, but of course things can always be 
improved. New devices were added to the document. Specifications about 
load balancers were added. The compliance criteria were also simplified. 
There was a good discussion on the mailing list. The document is 
currently in last call.

Note that the document is meant as a template, don't just cut and paste 
bits and pieces.

Jan and Sander thanked Merike Kaeo for providing a lot of useful input.

Randy Bush (IIJ) had a question about the CPE diagram in the document.

Jan explained that the RFC written by Ole Troan was included as a 
mandatory requirement. The idea was not to duplicate Ole's work. If a 
CPE does not support this RFC, it should not be taken into account in 
the process.

Sander asked people to send comments to the mailing lists to specify if 
this comment should be included right now (which means extending the 
last call) or if it is OK to include it in the next version. The Last 
Call for the current version of the document ends next week, 10 November 
2011.

Tahar Schaa (consultant supporting German government) asked what their 
plans were to include source address validation improvements.

Sander confirmed that it would be included in the document. But it is up 
to the tender initiator to ask for this requirement or not.

4. Horses for courses - like IPv6 profiles for German Administration 
(Constanze Buerger, Bundesministerium des Inneren, Germany)

The prepsentation is available at: 

http://ripe63.ripe.net/presentations/74-2011_RIPE_63_de.government_Constanze_Buerger.pdf



Maksym asked if the files Constanze mentioned in her presentation are 
publicly available.

Constance said this has not yet been decided.

Alexander Isavnin from Russia wondered how much this process is costing 
the German taxpayers?

Constance responded that they are just coordinating the IPv6 address 
space allocated to them and the deployment to all federal governments 
and institutions. But it will take a long time until this is finished.

Alexander asked if each department has its own budget.

Constance confirmed that this is the case. She also explained that it is 
not so easy to convince people to cooperate. Every municipality can do 
their own thing. That means she and her team have to do a lot of 
convincing, but they cannot force the others to cooperate.

Jan Zorz thanked Constanze for considering ripe-501 as a basis for her 
work and mentioned that there will be a new version (and a new number). 
He asked that Constanze and Tahar make their own adjustments in their 
documentation when the new version comes out.

Tahar clarified that ripe-501 goes into the same direction as their work 
is going already anyway. So yes, a few adjustments will have to be made, 
but it's not that difficult, because they are aware of the changes.

Jan asked if Constanze or Tahar are aware of any other governments 
following the German example.

Tahar said he believed that Spain is following a similar process.

Martin Levy (Hurricane Electric) thought it would be better to rephrase 
the earlier question: “What would this cost if you were to ignore IPv6?”.

Constance explained that they tried to analyse the costs so that they 
can put some pressure on the leadership. But it turned out to be very 
difficult, because the government and the network is so heterogeneous. 
In the end they had to stop the process analysing the costs.

Tahar added that Germany, due to its constitution, is a complex country. 
The costs are held and managed in each state and each municipality. All 
that can be done really is to provide the first steps and some 
supporting documentation. He saw two main motivations to deploy IPv6:


1. Address renumbering (there is a long history of using IPv4 address, 
mostly private, which means that there is now a horrible network of 
cascading NAT layers.


Some of the networks have been renumbered up to four times and this is 
very costly. Deploying IPv6 will solve these problems.


2. If one wants to set up a telephone infrastructure in Germany today, 
it is only possible to buy VoIP telephony. What about one office wants 
to call another and the addresses clash? You can better start using 
public (IPv6) addresses.

In conclusion, the question is not: What does it cost to do it, but what 
does it cost not to do it?

Constance said yes, just do it.

4. Status of ADSL Deployment in the XS4All network (Timo Hilbrink, XS4All)

The presentation is available at: 

http://ripe63.ripe.net/presentations/75-th-ipv6-ripe63-20111101.pdf


Maksym asked why the MTU on one of the slides was set to 1452, why it 
was so low and whether it was part of his implementation.

Timo said yes.

Gert applaud Timo and XS4All on this. He said it was great to see one 
mass-market provider go forward with this. He said he hopes that there 
will also be more users in Germany any time soon.

Andy Davidson (Hurricane Electric) asked if Timo knew the retail prices 
of the new CPEs that include IPv6.

Timo said they were around EUR 100.

Andy concluded that that price is coming down all the time, which is great.

5. Lightning Talks

5.1. Results of the 2011 Global IPv6 Deployment Monitoring Survey (Chris 
Buckridge for Maarten Botemann)

The presentation is available at: 

http://ripe63.ripe.net/presentations/114-ipv6-survey-BUCKRIDGE.pdf



5.2. Effects of Capacity Building on IPv6 Adoption and Deployment (Marco 
Hogewoning, RIPE NCC)

The presentation is available 
at:
http://ripe63.ripe.net/presentations/66-MH-RIPE63-Capacity-LT.pdf



5.3. Stateless IPv4 over IPv6 in 5 minutes (Ole Troan, Cisco)

The presentation is available 
at:
http://ripe63.ripe.net/presentations/40-RIPE63-MAP-lightning.pdf



Jan, as a member of the MAP (A+P) architecture team, asked attendees if 
they felt that well-known ports must never be allocated to a user or if 
the user should have the opportunity to use well-known ports.

Ole responded that you could give users that are not happy with the 
default setting a full IPv4 address.

Benedikt explained that users shouldn't need low ports. He wondered if 
prolonging IPv4 is really worth the effort. The majority of people don't 
want to run a server at home. For those who want to, they will switch to 
IPv6 shortly. Those who use an IPv4 server at home will get some IPv4 
addresses from somewhere. It's not something you want to provision for 
mass customer products.

Jan said he believed stateless A+P is worthwhile because we don't want 
CGNs.

Benedikt disagreed and said he wants CGN and wants it to hurt that much 
that people will use native IPv6 in the end.

Jari Arkko (Eriksson) pointed out that there are trade-offs: If you are 
doing port division per customer on an static basis for customers, the 
power user and a small user get the same service, which neither of them 
will be happy with; we will pay in any case.

6. IANA Reserved IPv4 prefixes for shared CGN space (David Kessens)

The presentation is available at: 

http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedaddresspace.pdf
 
<
http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedaddresspace.pdf
> 




Gert wondered which address space they were going to use.

David agreed that this is of course an issue. However, since this 
proposal was well received in the ARIN region, it was suggested to use a 
/10 out of ARINs' address space.

Jari reported that he was one of the IESG members who reviewed this 
document and said he had a couple of concerns. Apart from the policy 
issues that are down to the RIR communities to decide, there are some 
issues with this particular proposal. What's the affect on the ISP ("My 
device works well now, but does it have negative affects on other parts 
of the network?"). He urged people to participate in this discussion and 
check if this would break anything.

Kurtis Lindquist commented that this whole process seemed a little weird 
(between one RIR and the IAB and the IESG).

Martin Levy said it is interesting that they were talking about IPv4 and 
CGNs a lot instead of about IPv6.

ACTION: It was decided to defer the topic of 
draft-weil-shared-transition-space-request to the mailing list.

7. IPv6 Speed Dating

Marco asked the audience how many people in the room have deployed IPv6 
(about half of the room). The other half is busy deploying it. He 
further asked those who are busy deploying it, what the biggest 
challenge is they face in the process?

A speaker from the audience said that the biggest challenge is to 
convince the management. The management thinks it is too expensive.

Marco asked those who deployed IPv6 how they passed that hurdle.

Andy said to just do it anyways.

Jan Zorz responded that he gave a 45 minute presentation earlier 
explaining how to convince the management.

Benedikt suggested to ask the management: "What's the business case of 
an earth quake?" The same applies to IPv6: by trying to safe money, you 
might lose customers and money in the end.

Timo suggested to explain to the management what they would lose if they 
didn't do it.

Jen Linkova (Google) explained that from an operational perspective they 
are still discovering bugs now and that they have to test almost 
everything again for IPv6. Therefore her advice is to test everything 
twice from the start, don't expect things to works out of the box.

Marco pointed out that this community and especially this IPv6 WG is a 
great pool of resources on IPv6 deployment.

Dave Wilson (HEAnet) responded to the question of what problem he had to 
solve and how he convinced his boss. He said he solved this in his case 
by providing a business case. But that might be different in other 
environments.

A speaker from the audience said that after convincing your boss, the 
main problem is organisational: all departments in your company 
(networks, IT, service, marketing etc.) have to work together. That is 
not always easy.

Andy added to his earlier comment that even if people don't have 
official mandate, he would advise them to skill-up anyways, so they can 
be prepared for the deployment phase.

The working group co-chairs thanked attendees and closed the session.

Summary of Action Points – IPv6 WG RIPE 63

ACTION WG chair: to send mail to the mailing list asking if there are 
volunteers to start on a renumbering BCP for ISPs and if people know if 
there is already work being done in this area.

ACTION: It was decided to defer the topic of 
draft-weil-shared-transition-space-request to the mailing list.