IPv6 Working Group Minutes from RIPE 56

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

-----------------------------------------------------------
RIPE IPv6 WG minutes for RIPE 56, Amsterdam
-----------------------------------------------------------
WG: IPv6
Meeting: RIPE 56, Berlin
Date: Wednesday, 7 May 2008
Time: 14:00-15:30 (UTC +0200)
Chair: David Kessens
Minutes: Robert Kisteleki
J-Scribe: Chris Buckridge
WG URL: http://www.ripe.net/ripe/wg/ipv6/index.html
--------------------------------------------------------

A. Administrative Matters - David Kessens

No addtional agenda items.

--------------------------------------------------------

B. Quick Update From the RIPE NCC Regarding IPv6 Services - Andrei Robachevsky (RIPE NCC)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Robachevsky-Update_RIPE_NCC_IPv6_Services.pdf

Quick Update From APNIC Regarding IPv6 Services - George Michaelson (APNIC)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Michaelson-IPv6_Activities_in_APNIC.pdf

Roque Gagliano (LACNIC) noted that LACNIC also has most of its services running over IPv6 too.

David Kessens (IPV6 Chair) noted that it would be useful if LACNIC could also provide similar updates.

--------------------------------------------------------

C. Deploying IPv6 at Netnod - Kurt Erik Lindqvist (Netnod)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Lindqvist-Netnod_IPv6_deployment.pdf

Rudiger Volk (Deutsche Telekom) asked about the global routing problem and whether Netnod registered for the route? Did any of your peers filter?

Kurtis responded that he did not know of any peers who filtered it.

Jean Camp (Indiana University School of Informatics) said that, if an experienced engineer can accidentally announce themselves to be in Japan, imagine what difficulty a standard engineer might have.

Kurtis responded that the particular problem of 'fat fingering' isn't better or worse in IPv4 or IPv6. If the other people would filter, there would not actually be an issue.

David added that people are mostly happy that they got the IPv6 to work in the first place and filtering it is something they postpone until after they got something to work. Also, Netnod did the same exercise with two different vendors. He asked Kurtis if it's a lot easier the second time he did it or did he feel that he had to repeat the whole exercise?

Kurtis responded that it wasn't exactly the same exercise, since the deployment was changed somewhat when it was done for the second time. The two vendors were similar enough to make the actual deployment was straightforward.

--------------------------------------------------------

D. Follow-up:

Global IPv6 Routing Table Status (Discussion) - Gert Doering (SpaceNet AG)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Doering-IPv6_Routing_Table_Overview.pdf

Problems in the current Global IPv6 Routing System (Discussion) - Bernhard Schmidt (Leibniz-Rechenzentrum)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Schmidt-Structural_problems_IPv6_routing.pdf

Ruediger asked if he was not yet filtering?

Gert answered that he was filtering towards the down streams but not currently filtering on peering links except for max. prefix things, because it's a little bit hard to do right now.

Fergal Suipeil (University College Dublin) said that it's easier to have a typo in IPv6 because IPv4 addresses are more familiar. He asked Bernhard if there was a solution for this.

Gert responded that resource certificates can help if your upstream validates them, so the typical problems will be discovered. The other thing is that if you're not using your region's IRR, you only build the filters based on the mail from your customer telling you their prefix and there's a higher chance of typos.

David said that he copies and pastes and never types them again. He added that the typo might happen at the Regional Internet Registry (RIR).

--------------------------------------------------------

E. IPv6 deployment experience at AMS-IX and What's really out there? Rather than what's on PowerPoint - Arien Vijn (AMS-IX)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Vijn-IPv6_related_issues_AMS-IX_peering_platform.pdf

There were no questions.

--------------------------------------------------------

F. Experience With IPv6 On the Wireless Network, Before, After and During the IPv4 Turn-Off - James Aldridge (RIPE NCC)
[link to follow]

Lorenzo Colitti (Google) asked if the DNS lookup was going through the router on IPv4?

James responded that nothing is going through that router on IPv4. On the Windows XP LAN an un-routed RFC1918 space is provided.

Lorenzo added that it would be interesting to try with a resolver that doesn't talk to the outside world and that's authoritative. He said that he tried that and it didn't work.

James responded that there's a problem if you have an IPv6 only authoritative name server. For your own zone it'll work.

Randy Bush (IIJ) said that it will not work if there's a non-IPv6 between the route and you.

Bernhard said that CISCO NAT-PT does not work if IPv4 and IPv6 are in the same interface. Use two interfaces in Cisco, that works.

James said that yes, the interface doing NAT-PT are IPv6 only.

Bernhard said that he tried to run a central router in his network to do NAT-PT for all the access networks, and it just didn't work. The error message is totally
unclear. As soon as you split IPv6 and IPv4 and different interfaces, it starts to work.

David said that he had heard many Mac owners complaining.

James said that his 10.4 and 10.5 Macs worked flawlessly. He continued that there were a lot of users on the IPv6-only networks. The only disruption was caused when we did the access point reconfiguration which screwed things up. He said that there may be issues by having to manually type in the DNS resolver address. If you get that wrong, things don't work.

Fergal said that the show of hands shows that IPv6 works fine as long as you've got IPv4. He added that he would not turn off IPv4 on his production network for a long while yet.

James said that  he wouldn't try doing a major reconfiguration of all the access points on a network during the middle of a working day. He said that the problem is that there were people on the IPv6-only networks before the dual stack network was turned off. He said that he thought that a number of them were actually getting useful work done. They had connectivity. What happened when the dual stack networks were turned off on the access points was that we managed to break the access points, not the IPv6 network in particular.

Fergal asked that if this was repeated did this tomorrow, we'd have no problems?

James said that reconfiguring access points middle of a in the working day is a bad idea.

Randy added that the problem is operational. There was no rehearsal before, there should have been one, at midnight for example.

James said that it was tried with one Access Point and that seemed to work. With nine, it's different.

Wilfried Woeber (Vienna University - ZID/ACOnet) added that this worked for him too, until the AP reconfig. He had an old SSH client which did not work over IPv6, so there are other reasons that it did not work besides AP reconfiguration. We really need this real life test. He thanked James for this setup.

Gert stated that he was unhappy. IPv6 was working perfectly in the morning, but then somebody took away the wireless. He sad that he expected that only the
IPv4 would be turned off, not the wireless with the IPv6 on it. He asked what the the real reason for doing it was? Was it to demonstrate that we need lots of work until IPv6 can be used? In that case, NAT-PT is a stupid idea, it just hides that nothing works when you turn off IPv4. Or that NAT-PT can be used as a transition mechanism?

Randy said that transition to v6 is not the customer's problem, they don't care how the packets are delivered. They are the enterprise user. The goal was to use the attendees as the enterprise. This is what the customer will see, when they only get IPv6.

Gert said that the plan was including transition mechanisms?

Randy stated that his is correct and that the transition mechanism will be in place for a long while yet.

Lorezo thanked everyone involved. He said that people have to decouple the content side from the network side. And NAT-PT is the only way to do it. He added that your access can have a reasonably functioning IPv6 connection, your websites can be IPv4 and once that's done you can start migrating the ontent, so this is the way out of the address crunch.

Geoff Huston (APNIC) said that the more realistic expectation is that you are going to have to deploy NAT-PT. He said he was impressed after watching the IETF deprecate it only a few months ago. IPv6 and transition at the edge is actually what we are about to live through.

Niall O'Reilly (University College Dublin) said that this was a rehearsal. Doing this at midnight would have given the same experience. He added that it gave him lots of things to think about. We can't screw the enterprise more than once and this morning's exercise was sort of an experience of somebody else doing that for us so that we could learn. He thanked everybody involved.

Magnus Westerlund (Ericsson) stated that the mechanisms needed to be worked on. There is work on the next generation of NAT-PT.

David asked for a show of hands to see if the exercise was useful. Several hands were shown. He asked if anyone thought that this exercise should not have been done. No hands were shown.

--------------------------------------------------------

G. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond

    * IPv6 trainings in Europe and the rest of the RIR regions - Jordi Palet Martinez (Consulintel)
http://www.ripe.net/ripe/meetings/ripe-56/presentations/Palet_Martinez-6DEPLOY_Project_Presentation.pdf

--------------------------------------------------------

Y. Input for the RIPE NCC Activity Plan

None.

--------------------------------------------------------

Z. AOB

None.

-----

Close.