These are unedited transcripts and may contain errors.
IPv6 session
15 May 2014
11 a.m.
CHAIR: I can reintroduce myself. My name is Marco, I work fork the RIPE NCC
and I'm also one of the co?chairs of this group, as was shown on this slide.
If anybody has any messages for us, you can always reach us at the e?mail
address.
We have an IPv6 wireless network, which is IPv6 only. It's an experiment.
Here is how to connect to it. We have a separate password, we want to hear
your feedback on the list. And maybe if we have time and unfortunately I
expect not. But if we have time left we might pick up on this at the end of
the session.
People that were there this morning noticed we did change the agenda
slightly. We ran out of time so Alex Band has agreed to move his
presentation to this slot, and in the meantime, we had five minutes left so
Andrei already presented his lightning talk on IPv6 synthesised records.
Apologies for a bit of confusion, it's always a Working Group things run
over, things run late and we have to swap around. So, without further ado,
I'm going to hand the stage to Alex and hope we stick within the time slot.
ALEX BAND: Hi, I am Alex Band, I am the product manager at the RIPE
database and about one?and?a?half years ago we introduced the IPv4 analyser
trying to offer an insight into all of the allocations, assignments how many
allocations you have in an easy to use interface that allows you to find
free space, it shows you which invalid assignments you have made and very
quickly it turned into the most visited page in the LIR portal and we got a
lot of requests, saying can you please also do this for IPv6, and we have.
And it's done. And this is actually the biggest collaboration within the
RIPE NCC that we have done, because we worked together registration
services, together with training services, communications, external
relations, to gather all of the feedback that we have received from users,
from members, what kind of issues people run into, when they get their first
/2232, so that's really the question we are trying to answer. I got a /32
/ or maybe a /29, now what? What do I do? Where do I start? And making an
/ addressing plan is already quite hard and sort of tackling the whole
/ database aspect of it is also pretty difficult. So, we set out to design
/ something to make it really easy for people to get going with IPv6 and
/ manage their address space from within the LIR portal.
So, this is the concept. We wanted to give a visual navigation. And we
wanted to really seamslessly integrate with the RIPE database this time.
And that's the key difference with the IPv4 analyser because it really only
gathered data and showed you things but it didn't actually allow you to do
anything with it, and we finally pulled that off to have a seamless
integration between fetching information from the RIPE database and actually
creating new objects and doing new things, and also manipulating existing
objects.
And pouring all of that into a design makes it look like this. And this is
a hierarchy /K?L view of all used address space. Initially you think, well,
especially for v4, thinking about the amount of free space you have was
really important, we wanted to show how much you have used, whether you were
over, under, 80%, stuff like that, but for IPv6 don't consents really don't
apply. If I'm going to try to visualise a /48 in relation to a /32 you are
always going to end up with something that is half a pixel wide and doesn't
really scale. So we left out all of the free space in this visualisation,
it just gives you a structured hierarchal view of all of the address space
that you have, all of the assignments, aggregations and suballocations you
have made.
That is in the visualisation below, and for the selected block, it will show
you all of the more specifics in a table. And I would like to think they
are thanking me for letting me use if they would use the RIPE NCC it would
be just really boring, so ?? and this has a really nice visualisation. That
is how it works.
So you can browse through your address space and every time you click on
something, it zooms in and regroup together all assignments, because they
could be like one assignment or it could be 10,000 assignments and I don't
really want to show 10,000 assignments in like one pixel high blocks, so we
just group them together and if you select a parent object it will show you
all of the child objection in the table below. Making sure that it stays
manageable.
Then the other thing we did is we added a create new objects button. And
this is the key new thing that we have introduced and it sort of is a
paradigm shift in the way we interact between the LIR portal and the RIPE
database in managing your objects. Because when you click, it this is the
first thing that will happen. You take your parent object and it will go,
okay, you would like to create a new object as a child object of this one,
but in order to create that, we first need to establish an association with
who you are, so that is the SSO account with which you're logged in, and the
maintain err of the object in the RIPE database. And this is a one time
operation, you just enter the password for the maintainer, and it adds an
attribute to the maintainer object. And this attribute has got theality
SSO?1, which is essentially a new addition that has been added to the RIPE
database about two months ago. So you are no capable of editing the RIPE
database and updating the RIPE database using your RIPE NCC access
credentials and that's a really big thing, because it finally allows us to
have seamless integration between all of our different services, so you can
really go from RIPE Atlas to RIPE Stat, to the LIR portal and the RIPE
database, and check some of your measurements and update some objects
without having to enter new credentials at any point in time.
So after you do this, it's really like a one time operation, you're good to
go and it essentially asks you three questions:
What do you want to do? I want to create a new single assignment for one of
my customers, I want to create an aggregate block, for example, my DSL
customers, for example a /36 for my DSL customers within that /56 or /48s,
we decided to limit the options. Let me walk you through the second one in
a minute. The third option is to suballocate the block. We all it
allocated by LIR, but once you do a training course people are, isn't that
just a suballocation? So we decided to call it what it is, it's a
suballocation, really. And when creating assignments, if people don't
really know what to do, we just give them the default first. So, the best
practice is to give a /56 maybe to your End Users, and it really, it just
distributes everything on level boundaries, so you essentially have five
options in this list. Because if you'd like to assign more than a /48 per
customer you are going to have to send in a request to the RIPE NCC anyway,
and after you have got an approval for that, at that point you can just
enter the block manually so. This just sticks to the default and it gives
you a limited set of options, just for people to make it really easy to get
going.
So what is the assignments size you would like to give to each customer,
/56. You can choose from five other options. You select the aggregate
/ side; it tells you, this will be the amount of customers that you'll be
/ able to serve using the block that you are now going to create. Then the
/ next step, it just takes all the data, it pre?populates all of the fields
/ from the parent object, so you can just edit what needs to be changed to
/ your text C, your admin C, the only line that the empty really is the
/ description line. So you just give it another description and when you
/ hit go, it will create a brand new object in the RIPE database.
Now, how does this work? Well, it interfaces over the restful API, and
everything is linked together through the RIPE NCC access account. So
single sign on, even including two factor authentication if that is what you
would like. It's a lot easier for people to wrap their head around than a
maintainer object and really trying to get that going. I mean, Denis did an
update in the RIPE Database Working Group where we're also talking about
trying to get rid of the entire concept of maintainers or rethinking that
concept. We are just trying to make it as easy as possible for people to
get going with this technology.
And you may think well that's not an awful lot that it offers, it's just
some visual navigation and it shows you a table with more specifics and I
can create three flavours of database objects. Is that really it? There is
a lot of technology under the hood and the concepts that we're introducing
here it really allows for expansion on this as a current idea, or we can use
these ideas in other services as well. To give you an example, in the IPv4
analyser, we gave you have an overview, for example, your invalid
assignments, for example, an overlapping assignment, right now, what we're
doing is we're just showing you these two are overlapping, but for years I
have been saying, I want a magical fix button there; I just want you to be
able to go, fix, and it tells you these are the ones that overlap, select
one you would want to delete; hit go and it just does it for you, really to
help people make it easier to manage their address space. And this kind of
out?of?the?box thinking, is what I would really like to hear from you, if
you have input on how we could make this easier and how we could add more
structure and make it easier for people to understand. I think that would
be really helpful and awesome.
And you can imagine that the way that the LIR portal grew as a service,
right now it sort of scattered around with different tools and different
services, some things linked to a registration, to a resource request, other
things are an object editor to edit a specific subset of entries in the RIPE
database, for a lot of users it's really confusing and we're trying to use
these design paradigms to bring it all together. So over the next couple of
months we'll be putting a lot of work into the LIR portal to make it in line
with the things that we're introducing here.
Again, if you have ideas on how we could continue to build on this, then we
would love to hear them.
Any questions?
MARCO HOGEWONING: Any questions for Alex? No. Okay. Thank you Alex.
Then, next up is Jan Zorz and/or Benno, I think Jan is going to present.
You might know that we have got a BCOP task force and one of their things is
to set out to write documents. As mentioned in the last Closing Plenary in
Athens we invited them to bring some of the IPv6 work here, this is the
first step at this.
JAN ZORZ: Thank you. Jan Zorz, from Internet Society. We are bringing
here from the Task Force the first IPv6 document that I happen to be the
co?author and the editor, but I will talk about that later.
So, first, some misconceptions in reality we have been talking about this
document around the world, and this is not an ISOC document. This is a
community document. And it is a product of a group of brilliant experts
from the community. You will see the list later. I just happened to be the
initiator and the editor and I would like to thank ISOC to dedicate some of
my time to run this effort.
So, as you probably know, RIPE 554 removed one of the speed bumps for the
IPv6 deployment where we well specified how to order the equipment, and
Sander will talk about this later, we decided to ask the community if we
want to do the next version. And while I was travelling around the world
and talking to the operators, I heard that the next speed bump is the lack
of IPv6 knowledge at the help desks. So, what people did, people deployed
IPv6, tested everything, and then said we are not deploying it to the end
customers because our help desk will burn down in flames. This is a mental
conception of people. It's like a mental burden, but we need to ?? I
thought that we need to tackle with this anyway.
We know that IT help desk can be difficult sometimes, especially if they
don't know how to answer the question, and if there is an IPv6 call to the
help desk, if they don't know the answer, they can be a bit difficult
sometimes, so we thought of bringing up the very simple, short to the point
document with IPv6 trouble shooting procedures for the first line of the
help desk. We have got something good contributors, it's Lee Howard, JJ ??
the list is here, and this is actually the document to provide the starting
point for the Help Desk. Actually, the hidden intention is to provide the
technical team at the ISP to hand over something to the Help Desk manager
and say, okay, this is the stuff that your boys need to know about and for
us checked, we can move forward, we can move on and deploy IPv6.
We thought that the document is not good enough. So, I tried and talked
Jason if he is letter, maybe you know him, he is in Yahoo, he is running the
test IPv6 dotcom. It's a brilliant tool, but we thought that we need to
detect what is wrong on the other side in some really simple fashion. So,
we thought that we need an online tool to detect the state of connectivity
on the other end and test IPv6 dotcom is a very useful tool, but a bit
complicated and not made for this.
So, we talked Jason into programming and making the special version of the
tool that is called ISP.tes.IPv6.com and the idea is you go there, it's
widely open, anyone can use it. You go there, you type in ISP.test.IPv6.com
and it tests your IPv6 connectivity and provides you back with a very short
result, and there is also a help desk code. For this one, this is 46, it,
so it's dual stack and possible tunnel. So, the user on the other end can
read to the help desk guy over the phone line, just the code, if this is one
of the generic situations, and then the other end can go into the document
that we are writing and actually trouble shoot his issues, or escalate.
So this is a table of content. We are dealing with some scenarios here,
it's IPv6 plus broken IPv6, this is the hardest one to tackle. This is the
longest procedure to deal with. Then we have like, I will not read all of
them. And then slow, MTU and side failed connectivity. Are addition, the
tool can add slow or possible MTU issues to your result. It's quite a
complex set of a mechanisms under the hood, but it's important that for the
help desk person and for the user, it's as simple as possible.
We are also providing some IPv6 training for the help desk to the help desk
managers, so, this is the table of content. This is one example. For
example, the hell desk code is 624, then it's 6to4, IPv6 are IPv4 is good,
IPv6 is good. It's 6to4 is preferred, your address is this, your IPv6
address is this one and then we go into interpretation, we tell people in a
few words what is this, why is this happening, and we propose some action.
Have the user disable an automatic tunnelling mechanisms, right, and we
explain in simple words why we're doing this. And then we have, for
example, how you disable it in Windows. So it's quite easy, easy to read,
fixable, done.
This is the hardest and the longest one, 112 ?? thank you, Marco ?? so it's
IPv4 plus broken IPv6. This one, if you go and read the document, this is
like five or six steps, what you need to check, then it's a table of
possible addresses that you need to match. If they are valid or not valid
and so on and so forth. So this actually made the document a bit longer
that I don't like personally, I don't read things that are more than ten
pages long, but anyway, we think it's ?? this document is in pre?draft
stage, and what we are asking you to go, to read the document, I circulated
it on the mailing list, and here we are to verify the technical aspects that
should be corrected in the document. I know there is lots of work to do and
you did a great job as a community at RIPE 501 and RIPE 554 and I hope that
you, as the community, with us, will do the exactly the same job here for
this document and make it as popular as RIPE 554.
So, the whole thing started at the pick up, we got the authors together,
shipped them over to the IPv6 Working Group for the technical verification
?? thank you for the IPv6 Working Group co?chairs for accepting us and
putting more work in the Working Group. We are tracking the issues at
Sander's GIT hub. You can go there and see, it's publically available which
issues are already in there so you don't put in the same comment. So, when
I published the whole thing at the Go6.si website and circulated it on the
mailing list and also Ivan wrote the block post about it, it got a bit of
traffic, so here are my logs from 13 April, 1,872 downloads. So I suspect
that some of you are already reading it and I'm really grateful for that and
we expect some really, really good comments.
Thank you.
AUDIENCE SPEAKER: Rangler, I received this from you Jan, I think it was in
Paris and I showed it to my help desk, the basic feedback from them was
great, give us these tools and we're set to go. So I'm really glad your
doing this and promoting your work internally and we hope to help you. One
thing that you could consider is on the website where you have the fall
codes, would you also add the help text as well, so if you have expert
users, they can actually go in and understand and fix it themselves without
actually not calling the Help Desk itself.
JAN ZORZ: This is the plan. When we finish the document, when we reach the
consensus somehow ?? if ?? and we polish publish the document, I will
probably talk to Jason to add the parts of the text to appropriate scenarios
that are coming out. But yeah, great suggestion, thank you.
AUDIENCE SPEAKER: Jenna. First of all I think it's a great idea. I
already sent you a pretty long e?mail with comments, so I'm not going and
discuss the comments itself. Just a question about the procedure. You
mentioned GIT hub and you mentioned two mailing lists, I am afraid of kind
of too many places to track the work. So, I think we probably need to agree
where we're going to send suggestions so people don't need to track too
mailing lists and one GIT hub.
JAN ZORZ: The idea of the pick?up Task Force, is the main goal is to get
the operators together and get them agree on that this document is actually
the current operational practice or is going to be the current operational
practice the here in the IPv6 Working Group, we are verifying the technical
aspects of the document. Two different things. And the GIT hub is just the
issue tracker that people can go and see if somebody else has commented the
same thing, maybe Sander ?? Sander is jumping up and maybe he will explain.
He is the co?victim.
SANDER STEFFANN: The issue tracker is just what we use internally and just
offer it as a reference to everybody else. But everything will happen on
the mailing list.
JAN ZORZ: Correct.
AUDIENCE SPEAKER: Jenna: For technical comments about the adjustment to
the document from the procedure point of view, from technical ?? you go away
in the IPv6 mailing list.
JAN ZORZ: Yes.
AUDIENCE SPEAKER: I'm not going to send my e?mail to ??
JAN ZORZ: It was accepted. Thank you, we will put it on GIT hub issue
striker, every part of your comment, and then see how we track the whole
stuff.
SANDER STEFFANN: I definitely agree with Jan, we should not have the
discussions at three places at one. I think the IPv6 Task Force is the
place to be now.
JAN ZORZ: What I would expect from you as a community now, is to go and
read the document and send the technical comments to the IPv6 Working Group
mailing list and when we get through this, we'll get back to the pick up
Task Force and decide if this is a pick up document or not and publish it
anyway as a RIPE document. Thank you.
SHANE KERR: Thank you. I believe next up we have Ragnar. Also talking to
us about a document. This was coming to us from the IETF about IPv6
security in CPEs. Take it away.
RAGNAR ANFINSEN: I am not representing my company today, but a group of
authors who have been working with a draft for the IETF, and we actually
missing feedback from the operational community, which basically is you
guys. So I'll try to go through it with you today.
So, the question was on the include net mailing list on what's the default
recommendation for a CPE file on IPv6? Obviously there were two answers.
It's either on or off, and there was a lot of great feedback on that one. A
lot of people saying the firewall off. Because we have good entrance
security, or you do have good host security, you need good end to end
connectivity, operators rung without firewall today says it's not a problem,
and so on. The firewall is actually not securing you so much any more,
because the people are coming through to you to e?mail and spam box and
everything else anyway. And you had all the other camp saying, well we also
have the customer are used to security like NAPT systems, so don't disrupt
that. Marketing is afraid to go with open security model, where they kind
of having media issues and all this stuff. So the usual thing.
So, today the IPv6 security is done basically through 6091 which basically
says either keep is closed, everything out is allowed, nothing in, like NAT,
or you can have an fully open and you can add some rules. But basically you
can add rules on both directions.
So, it's not very good for end to end connectivity. One of the recent
additions to this is X box 1 which basically uses IPv6 for most of its
traffic. If you have an IPv6 firewall it will revert to v4 and we're back
to where we started. So...
And also, one point from the one of the authors is NAT, IPv4 NAT is not the
same as IPv6 firewall. Because, you can do hole?punching and stuff with
IPv4, but you need stun servers and such to keep end to end connectivity so
you need to have states and sufficient. On IPv6 firewall you don't have
that capability because you kind of toggle each port you need to open and
you /KOEPBT don't have a way of actually opening other ports on the UN N P
are actually coming. That's the future. What we're walk talking about now
is what's cosmetic surgery. We need something now so we're using the tools
we have.
So, with thought the solution might be what we call balanced security for
IPv6 residential CPE, and we presented this in the IETF for a few years now,
we had mixed feedback, in Jan, it's, yeah, could be useful. But (Jan) they
are asking for operational practices and such.
So it basically works like 1692 but we are just saying keep it open. Keep
the firewall fully open. But block some ports, and those ports is one of
the big discussion points. So, typically exceptions might be the normal
SSH, tell not, HTTP, /T?PS and such things. Keep in mind this is not meant
for the experts, this is ?? this is many for the people who /KOEPBT care and
don't know and expects things just to work (don't) like our parents or our
friends who do not focus on security. So we want to try to help them in the
best way possible.
So, managing these exception Yours sincerely one of the bigger issues,
because who decides what should be open and what should be closed. And we
can do it through different ways, we can define a pick up document which
basically states this is a community effort, we decide that these ports are
the most relevant for blocking, for the average user, keep in mind that you
can go in and edit these ?? you should be able to edit these default
settings any ways but this is kind of the one of the customers connected
IPv6 firewall, this is what he gets. The service provider could do it
themselves, obviously. And just as a note, in the draft if you read it,
there is an example, this is purely an example, it's just for the which is
come implementation whom have already done this.
So, as I mentioned, Swisscom have deployed it and you know how many
customers they have. As far as today they do not have any operational
issues, they do not have any bad feedback on this and obviously my company
will deploy this soon as I have said many times before. So basically
questions to you guys: Do you find this useful? This a way we should go?
Does a pick up document defining these rules make sense? And what do you
do? What do you think? What would you suggest in this scenario?
So, if you want to contribute, see me during the meeting or contact any of
the authors on mail.
So, thank you.
AUDIENCE SPEAKER: Sander Stefan. I think this is a really good effort. I
think for things like the X box 1 and for the end to end model, this is good
to have. I can appreciate that it's not everybody's preference and people
like really tight security. But, yeah, I think this is, for me I think this
is a good direction to go in, and actually both showing advice on how to do
this and showing experiences on people who have already done it is both
very, very important, so, thank you for this.
JAN ZORZ: Thank you for bringing this here and basically my suggestion at
the IETF was to verify it with the operational community. If you need more
authors and more cooperation, you can come to the pick up and ask people if
they would like to cooperate and then verify with the technical experts
here. That was my comment. My question is: Did any of the CPE vendors,
apart from the one you are using and probably brainwashing for years, did
they show any interest in this?
RAGNAR ANFINSEN: Either way, just basically silence, but I think it all
comes down to if you want to do this on a retail CPE, I haven't thought that
very well through, because the manageability of such a thing would be quite
complex. This is mainly thought out for service providers who actually
manage the CPEs for the customers. For my sake, they come to our web
services and then manage the CPE from there, so I can easily, any rules or
any default rules in general.
JAN ZORZ: Did you ever think of going to like the Open CPE project, or I
don't know, last time we had a presentation here from from Deutsche Telekom,
they are working on their Open CPE version, maybe you should go in and do
some running code and see how that works?
RAGNAR ANFINSEN: Sure. Thank you.
AUDIENCE SPEAKER: Benedikt Stockebrand. I'm not going to warm up our
discussions we have had so far to the mailing list, just one thing from a
discussion I had with Tore Anderson sometime ago, it might actually be some
kind of local cultural or whatever sort of issue what approaches are most
reasonable. So, just a suggestion, you might want to keep a bit of an eye
on it because otherwise you might wind up with a recommendation that works
for some people but not for others.
RAGNAR ANFINSEN: Sure. Thank you.
AUDIENCE SPEAKER: Matthew Moyle?Croft from Amazon. Previous job in
Australia when we rolled out IPv6 we did for filtering pretty much what we
did for v4 which was to give customers the ability to change a set of ACLs
on their servers. We didn't do it in the CPE partially because we didn't
manage them. Which is different in different enviorments, but also so that
we could not only reduce load on the last mile, because you know, there is
no point carrying these packets to the CPE most of the time if people don't
want them. The second one was so that we could update them quickly.
Obviously NTP is on your list now, but recently NTP was not on people's
lists and I understand that if you are remotely managing CPE you can do it
differently, but it still tends to be a lot harder than updating a couple of
ACLs on your aggregation routers. But, we allow people to turn them on and
off. We had very sophisticated users, most of APNIC I think was using us at
one point because we were the only people doing v6 in Australia.
RAGNAR ANFINSEN: Thank you. The draft is not specifically towards the CPE
but towards the server, so you have BNG you can actually apply this on the
BNG if you have such functionality. It's not necessarily to the CPE but for
the end user as well. So, sure ??
CHAIR: Thank you Ragnar. We welcome your feedback on our mailing list.
Next up, Sander, yet again, we are actually doing work here. Some of you
may remember that a few years back we had this document that was called RIPE
501. Then it became RIPE 554. And here we go again. It's two years ago,
I'll leave it to Sander to tell the rest of the story.
SANDER STEFFANN: Two years ago we finished ?? RIPE 554, so for those of you
who are new and never heard of it. A short introduction. RIPE 554 is a
template guideline for procurement of stuff that should do IPv6. So, it
includes something about some hardware, some software. It's actually used
all over the world. So it became a very popular document. And if I know
some governments even incorporated it into their own procurement documents.
It's part ?? it's translated into Dutch and part of the Dutch buyers
handbook for ICT equipment in the Dutch Government, for example.
So this became quite successful. To be honest, the first version RIPE 501,
was even more successful. So, these are the views and downloads from the
RIPE website. As you can see, the light blue line is 501. The dark blue
one is 554. And there is actually a demand for good guidance on this.
So, it came to be because Jan Zorz wrote a document for the Slovenian
Government and at some point came to RIPE and say hey, this might be useful
for more than just our Government. So, it was translated into English, and
basically published. But then of course people came and said hey, but we
would do this different, we would do that different, we need to add
something on this device category, so, we expanded it a bit, and that became
RIPE 554. But, as it always goes with these kind of recommendations, things
change, and the document is almost two years old, there are new standards,
new RFCs, some things have been updated and people have actually pointed out
bugs in the document.
Now, the problem with RIPE documents is once they are published, they cannot
be changed any more because that would cause confusion. So, I'll go a bit
through the it bugs first and show you what we really need to do.
RIPE 554 contains a line in the requirements for enterprise and ISP layer 2
switches, that mentions router advertisement filtering, RFC 4862. But RFC
4862 is also the stateless auto configuration. So there is a bug in there
the title and the number just don't match. Unfortunately, we tried to fix
it because it was discovered right after publication but it was already
published, so, it's still in there, so that's something we definitely need
to fix but I think this is simple.
Then we have some other things. There is mention of RFC 3140, but this is
actually something like you would do in operations, not something that a
router supports or doesn't supports. It's just how you use the different
values. And even the author of the RFC said this really shouldn't have been
in your document. So, I think it's, we have a good case of removing this.
So, and then we got lots of people who said oh but this RFC is a good idea
and this should actually be required from vendors. So, we have a whole list
of new RFCs, some things were missing, things like application aspects for
IPv6 transitioning. We have a document on operational neighbour discovery
problems and solutions. There is a document on first come first served
source address validation, there is a document on the processing of IPv6
atomic fragments and especially this last one I personally think is really
important but there might be more things that have come out that we have
missed in the previous document.
Now we got some people asking this is really good but can you please broaden
the scope a bit. So, it now mentions any software that communicates via the
IP protocol should support IPv6. But then we have things that pars lock
files, analyse data, so they don't communicate over IPv6 but they still need
to understand IPv6 addressing for example. So, this is something that we
might need to broaden a bit.
And then this is another one that I heard from many, many people. We give
guidance on hardware and software, we do give some text on integration
services, but how about connectivity? How about hosted services? These
things are getting more and more important, people love the word "cloud" for
some reason. But those things should support IPv6 as well if you're using
them. So, this is also something we need to discuss and I think this can be
improved.
And then we also have some generic text that says, that people can put into
their procurement documents, some people said oh this is useful, some people
said this is not something that the RIPE community can recommend because it
depends on your ?? the legal situation of your organisation, it depends on
the country that you're in. So, maybe this is not something we should put
into a RIPE document. We have to discuss that as well.
So, lots of work to do. And as this is a Working Group, I think we should
do it here. We already talked about the issue tracker. We are also using
it for this document. And we can actually use a few more people to do the
work here. So, in the opinion of the authors of RIPE 554, we think this is
something we need to work on. So, I think we should, as a Working Group, we
should take on task and start writing the next update for RIPE 554. I
mentioned some things, if anybody has any other ideas, things we should
improve, mistakes we made in RIPE 554, please step forward. If you are
willing to help out, please contact us, discuss it on the IPv6 mailing list,
and that was it. So, any feedback on this, do you think this is a good idea
or maybe you want to shout out like no, please leave this document alone,
it's good as it is. That's also an option as well. So... let us know...
SHANE KERR: I'm going to put myself at the head of the queue. I think this
document is one of the great success stories of the IPv6 Working Group and I
thank yound and your authors and everyone who put effort into it. And I
think yeah, it's time to revise it. These things can't ?? they can't be
static. They have to be updated periodically. That's just my 2 cents.
AUDIENCE SPEAKER: I fully agree with you, Shane. There is one thing I
have noticed with people I pointed to 554, which was that by the sheer
volume, it sometimes scares people off. So, we should avoid making it like
a 500 page document that nobody reads any more, and maybe at some point, I
don't know if it's the right time now, but it might be (/SKAEURZ) necessary
at some point is to actually split it up into different documents for
different areas. So, from that point of view, maybe adding something about
choosing your connectivity might actually be better off in a separate
document. Just not even a suggestion, just something I'd consider talking
about right away.
SANDER STEFFANN: That's one of the reasons why I suggested removing all
that broader plate text because it just confuses people. But yeah, thanks.
AUDIENCE SPEAKER: William Pettinghouse. I think it's not a good idea to
broaden the scope of the document too wide because for each section you have
you get suggestions over suggestions as the the world turns around. Keep it
with the hardware. You don't have too many discussions there, because
either a firewall supports a feet our or it does not but if you go into
cloud services or SDN you get into political owe religious discussions on
what has to be included in the document. So keep it relatively where it is
right now. Fix bugs, add new RFCs, but for Cloud, SDN connectivity, let's
have a new document if if you find new authors.
SANDER STEFFANN: If we don't find new authors, I am also willing to work on
that. But, yeah ?? I think what I hear now is that people say, if you do
new stuff, do it in a different document, and that's ??
AUDIENCE SPEAKER: Otherwise you can't stop the discussions any more.
There is so much development in all of these areas you will have a follow?up
document every six months, and this is not what you want.
SANDER STEFFANN: Definitely. Thanks.
AUDIENCE SPEAKER: Marco, speaking in the position as a RIPE External
Relations Officer and Technical Adviser. I agree to the previous speakers
in terms of broadening the scope. I think you should keep in mind that RFC
1925 and the fact that you can keep gluing the stuff in.
As far as this document being used, you said it, I have come across it quite
a lot in different organisations, even in the IT context people pointing to
this, it's been used by the OECD, been referenced by various governments,
and the big thing and that's also where you are leading to is confusion.
First suggestion is, if you remove boiler plate text, can you please add a
paragraph in the start of the document that explains how this document
handles updates, so people don't have to go to anywhere else if they get a
copy of the document. And the second suggestion I would like to put forward
to the group and I'm not sure whether it's actually possible on the RIPE
thing, but I think we can do it, is to not obsolete RIPE 554. Issue a new
document. Make sure that it's referenced everywhere, make sure that the
generic references go to the new document, but leave it as is, because
people who are not familiar with our processes and are not familiar with
things and it's basically also what happens are RFCs, if they come back to
RIPE 554, yes, we know it contains bugs, but what really would confuse them
if they read somewhere and says use 554 and they go somewhere and it says
this has /HR?PB obsoleted. That /SKAEURZ them away. As a forward
consideration for the group we might want to consider about leaving the two
documents alive.
SANDER STEFFANN: I agree with you, so basically that comes down to a
wording question, maybe not say obsoleted but say there is a newer version
or whatever, but, yeah, I agree with you that especially for people who
don't know this community, that part of the communication is very important.
SHANE KERR: I'm going to jump in the queue again because I am the Chair and
I can. I'm going to say that sounds really confusing to me so I think we
need to discuss T it's not clear at all in my head how that would actually
look or work, anyway...
SANDER STEFFANN: If we go back a little bit, the people down logo 501 are
still. There is still a lot of them. And that one said (downloading) says
this one is obsoleted and replaced by 554. But I think we have to do this
consciously and think about how we want to communicate.
SHANE KERR: Sounds like a crazy idea but it just might work.
JAN ZORZ: It's weird commenting on my own work. Sander, what we managed to
forget to put in this presentation the language polishing. I got lots of
comments from people saying this work clearly shows that there is a
collective effort of many people because the wording is not consistent
throughout the document, and we would really, really, really need somebody
that is a native English or American or whichever version of it, speaker,
and go after ?? or before we want to publish it and do the consistency in
the language.
And the second thing is, the connectivity, as you probably know, the list
for the specification for the connectivity that you should ask your access
provider. I am collecting that list, it came out of Andrew check owe list,
I am retaining tonne a site, but it was a 554 draft but it mysteriously
disappeared during the process, I think America overrun it and it
disappeared, so that list kindly ?? kind of exists and I'm willing to work
(/PHER I can) if we split from 554.
SANDER STEFFANN: While standing here I was thinking on that, so, I think we
should stick with updating RIPE 554 at this point. Once we have that
finished, I think we should take the extra stuff to the list.
AUDIENCE SPEAKER: Just a comment. I might have misunderstood what Jan's
first point was. I want to clarify that the RIPE NCC is obviously happy to
help the language review and consistency checks and all that and I think
that also happened in the last versions of the document.
MARCO HOGEWONING: You stole my comment.
SANDER STEFFANN: That work is much much appreciated.
SHANE KERR: I agree. So thank you Sander and Jan.
All right, I think we're up to our last slot of the day, Edoardo Martelli is
going to talk to us about IPv6 deployment at CERN, which is cool.
EDOARDO MARTELLI: So, I will present the deployment at IPv6 as we did at
CERN. This is the agenda for the presentation. I will go quickly because I
don't think I have much time.
So, CERN. CERN is run a particular accelerator that is 100 metres
underground and is 27 kilometres long. We have a campus here, that is
10,000 people each day. So we have a large network too that is used for the
campus for the Wi?Fi connection, for the control of the accelerator, so we
have a cryogenic system that keeps it at the minus ?? plus 2 degrees. It is
controlled over the IP network and we have a data centre in Geneva and one
data centre in Budapest. We have 150 routers and route more than 2,000
switchers and 50,000 wired devices.
So, we manage this network with network system that we developed and it
takes all the information from a network database where all the devices are
registered with their Mac address and IP address.
So, we started playing with IPv6 in 2001, but for many years, we didn't
really have nothing to do with it. So, the development stayed in a corner
of the network until 2010 when the computer centre people fell in love with
the utilisation so they started creating virtual machines in large numbers
and they proved to be very useful. So it was soon planned to have a data
centre hosting 130,000 VMs, everyone needing a public IP address. Because,
we were going to upgrade our accelerator that is being upgraded now, and it
will generate more data than has done before.
So, the next was to approve deployment project and we allocated three people
for this project for two years. One for the network part and two for the
software development.
The project was defined in this way to be dual stack everywhere, to assign
an IPv6 address to every IPv4 ?? to every device that has an IPv4 address.
We wanted to have identical performance, so not to use devices that were
software treating the packets. We wanted to use the same tools that we were
using for IPv4, and give all the same services, network services. I work
for a group called communications system and takes care of the, all the
fixed and Wi?Fi and telephony networks and we are run the DNS and DHCP,
that's what I mean network service portfolios, that's what I mean these four
services.
This was the work plan of testing. Then one big job was to design the new
scheme for the network database that had to be compatible with all the
existing queries. Then we populate this had network database. We
developed, the plan was to develop the tools, configure the network devices
and then giving the tools to the engineers for the deployment and finally to
the End Users.
So, how did it go? I think it went well. So the network database has been
?? the schema has been completely changed and data ported to the new schema,
and IPv6 has become the navigation record before it was the pour address,
now it's the IPv6 address. And the schema is compatible with all the Legacy
query, so we didn't have to change all the existing sort before, first we
changed the database and then we changed the software, it was fine. And we
have all the campus data centre and firewalls and external router with you
will a the interfaces dual stacked. We haven't done it in the accelerator
underground because there are a lot of industrial devices that don't have
IPv6. And there was not a real need to rush into this on that one, and also
the L H C deinterconnecters are not ready to use the IPv6 for data
acquisition.
We assigned an IPv6 address to IPv4 one, so since we used the database to
generate the configuration of the DNS, every device got a name and an
address, even if it was not used in domain IPv66.CERN.ch, also for the
dynamic devices getting with an IPv6 address that could change, we used a
dynamic DNS.
Identical performance. This we did, we did almost everywhere. The only
exception is a point where we use the policy base routing to do, to allow
some kind of traffic to bypass the firewall, the stateful firewall, and this
is still software routed.
And so we don't have that service at the moment. But it's not operable
because we don't have a large volume of traffic at the moment.
The network management system, we developed the software that configuration
the routers for all the vendors we have. We generated the IPv6
configuration from the DNS network database and also the firewall, we den
rate the access list from (DHCP). That's because most of the users, even on
the desk top, they have fixed IP address public and they are allowed to run
services that are visible outside CERN, because we work in collaboration
with many universities, so we have many guests so users are allowed to
install our, any kind of service on their desk top or run even as more
computer centres in the offices.
Then we have this web interfaces, SDB web, that is for the engineers, and
Webreq for the users. I can give you a quick screenshot. This is the
interface for the engineers. And this is the firewall where we had an
example for the firewall, we have all the rules pour and IPv6. This is the
end user interface where, the user can register the device. This is their
name and then they get an IPv4 and IPv6 address and they get the information
of the name servers and time servers they can use.
But when we get the information with the DHCP IPv6.
We also implemented this IPv6 ready flag, and we have seen it here. This
allowed the End Users to decide when the DNS return, the name.CERN.ch
returns an A and AAAA records and that they do when the service is running
on their machine is ready to reply over IPv6 and v4.
DNS works over IPv6. NTP and DHCP. DHCP IPv6 was a bit of a challenge and
also there was one of the things that delayed us. We were supposed to
finish by 2013, we have just finished. And because we had to wait for
classes that were available only in the very latest version of DHCP of ISC,
the one we're using.
Common security policies. The security team didn't want to us to deploy
IPv6 if we were not block erring or filtering as it was for IPv4, so we had
to implement the software very soon before going for a new one in
production, and so we had to translate all the rules, we had over 4,000
rules, most of them were translated automatically but some needed special
care.
And also we have the software also manage anti?spoofing ACL everywhere where
we connected the users.
So these are statistics on last week. We saw 5,000 average, that is 55% of
the DHCP IPv4. The DNS the IPv6 addresses with the ?? so we see 200,000
queries per hour, 4% of what we see on IPv4. And this is the Internet
traffic, we see the pick of 60 megabit per second, that is 50% of our
Internet traffic. So again, as, it's probably YouTube, not much more, and
it's 5% of our generic traffic, but it's only 0.2% of all the traffic we
send. We send out a lot of data coming from the accelerator and this is
only on IPv4.
This is the timeline. I can skip. There are more information at this web
page.
So, challenges and lessons learnt. Benefits. We see on our group for ?? is
very easy management of addresses, is very easy to deploy new services.
There is nothing ?? of the the same size the sub?net. Before we had to
think every time we gave a /27, a shareholder 28, a /29 then we change. But
this single size, there is nothing to think. And also, it will stay
forever, so there is no chance that it will change.
The challenges we had to solve. Size of routing tables, so they using the
routers, there was a challenged. Everything has doubled. We have a lot of
traffic in our OSPF routing table so this supposed challenge is some routers
that have a low takeup.
There were new issues to be solved by support lines, so we had to train the
first line, second loin, third line, all the support we have to be able to
understand what it is IPv6 and, in order to relieve the engineering.
DHCPv6 is still in early stage, I will talk to you more in the next slide.
The security team had to learn new things as well, because they realise
quite soon that there were new threats coming in.
And unfortunately we have many applications that were written many years ago
and is very highly that they would be changed in order to use IPv6.
About the DHCPv6. So we are not using auto configuration at all. That's
because we use the addresses in the network database to generate the
configuration for the DNS firewall. And also to tracer users with map Mac
addresses and IP addresses, so we can understand what the people are doing
and help them in case of problem. And also we use as a light access
control. So when a user comes as is forced to register the Mac address, so
we know who he is.
So, the drawbacks are that we have to have a for the default gateway for the
mask length. And especially the default gateway is problem because we
cannot use to decide which gateway is used, this is made by the client. We
were used to control the gateway that the clients were using.
We use the Mac addresses for, to assign IP addresses, IPv4 addresses, and
this is not how DHCPv6 was supposed to work, we were supposed to use DUID,
but cannot manage the assignment of a DUID because we don't manage the
client, so we have put in place some tricks in order to get the correct Mac
address and also we are waiting for the implementation of this RFC that will
solve this issue.
And also there are many devices that don't have a DHCPv6 client by default
for the IOS up to version 6, Android, even the latest one don't have it.
Old Mac, Linux version, and all those devices still using
We are working with our user community to help them ?? well to invite them
to use IPv6, so we have a Working Group that is checking all the
applications we have that we are using for the physics analysis. And we
have an international Working Group that has made a list of all the
application and is checking that they are compliant or not, there is a lot
of testing we are doing to help our users use IPv6.
Lessons learnt:
We deployed IPv4 for almost 20 years, and it is taking time to catch up with
all the expertise developed during this time, and also with all the software
that we developed.
The network is the easy part. When it comes to ?? for us, a very long time
was ?? most of the time was spent in developing the software that managed
all the addresses and that generated all the configuration. When it came to
push the configuration to the network that was done really fast.
The DHCPv6 is delve not not DHCP v4. When we started the project we thought
it was the same but in fact it was not, and we learned it the hard way.
It helped a lot to have a staged deployment and to contact a large variety
of users, and also to keep in touch with them, because we discovered that we
were inviting users users, they had problems and they didn't want to solve
or don't even bother to tell us that things were not working, so having a
good relationship one to one with the users, or taking a group of users in a
room and seeing how they can use IPv6 or configure the IPv6 in the machines
was very useful.
We tested a lot, we emulate the load on to understand if our routers would
have been able to cope with the additional load, all the routes we were
adding, and I thought all the tests were okay only when we put it on all the
150 routers, we saw problems here and there. So, the test on the live
network is really important and will show ?? you have to be prepared there
will be a problem.
The developers. We all thought that everyone would have been happy to
implement IPv6 support. But ?? to use IPv6. But this is not what we're
seeing. So the developers of production application they are saying they
already have too many bugs to solve. I don't want to code the IPv6 support
and add more bugs.
Then the last chance that I wrote after the yesterday ?? no, two days ago,
was what was wrong with IPv6? So I wanted to make a comparison with IPv4 as
we did at CERN. So, we start /TKHROEUG pour ?? giving IPv4 connectivity in
1986 and the worldwide web was conceived recollect the idea came in 1989
because, there was a possibility to use terminals with IPv4. And three
years later it came out and was started using in the scientific world. So
this is already eight years after the deployment for IPv4, and at the time,
1992, the main protocol used at CERN was ?? and nobody thought it was going
to disappear, and but in fact, seven years later, it was phased out.
And Tim Bottesly was not an network engineer; he was a software developer.
So I think it's not up to a network engineer or our community to find the
application that will use IPv6.
More information at this website.
MARCO HOGEWONING: Thank you. Any questions?
AUDIENCE SPEAKER: Jenna, Google. A question: What are your plans for
those taking your external services? Because we have less than four
interesting presentations about web servers being unavailable over IPv6 here
and as far as I can see, your external services like mail server and web
server are dual stack. There any particular issues which prevent you from
doing that?
Yes, so the mail servers were moved to IPv6 internally ?? last week, for
other internal users. But they didn't want to open it for the external
users because of spam software we were using, that is not ready for IPv6.
This was the reason. And for web services we have a system that allowed
users to create their own web services, web servers, and again, it's only
available inside and they didn't dare to do it with the main www.something
website. That because we went into production with the network field two or
three months ago.
SHANE KERR: One of the things you mentioned is that there is new issues for
the support lines. And I remember way back in the day when we had the IPv6
world day, it was a concern that a lot of people had, a lot of training
sessions and things for their help desks and didn't see any additional load.
I guess yes, you need the procedures, but have you actually seen additional
questions because of IPv6 or anything like that.
EDOARDO MARTELLI: We saw questions people wanted to know how to use it, and
?? but no problems I found. So ?? maybe people that were not able to get
the DHCPv6 reply, we saw for instance, for the Linux version we are using,
there is a receipt to apply for DHCP table 6 was blocking the reply for
instance, so the Superline has to be trained to help them.
SHANE KERR: I do have another quick question, which is there are people
trying to work on secret plans to eliminate the need for RA, to incorporate
the functionality into DHCPv6. There are people who are very, very morally
opposed to this idea in the IETF, but I hope ultimately pragmatism will win
out in the end here.
AUDIENCE SPEAKER: You talk about the exportation and the support tools and
the management tools, are they all homemade or are you using some standards
support tools and did you encounter problems to use them with IPv6?
The second question is about the applications. You seem to have a lot of
specific application running over your system. And did you encounter
problems to use these applications in a dual stack machine or many
applications are still in IPv4, what have you planned for these applications
that you will move to IPv6 or not?
EDOARDO MARTELLI: So, first question, most of the network management is
homemade, so we are using commercial data but the rest of the software that
take up the information is homemade. So, no commercial software.
Second question, say again, sorry.
AUDIENCE SPEAKER: The second /TKPWE concerns the applications, you talk
about your applications that don't move to IPv6 ??
EDOARDO MARTELLI: Yes, one of the tests was to ?? is to check if they keep
working, if they are on a dual stack machine, even if they don't use IPv6,
because we saw cases where they stopped working because they tried to use
the DHCPv6 rather than v4, this is one of the tests, and we have Legacy
application like A F S, which is a distributed file system that we think
will never get IPv4 support, so we'll have to see how to manage the machine
that had need to access this. So if there will be servers visible outside
they will get public IPv4 addresses, so at the moment we are not at a point
where we can say we will phase out IPv4, because of this stalled base of
application. Also we have tape servers, they are zero IPv6 support.
AUDIENCE SPEAKER: Dual stack is a step or do you plan to go in future to
IPv6 only?
EDOARDO MARTELLI: At the moment, we are dual stack forever.
MARCO HOGEWONING: Okay. That wraps it up. Thank you. And as a final note
I would like ?? we running that IPv6 only service because if you are a
developer and you are looking into adding IPv6 also, be aware that you might
encounter situations where IPv4 is no longer available. So please don't be
dependent on that.
That concludes our presentations for the day. We're back to where we
started, our pretty faces on a big screen. As you may have noticed one of
them is missing, David is joining ?? enjoying his sabbatical and couldn't
join us here. For the people on the mailing list who saw his message are
already aware, David has decided to step down as a co?chair of this group
after 15 years of active service, which is quite an achievement I think, 15
years of deploying IPv6 as brought us to, where exactly ?? is Geoff in the
room? Which made us think, as a bit of a context in the background, there
have been discussions about should chairs be replaced or at least
reconfirmed at some period of time, just to keep things alive and keep
things going? So, with David stepping down Shane and I were thinking a bit
and we have also been there, four and a half, five years or so ??
SHANE KERR: A while.
MARCO HOGEWONING: And gradually things shifted. When I started this I was
running a network and I was deploying IPv6 and now I am completely moved to
the other side. Shane has moved around a bit. So, we are thinking of ??
well, A, filling a vacancy. But, we might decide to make more vacancies and
basically what we came up with is a plan to gradually rotate ourselves out
of the loop. How fast that will be, that is kind of depending on this group
and on the amount of volunteers we get in.
So, first of all, the way Working Group Chairs are appointed is basically
bay consensus of the Working Group, and the Working Group can decide on the
process. So there can be a vote, there can just be a discussion on the
mailing list, or maybe it's just a Working Group pushing somebody forward
and saying congratulations you now are Chair of the Working Group, as also
happened two people in the past.
SHANE KERR: Yep. I kept pushing for competitive assembly language
development, but that wasn't very popular...
MARCO HOGEWONING: Anyway, it's up to you. And, first of all, we would like
to invite people that think, oh wow, I am doing something with IPv6 and I
would love to go Chair this Working Group and help to further advance the
deployment of IPv6, so make yourself known, to the mailing list. That way
we know how many people are interested. At the same time, we'll probably
start a discussion on the actual process, if we get really many candidates,
we can start a vote. It's not being said that a group must have one Chair
or two chairs or three chairs. Above three it becomes a bit impractical, we
think, so, I would suggest to the group to stick with three chairs. What
will happen? David stepped down already. Shane and I remember discussing,
I think we're going to ?? Shane is going to rotate out in London. Maybe I
stick around for another one or two meetings to at least help with a bit of
continuity and a bit of institutional memory and help the new co?chairs on
their way. But it all kind of depends on the amount of candidates and what
the group decides. So if the group pushes forward two or three new people
and they decided that yes, we can do this ourselves, we're happy to step
down. And that kind of sums up what I had to say and I'm open for comments,
suggestions, volunteers who already want to fire themselves forward to this
stage and say yes, I want, I want, I want. And feedback on your general
plan. What do you think? Is this suitable? There is nobody standing up.
Come on. I feel we're stuck with this, Shane.
SHANE KERR: If you're interested in possibly serving as a Chair, you can go
about it any way you want. You can just announce it on the list. You can
stand up at the microphone here. If you are also curious about what exactly
is involved with being a Chair, how much time commitment you expect. Or the
logistics. You can talk to us or mail us, things like that.
AUDIENCE SPEAKER: Jan Zorz, I would first like to thank David for you will
his 15 years, I hope he is watching through the webcast.
MARCO HOGEWONING: Yes, of course, I hope to see David back at some meeting
in the future where we can properly say good?bye and thank him for all the
effort. Unfortunately, he couldn't make it here.
JAN ZORZ: So for the second thing, I have been involved with this Working
Group for quite a long time now and did some work. Currently, I am
co?chairing the pick?up Task Force, so I don't know how that would work
together, but if this Working Group is happy to co?chair, me co?chairing
this Working Group, maybe we can find the way to make it work. Thank you.
SHANE KERR: RIPE is quite flexible as an organisation. There are not
really many hard and fast rules. We try to just do it sensible the so, you
can talk to Hans Petter and maybe he has opinions about this sort of thing,
or ?? so... anyway...
MARCO HOGEWONING: Bear in mind that in the run?up of the meeting it can be
?? well it's not totally time?consuming but it can be a bit busy in the run
up of the meeting organising everything.
AUDIENCE SPEAKER: Jenna. I have been involved in the IPv6 deployment for
a while and I would love to see it multiplied and getting people more
enthusiastic, so if the Working Group believes I could help with it by being
co?chair, I would be happy to. I know you can adjust it one way, okay,
someone has to stay and help us, so ?? it's not going to work like that.
SHANE KERR: We're not retiring, like.
MARCO HOGEWONING: We will stick around at meetings but whether that will be
formal or informally, that's something that we can probably hopefully work
out in due pros, we won't leave you to your own devices. As a point,
although this session is recorded and transcribed and everything, please
repeat these nominations on the mailing list so people who are not here or
are not watching the webcast at least know what's going on.
AUDIENCE SPEAKER: Jenna: It's kind of a scare when all three people just
try and escape, it looks suspicious, okay. It's probably something I don't
know.
AUDIENCE SPEAKER: Dave Wilson, HEAnet. Well, you have two excellent
volunteers there, you should pick them. And I see that eventually there is
going to be simply slots available, when the time comes around, if I can
help I'd be happy to. That said, I think I was fair and clear about my
feelings last Tuesday, so if you ?? if anyone thinks that that's maybe not
the correct answer, then I won't be very upset.
SHANE KERR: Okay.
AUDIENCE SPEAKER: When I heard Jenna going up and volunteering, I thought,
wow, that's a great idea, I second her. And in case you more power and
nobody else steps up I'll do it.
AUDIENCE SPEAKER: Rob Evans, not standing, but just to say that I think
what you're doing is really good in terms of asking for periodic
reaffirmation of Working Group Chairs. It's disappointing that you won't
restand, because it could be that you know I think you might well have more
to add in the future. But I think what you're doing in kicking this off is
a very good thing.
SHANE KERR: Thank you.
MARCO HOGEWONING: With that ?? no further comments? Anything online? Then
we're exactly on the dot finished with this Working Group.
SHANE KERR: Thank you everyone. I hope we see you in London.
MARCO HOGEWONING: See you in London. And do feel free to test the IPv6
only network. Thank you.
LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
