[ipv6-wg at ripe.net] Draft Minutes (v1) from IPv6 WG - RIPE 49

Please see below for the draft (v1) minutes of the ipv6 working group
session for RIPE 49.

The minutes will be declared final if no substantial changes are
proposed before Fri Oct 22.

I hope this helps,

David Kessens
---

RIPE 49  Manchester
IPv6 Working Group
Wednesday 22 September 2004
WG Chair  David Kessens
Scribe  Adrian Bedford (RIPE NCC)
Attendees: 121

Administration and Agenda
Presented by David Kessens

Adrian Bedford of the RIPE NCC was appointed scribe.
Agenda was agreed
Minutes from both RIPE 47 and 48 were approved.

Update from the RIPE NCC
Presented by Andrei Robachevsky, RIPE NCC

As of August, k-root is IPv6 enabled
The new version of the RIPE website (to be launched shortly) will also be 
IPv6 enabled.

An Overview of the Global IPv6 Routing Table
Presented by Gert Doering (Spacenet)

A number of anomalies have been observed in the Global IPv6 Routing table, 
though in most cases these could be explained by traffic engineering, 
internal transitions and in one case a prefix leak.

One person used the Jabber Remote Feedback system to ask why IXPs are
announcing /48s with no export. It was explained that, for example,
AMSIX doesn't want it's neighbors to make it's prefix globally
visible. It remains a contentious issue as to whether something should
be globally visible.

What are the Deployment Plans Behind the Larger IPv6 Allocations?
Presented by: Mikael Lind (TeliaSonera)

David Kessens asked whether there were plans to allocate /64s for mobile 
use.  Mikael confirmed that this was likely and that TeliaSonera was also 
looking at /48s for this use.

Kurtis Lindqvist asked whether TeliaSonera has been talking with
vendors to co-ordinate hardware and equipment. Mikael explained that
this has not yet happened, as they feel right now there is little
incentive to do so.

David asked if Mikael would consider returning to a future RIPE
Meeting to provide an update when TeliaSonera is further along in the
development and deployment process, Mikael indicated that he would be
happy to do so.

Deployment Plans Behind Larger IPv6 Allocations
Presented by Jordi Palet (Consulintel)

Jordi will continue to keep the Working Group posted on feedback.  He will 
also encourage non-respondents to contribute.

Geant IPv6
Presented by Jordi Palet (Consulintel)

Guidelines for ISPs on IPv6 Assignments to Customers
Presented by Jordi Palet (Consulintel)

This presentation was a follow on from the one given at RIPE 48.

< BREAK >

IPv6 Glue for the Root Nameservers
Presented by Johan Ihrén (Autonomica)

Iljitsch van Beijnum asked how long the process is likely to take.  Johan 
commented that it would depend on who was prepared to take on the task, 
Johan is willing to do this, though added that nothing is root server 
specific, if people argue that we need v6 glue now, then they should step 
up and offer to help out.  There is no specific target date for this to 
happen, since testing needs to be completed.

Randy Bush asked that since we tend to assume that we should upgrade
when something breaks, how is he to know when something has in fact
broken. How, as an operator will he actually know there is something
wrong? Johan agreed with Randy, there needs to be an agreed process.
This could mean that things may not happen universally at the same
time. Much will depend on the level of ambition of those involved -
the tasks could be more or less complex.

Gert Doering commented that as we see ccTLDs adding v6 glue, they might 
already know some of the issues that could arise.  He suggested that 
someone speak to the ccTLD Operators and find someone who is willing to 
help with testing.  It was also suggested that prudence might be a good 
idea.  If a ccTLD Operator decides to deploy v6 transitions to their 
nameservers, in the end it will be their own decision.

A question was asked about whether anything could be done to improve I-root 
connectivity to Europe.  Johan commented that this would fall into his 
domain and promised to provide more feedback on this by RIPE 50.

Bill Manning commented that the group appeared to be talking as if testing 
had not in fact started, whereas people are doing tests, ccTLD Operators at 
already looking at the impacts of these tests.  A timeframe was agreed at 
the last ISOC meeting to finish testing before their next report at the end 
of the year, enabling a report to made to ICANN.  One obstacle here is that 
the last report to the ICANN board took six months to have approved.

Doug Barton of ICANN commented that the process has been streamlined and 
lessons learned, it is felt that any such future report would receive a far 
quicker response.

David Kessens asked if all root servers planned to have IPv6
connectivity at the same time. Johan replied that he thought it
unlikely that everyone would approach this in the same way, adding
that he felt diversity was not a bad thing. It would, he said, be
likely that we would see some TLDs using basic glue with others
holding off during the early phases. The day when we will see the v6
glue globally is still somewhere in the distant future as there are no
specific plans at this point to co-ordinate such a deployment. To date
eight have basic glue in place. David asked if this community could
help and Johan said he felt it certainly could. There was discussion
about asking the RIPE NCC for help, though Johan this was not
necessary at this stage. From his point of view he did not feel the
issue was who did this, rather thought needed to be given to
identifying which tests are relevant. Time would need to be taken over
inventory to find out what code is already out there. David rounded up
the discussion by saying that volunteers would be welcomed, though
this was not be taken as a specific action point.

An Update on Multihoming in IPv6
Presented by Geoff Huston (APNIC)

A comment was made that the slide detailing issues appeared to not
consider the update rates for bindings and third party referrals.
Geoff said that design decisions should avoid relying on DNS.

Randy Bush commented that there had been some mission drift from
multi-homing to mobility. 

A comment was made that if an opportunistic solution does not meet all
the needs in the architecture, you are forced to use a structured
identifier. Such an identifier would have to be unique to avoid
collisions. This could give rise to a very complex registration
infrastructure, which might be painful to administer. Geoff replied
that uniqueness never comes cheap and needs enormous effort at a
global level. This lead to a suggestion that it may be preferable to
choose opportunistic styles. Geoff felt that this was down to personal
taste; there were certainly benefits in avoiding global costs if set
up problems could be avoided.

A suggestion was made that we should consider developing a whole new 
protocol that could handle routing table growth, Geoff replied that it 
would be ideal to think that we could do both, groups do exist with 
experience in both fields. The IETF have working groups that work together 
to engineer solutions and ensure routing tables do not become too complex. 
Geoff agreed that many people do feel routing could provide a better answer

Kuris Lindqvist pointed to work that had been done during an interim 
meeting in Santa Monica in June 2004, this looked at the architectural work 
done by Geoff and the 30-40 drafts submitted.  The drafts were split into 
four or five categories and based upon these; a simple poll was carried 
out. In some categories, the authors withdrew their proposals and in 
others, there was little support.  The consensus was that the architecture 
proposed by Geoff was the way the group wished to move forward at the moment.

A speaker announced that he had prepared a draft on the use of PI to reduce 
pressures on routing tables, intended as a compromise and is accepting 
comments on this.

A speaker added that during his presentation Geoff dismissed mobile IP for 
security and state management reasons.  The IETF has already addressed 
security and state management could throw up more problems.  He felt that 
having two solutions for these issues problem was unwise and we need to 
work towards a single solution for what seem like related problems.  He 
felt that using security, as a reason to reject the architecture draft was 
a red herring. Geoff pointed out that this is not yet in the draft, though 
will be in the next version.

Geoff agreed that some of the assumptions we made previously in mobile IPv6 
now seem less secure.  Security locators assume a stable home base  - if it 
fails, everything else fails. Multi6 looks at the ‘homeless vagrants’ of 
the world that do not have a home all of the time and the home is not 
reachable. It then assumes that there is not a home locator that can always 
be contacted.  The Multi6 team looked at the other approaches and aimed to 
learn from them.  He remains unsure if this kind of binding works in mobile 
environments, it is far too early to make this assessment.

David Kessens asked whether the group found updates from Multi6 useful, 
Kurtis suggested that it would be nice to have Geoff make a similar 
presentation in future Address Policy Working Group Sessions too.  Gert 
Doering suggested that as co-chair of the Address Policy Working Group, he 
would like to see the drafts on PI Addressing discussed through the Address 
Policy Mailing List.

Moonv6 Update
Presented by Jim Bounds

Kurtis Lindqvist asked whether security testing had been carried out in an 
isolated test environment.  Jim clarified that filters had only been tested 
on IPv6 ports, addresses and protocols.  He added that it showed there was 
confusion.  Just because dual stack is not a security problem, IPv6 in 
itself is not an insecure protocol.  Intrusion detection needs to be 
included into work.  Kurtis asked what stage of the evolution process the 
project had reached.  Jim replied that in this respect, research was still 
quite basic.

Deploying 5,000 IPv6 Sites - XTEC
Presented by Jordi Palet (Consulintel)


Input to RIPE NCC Activity Plan
Presented by David Kessens

David asked if the group had any items to include in the 2005 RIPE NCC 
Activity Plan. There was no response.