These are unedited transcripts and may contain errors.
IPv6 Working Group
Thursday, 15 May, 2014, at 9 a.m.:
SHANE KERR: Good morning, everyone. It's 9:01, I think we are scheduled to
start at 9:00. We shouldn't have such a too packed agenda this morning so
that should be all right. First of all, this is the RIPE IPv6 Working
Group. If you are looking for another Working Group, you are in the wrong
place or way too early, maybe.
So, let's go ahead and get started. We are good. Sorry.
So, anyway, as I was saying, good morning. This is the v6 Working Group.
On the slide here you see your Working Group Chairs. And we see a little
asterisk there and if you can read it in the bottom, it says these are your
Chairs for this meeting. We are going to talk a little bit more and try and
get new Chairs in, so we will discuss that at the end of the second session.
Anyway, we have got David, Marco and myself, and I think David and Marco are
both sleeping and happy in their beds right now.
All right. So this is not the first meeting we have done it but there is an
IPv6 wireless experiment here, this is in IPv6 only network. It's probably
the effort to kind of shake out the bugs and systems, everything has been
designed for dual stack to date and so on so we have an IPv6 only network.
There is two this time with these different SSIDs, the password you can see
there. It was sent in a message to the mailing list last week, it's on the
website as well.
In the various messages there is scary warnings about best effort demand and
things like that, don't use it for heart surgery or whatever, but I would
actually encourage to you try using it for the most mission critical things.
It's a wireless network, I don't think it's any less reliable but it's best
effort.
So this is the agenda for our first session here. It's very slightly
different from what we have gone on?line. We are going to start off with
Niall talking about his IPv6 campus deployment experience. We needed to
make sure that he was available for the second morning session somewhere
else, so we went ahead and put that first. You can see the breakdown here
of all the different things.
We have a few more discussion?orientated topics talking about various
documents and things like that, those are scheduled for the second morning
session. It's possible if we seem like we have a lot of extra time this
morning, we will move one here earlier to take best use of time. I don't
actually expect it so don't fall asleep and only read your mail, pay
attention. We may have some interesting discussions.
You can see the kind of things we are going to be discussing, Bcop document,
IETF document, new stuff for RIPE. As I mentioned at the beginning, we are
going to talk about IPv6 Working Group Chair replacements at the end there.
OK. So, with that, I guess we are ready for our first presenter. Any
questions before we get started? Ready to rock and roll?
MARCO HOGEWONING: Apologies. It was the elevator.
NIALL O'REILLY: Good morning, everybody. What I want to do this morning is
to tell you all a little bit about what we have just been doing in UCD. Our
IPv6 has been on hold for a long time. First, let me get some sense of the
room. How many people here are working for an enterprise or a university or
something, something that is not primarily an ISP? OK. So, some of you ??
how many of those have actually deployed IPv6 on their campus? Sorry, can
we take the first show of hands first again, sorry. A couple of does. And
of those, how many have actually rolled IPv6 out campus?wide or in a
significant deployment. So a bit more than half of those. Thanks for the
prompt, Shane.
So, I am going to give a little bit of background, talk about the goals of
the recent project, mention what the results were. This is the wrong set of
slides but that won't matter. I made some tweaks to them but the ?? this is
the old one. I will talk about not so much the reasons but my assessment of
what the experience tells us and what the prospects for the future are.
UCD, as some of you might know, is Ireland's largest university and we have
been playing with computers and networking since a long time before we got
our hands?on IP. We have been on the Internet since 1990. We were on the
e?mail, sort of gatewayed Internet long before that, and we are a Cisco
shop. I mention this simply because that restricts the kind of data points
I can offer to you. It's not because I want to do a marketing spiel for
Cisco or even to beat them up.
We weren't starting from scratch. I should mention that the motivation for
doing this was that, next week on our campus hosted by HEAnet is Terena's
big annual networking conference and we were told that the people at the
Terena know conference would really need IPv6 and I was delighted with this
because I had been looking for an excuse to do some more progress with IPv6
for quite a few years, but we had some of the work done quite a few years
ago; we had an IPv6 addressing plan, which is apparently a good thing. We
were running BGP with HEAnet; over tunnels admittedly but still BGP. We had
got our fingers dirty with OSPF version 3 and we had our publically
accessible access dual stacked which was a good start. One or two people,
myself and another colleague on a test LAN with client devices, so we didn't
really have any penetration but we had at least done the feasibility
demonstration and we went into this project end of January with a bunch of
non?problems. We were tunneling and not native, which is not best. We had
some strange problems with SLAAC that the RAs weren't getting through. We
had aband done after doing the DNS servers we abandoned sixifying some of
the other servers because we discovered the server configuration was too
brittle, and we didn't address that in this project. We didn't' have any
wireless and a couple of v6 routers that were doing this stuff were
maintained by the project team, which meant me, rather than our net ops team
so they weren't part of the production network. We had one strategic goal
for this project and that was to position our organisation so that if we
wanted to do further IPv6 deployment, the Net ops team would know how to go
about it and the knowledge wouldn't be hidden between the ears of one or two
enthusiasts. And we achieved that goal.
The operational goals are more detailed and we had eight or so of those and
we wanted to get OSPF v3 not on the backbone LAN. We wanted to go native
with IPv6 through our production boarder routers, with of course BGP. We
wanted to introduce some wireless IPv6 and some cabled IPv6 in some of the
buildings that would be used for the Terena conference. We wanted to do at
least some of what was needed for BCP 38, replace our bypass routers with
dual stack on the production routers. Solve the missing RA problem and
solve the traceability problem which I gather is fairly widespread in IPv6
and indeed I know that there are some Ed /RO*E sites who don't offer it
because they can't meet the traceability requirements because the Layer 2,
layer 3 address binding isn't working properly and we wanted to retire the
test LAN. And we had a mix success.
Some of the goals we were just able to reach, things just worked, the other
ones, the four I have marked with orange crosses, it's rather than red
because we found work arounds, the problems didn't go away. I will talk
about those work arounds in a minute.
But first, a little graphic to show you this was the situation at the end of
January. We had a small, the orange links and end points are where IPv6 was
available. So we had a couple of tunnelling routers connecting to HEAnet
and we had bypass routers doing the IPv6, and connecting into a couple of
VLANs where we had the sixified end systems.
And the situation then at the beginning of April, eight weeks later, was
that we had ripped out the bypass routers, we had to put in a couple more
and I will explain why in a minute and now we had IPv6, in all the places
that were going to be needed for Terena and we had sufficient transfer of
expertise into our operational team that if we need to sixify another
building, we can sixify it on demand.
So to come to the specific problems, on the BCP 38 side we thought it would
be nice, we can rely on Unicast reverse paths, verification, but no, that is
not available in the access boxes that we happened to have. So we had to
work around that with a per interface ACL and we used the same access
control list to ?? now ?? we used the access control, it's a per prefix
access control list. You can see the last word, the last 16?bit word of the
address before ?? of the network specific part of the address is matched in
the name of the access control list and so we have ?? we have to do that per
prefix which effectively means per interface because with IPv6 we don't need
multiple prefixes per interface much, and we also tried to solve the address
binding information problem by putting in logging for neighbour
advertisements.
I say more about that in a minute. That is how we had to work around the
BCP 38 issue.
The dual stack versus bypass routing issue, we had a mixed experience there.
On the border routers, because of the kind of routers they were and the kind
of software image they could run, there was no problem, and likewise, in the
core of the network. On the access side, we found that we had weirdness if
we were using old kit and default images, that is to say release 12 rather
than release 15, and this was what turned out to be behind the missing RA
problem as well.
On our server farm there were too many depend sees and too high risk of
damaging services so we couldn't upgrade those to a recent image, and we had
to put bypass routers in there instead. And it's always a solution that is
available, even if it's not obviously ideal. Because it means you need more
capital equipment, but you decouple the ?? decouple problems on the 6 side
from problems on the 4 side.
The missing RA problem was kind of weird. We could see solicitations come
in from clients and advertising going out from the router and the
advertisement never reaching the switch port where the client was connected
and as far as we were aware, everything in between ?? the router of course
was virtualised in a layer 3 switch, and as far as we could see, everything
between where the RA was being generated and where it should have been
delivered was switching and we would have expected that to be simply carried
at Layer 2, but it wasn't arriving, and we didn't really have time to
investigate what was the underlying cause and work out which releases, where
the boundary was between the good and bad releases, we just said, hey, we
have a show to deliver, we will put in latest boxes from the inventory,
latest image, and it worked. So that is something to work ?? that is
something to watch out for if you are using ?? we have a lot of quite old,
some of them formerly beyond end of life and support, but they are still
working and not broken and we don't plan to fix or replace them and the
scheduling of the capital budget for that will happen when we decide they
are broken.
On the address binding side, the access list I showed you earlier didn't do
the trick. I was able to plug in my own laptop and not able to find its MAC
address in the log files so I knew that this wasn't working. That was on
the copper side. On the wireless side we got some very helpful hints from
people at the University of /HR*UF /PWURG which said the controller we were
using actually could be told to log general ?? well, would generate log
message and if we adjusted the log message filtering we could get them
delivered to where we needed on our central logging server. So we were able
to solve that problem on the wireless side but not on the copper side so on
the copper side we conclude that IPv6 is still unmanageable. And the sort
of assessment of the experience is that the manufacturers support for IPv6
is still evolving. For example, we were able to find releases in the
15.something series which were ?? which appeared to have the features that
we wanted, but weren't ?? didn't appear to be supported on the new equipment
that we had just bought. So it was a difference between 15.2 and 15.4, and
so we ?? the problem is the manufacturer may have sold the problem but
whether that solution is available to you on the equipment you have and the
images it will run, isn't necessarily obvious. And so some of the
management requirements weren't reachable, and I ?? it occurred to me over
dinner last night with some friends that the thing with IPv6 is that the
notion that we need an ecosystem which will support network management using
available tools, doesn't seem to have informed the thinking of the people
designing the components, especially DHCPv6 but also some of the other bits
which we need to deploy to make IPv6 work in our networks.
So, what I think is likely to happen after the Terena folk have gone away,
is that we'll withdraw IPv6 on the copper access networks, we will keep it
in the server farm. We will keep it on the ?? in the core of the network
and on the border routers, we will keep it on Edgiroam so we will be able to
offer that with IPv6 which not everybody is doing, and we will defer further
deployment, as far as I can see, until the manageability gap is closed,
either by spending more money to ?? when we can schedule capital upgrades or
by being surprised by the manufacturer coming out and saying, oh, this image
will actually run on your access switches, we will see what happens. But,
you know, there is ?? that is where I think the thing is. And to finish,
some of you, I guess, will recognise this signature line that comes
frequently enough into my mailbox and finally, we have an answer in these
statistics that HEAnet have made available to me for that question.
And that was Thursday the 27th of March. Before the questions, I'd like to
just acknowledge the team at UCD who worked energetically and
enthusiastically to make this possible for the Terena gig; the friends in
HEAnet who worked to get the BGP going and were there always when we had
questions and were looking for advice. Also, way back in 2007, especially
Anand Budhev and Alex Gall who helped me test the reachability of my name
serves over IPv6 from their places and the folks in Lufbra who gave me the
hints about the wireless controller.
So as the ?? some radio personality used to say, if you have been, thanks
for listening.
MARCO HOGEWONING: Thank you. Questions?
JEN LINKOVA: Thank you, very interesting, I am gad to see that you
succeeded.
NIALL O'REILLY: It took some determination. But it wasn't really a war
story.
JEN LINKOVA: Ah. That is good, yeah, it's kind of positive side, yeah. So
the question, what was the scale especially for radio? How many users you
have or you expect to have?
NIALL O'REILLY: I think it's about 6 or 8 /22s. In terms of IPv4
addressing. So we get ??
JEN LINKOVA: In terms of users?
NIALL O'REILLY: Users is difficult to say because our wireless network gets
populated by about 3 devices peruser. So you have tablets and phones and
stuff. But in terms of real users, really using IPv6 ??
JEN LINKOVA: Devices, devices using your IPv6 wireless network?
NIALL O'REILLY: Well it depends on the post tour of the device as well but
certainly we would see a couple of tens of thousands of devices on our
wireless network.
JEN LINKOVA: I am asking because it's well?known problem with scalability
sometimes on the wireless in terms of seeing excessive amount of race being
sent which might affect the battery life of the devices, so if you ??
because my understanding is you are preparing for the conference so you
would expect to see a lot of people coming right, and you don't have them
right now. So just a comment that you might be interested in, is there ?? I
don't know ?? I think it should allow to you do that, either send solicited
RAs as Unicast or probably using the RAs router ?? if you see thousands of
people simultaneously connecting, you will see a lot of race, the battery
life just goes.
NIALL O'REILLY: That will be an interesting user experience from using IPv6
on wireless. I haven't noticed such a problem on my own tablet because we
were at least using, without having announced them to the customers, we were
using Edgiroam and the TNC ?? the TNC SID already at the beginning of April
and mostly they were just working and I didn't notice any excessive
surprising battery drain on my device. What you are saying; when we add
loads of customers, the noise level on the network goes up and that hits all
the ?? that may be mitigated by the wireless controller we are using,
because all of the access points, tunnelled back to the central wireless
controller and it's much less ?? it's a much more controlled environment, I
don't say it's less noisy because I don't know but it's a much more
controlled environment than we would have had before with autonomous access
points. So thanks for the warning. And we will see how it goes. I am sure
the Terena folk will let us know what they think of our network.
AUDIENCE SPEAKER: Probably they will be do so. Wilfried Woeber and we have
been playing with IPv6 for a while as you probably are aware of, and I'd
like to have one reading about the potential for IPv6 on the scalability.
We were pretty surprised when we were made aware of a paragraph in the most
recent Akamai report about the last quarter of 2013 and it turned out that
Vienna university had 43% of IPv6 traffic to and from Akamai out of 100, and
I think this is something to keep in mind ??
NIALL O'REILLY: Nearly half of Akamai's traffic was identified with
University of Vienna?
WILFRIED WOEBER: No, the traffic ?? the other way.
NIALL O'REILLY: Sorry, nearly half of University of Vienna's traffic was
Akamai was IPv6?
WILFRIED WOEBER: Yes.
NIALL O'REILLY: That graph that slipped off the table a moment ago, what
Dave Wilson was able to capture from his instrumentation for me, the blue is
the percentage of total UCD traffic, which is IPv6. So it goes up at some
stage to 11 or 12% on this big peak on the far right, and ??
WILFRIED WOEBER: My wild guess would have been in the range of 10 to 15,
maybe 20, but 43 is a real surprise to us.
NIALL O'REILLY: It varies very much with application. One of the things
that happened a little over a ?? nearly a year?and?a?half ago, was that we
sixified our mail service because we outsource it had to a well?known
provider ?? we outsourced it to Google so as soon as any of the people in
our building or on the two SIDs that we were offering IPv6 was on was using
a mobile mail client or something so they were doing it by six and we were
seek plenty of mail traffic over 6.
BENEDIKT STOCKEBRAND: About maybe half a year ago ? from Google pointed me
towards a document from university in South Africa, I am not sure if it's
Peter Marz or something like that, they turned on IPv6 on to entire campus
and had 54 or 56% of the traffic at v6 immediately, which was basically
YouTube, YouTube, YouTube, and I think YouTube. Yeah, but that is not that
much ?? so as soon as you turn this off entirely, turned it on entirely, a
lot of devices will use it and it will probably already hit you fairly hard.
It's not like 10 or 20% or something like that any more. You shouldn't
expect that, especially if you are also connect the student dorms, whatever,
through your networks. It's going rather fast, especially if you have newer
machines with Windows 7 or something like that and not all the speeds other
people use.
NIALL O'REILLY: I think on the wireless ?? on the copper side we can also
deliver is except it's not manageable because we have no traceability so we
are not going to open that up.
BENEDIKT STOCKEBRAND: What are your traceability requirements? Do you need
it legal ??
NIALL O'REILLY: Part of the Edgiroam charter is that we keep the radius and
DHCP in the v4 environment logs for six months, so that the radius logs give
us a binding between an aunt entericated user and MAC address and the DHCP
give us the binding between the MAC address and IP address so every is
traceable to a user in case there should be some need to follow up with one
of the other Edgiroam partners over abuse, they can say we had this abuse
from one of your addresses, can you find out who it was and if it was one of
our people, a tourist in your campus, we will deal with them, and if it was
one of our people, you will please deal with them. And that is part of the
agreement and I was visiting last year one of the other European Enrens for
a meeting, we had it in their office, I found no IPv6, why? And the local
colleague said to me, it's a violation of the Charter. So that is the ??
that is the requirement that ?? but even for our own internal purposes we
see things in web server logs and whatever by IP address, we need to be able
to trace that back to something that we can identify with the user and
traditionally that has always been the MAC address.
BENEDIKT STOCKEBRAND: If you need this to be legal evidence, if you have to
go all the way to that point, things get really ugly. What you have is not
quite as bad. So it could be worse.
NIALL O'REILLY: Oh, it could always be worse.
JEN LINKOVA: Very quick question, just curious. Before you do have ?? you
use tools to conform that user is using IP address which was assigned by
DHCP, right, and not statically configure ?? pause just DHCP maybe does not
mean your malicious user was using that address.
NIALL O'REILLY: I am not sure that we are completely proof against
malicious users; in fact, I am pretty sure we are not. But of the vast
majority of our users want to use the network and the set?up, the tools we
have seem to be adequate for that kind of thing. And in fact, we have
ported support for the log records with IPv6 records ?? IPv6 addresses from
the wireless controller, and from the access list that I showed you earlier,
into our logging tools and our ?? the database that we used to index the log
files and the web interface that we used for querying that database and all
of that is in place and and working and it was ?? a small bit of playing
around with regular expressions in pearl and we just, to parse the other
records.
MARCO HOGEWONING: OK. Thank you.
(Applause)
So, next up, and by the way, I am sure Shane introduced me, I am Marco, the
other Co?Chair of this Working Group. Next up is Janos Zsako with what
their observations are in IPv6 in Hungary. You need that to be plugged?
JANOS ZSAKO: Yes, I need a couple of seconds, I am sorry.
MARCO HOGEWONING: I will just keep talking. We have got a few seats left
in the room, if we run out we have got a side room available downstairs, if
we fill it all up. You are ready to go.
JANOS ZSAKO: Just one second. Good morning. I am from the council of
Hungarian Internet providers and we are actually running the dot H ?? and
the Internet Exchange in Budapest, BIX. We are also five star LIR with 100
percent IPv6 availabilities, so we decided to make some measurements, let's
say, of how much IPv6 is used in Hungary. And well, I am aware that there
are very many, many different measurements which were done by different
companies, different people, and which show very different results; for
example, Google says.23%; Cisco says 18.13%; APNIC, which is basically Geoff
Huston and George, present here, they say.12% of IPv6 preferred flash.
So these results are very, very, very different. And well, basically, this
kind of reminds me of a joke which I once heard, that two accountants meet
and one of them has a nice bike and the other one asks, where did you get it
from? Well, you know, I was walking in the park and I just saw a very
pretty young girl and when she saw me she dropped her bike, she took off her
clothes and told me, you can take whatever you want. And the other
accountant says yeah, yeah, that was a good choice, her clothes wouldn't
have fitted you anyway.
So I think that there are very different ways of looking at the same thing,
and at evaluating the same data, depending on how you look at it. And I
tried to offer you a different view, which is neither the bike nor the
clothes, actually.
So, I have investigated the different aspects, namely the DNS, which was
started from the dot H U domain, the mail services, namely how many domains
have MX records which are available over IPv6, and the web services. I also
compared a bit the traffic at the Internet Exchange over IPv4 and 6, which
is as you will see, very ?? well, very interesting in a way.
So looking at the DNS, first, I started from the name servers of the dot H U
domains, as I said, and we have a requirement at the dot H U TLD, namely to
have an operational zone when you register the domain and, also, when you
try to change the delegation. So, we have ?? we also log at the moment of
the delegation whether that domain had or didn't have IPv6 available or
enabled name servers. And it turns out that in the database, we see that
around 8% of the domains had IPv6 enabled at registration of delegation.
And well, basically, half of them had even several name servers; some of
them has ?? had as many as seven different name servers available on IPv6.
So this looks quite good. 8% of the domains have at least one name server
and half of them have even several. Well
Well, there was a different view, actually, so it was a surprise that when I
checked whether all these name servers which were IPv6?enabled at the time
of the registration, whether they still worked, and it turned out that the
huge amount, over 20% of them, no longer had IPv6. At the same time, a lot
of domains which didn't have IPv6 at the delegation, turned out to have IPv6
because IPv6 was turned on later without changing the delegation, so it was
turned on on the name servers.
So, all together, there are about 14% of the domains which have IPv6
reachability, so the name servers ?? their name servers are reachable over
IPv6, and a lot of name servers disappeared; however, a lot of them appeared
without being ?? without the TLD being notified so this is the blue part of
the graph, basically.
Now, if ?? well, I also wanted to know whether the registration data which
we have in the TLD database is that bad or not, because that was a surprise
that the IPv6 changes were quite significant, and then I investigated
whether this also applies to IPv4, and actually, turned out that only
roughly 1% of the domains had a change in their name server structures so
the ?? they either had no name server available or just one of them, while
the registration rules required for two.
So, this was reassuring that the database is good enough, but it turns out
that the IPv6 enabling is changing very much, so if the name servers move
from one provider to the other, for example, IPv6 may be available at the
new provider or the opposite, it could no longer be available.
So, I also looked at the regional diversity of the name servers and it
turned out that a large portion of the IPv6 available ?? enabled name
servers in the dot H U domain are outside the RIPE region, so basically, 32%
of them or one?third of them are outside the region. It's interesting to
note that there are no name servers either in the AfriNIC nor in the LACNIC
region. So, also, it's interesting dimension that although 32% of the
domain ?? of the name serves are outside the region, only 6% of the domains
are served by those name servers. So, basically, the number of domains
which are served by the name servers in our region, is by far bigger.
Now, I looked also at the geographical diversity, how many countries are
involved in providing IPv6?enabled name service to the dot H U domains, and
well, it's not a big surprise that Hungary is among the largest countries.
However, it was a surprise, at least for me, that Austria has more domains
served than Hungary. I will come back to this. So you can see here a list
of the domains ?? sorry, of the countries which have name servers that serve
dot HU domains and among the top ten US and Hong Kong are there. I will
quickly run through this list. You can see them on the slide. There are a
lot of countries, smaller countries, larger countries, even Lichtenstein is
there so, that is interesting.
I also looked at the topolgical diversity and it was reassuring that roughly
320 different ASs were involved in this, and 40 of them were in Hungary and
Austria alone, so this means that a lot of Internet service providers which
are present in Hungary do have IPv6?enabled. And well, the largest chunk
here is the academic network, with 32 name servers?enabled with IPv6
enabled. However, if we look at the number of domains served, Austria and
?? an AS from Austria is serving close to 50% of all domains available on
IPv6. So this was quite a surprise, and well, I did some research and found
out that two large registrars have basically one or even both major name
servers in that particular AS. So this ?? which kind of distorts the whole
measurement in a way.
Now, I also looked at the way the data was registered in the RIPE database
?? sorry, not the RIPE only but the RIR database, and I found out that this
is very various so there are a lot of different statuses here. We can see a
lot of different statuses but it turns out if we look at the policies, in
particular in the RIPE region, we know that every IPv6 chunk should be
registered in the database, and there are ways to register it; namely, it
should be in the status assigned or if this is ?? there are a lot of clients
which are ?? a similar set?up, kind of, this could be aggregated by LIR, and
it turns out that very little proportion of the address space is properly
registered. So, close to two?thirds are registered improperly or rather, I
would say, they are not registered because they are ?? they have the status
allocated by LIR or allocated by RIR. So, basically, the end user is
neither shown in an assigned way or ?? nor is it stated that the LIR has a
lot of customers of the same kind.
Now, I also looked at the ARIN and APNIC region, but the situation there is
a bit different because, in their policies, they state clearly that if the
business requirements are such that the end user prefers not to appear in
the RIR database, then it could be omitted. So there we can't say that this
is definitely a wrong registration; rather, that they don't want to disclose
it. And basically, 96% of the address space is in this way unknown to who
it is actually assigned.
In the APNIC region, it is very, very similar, with the exception that there
is just one single ?? I found just a single registration which had the
status assigned non?portable as opposed to allocated portable.
Now, I investigated whether these name servers are available over IPv6,
so?so far, I looked at the question whether they do have an IPv6 address.
Now, it turns out that the situation is good because if there is an IPv6
address, then 96% of the name servers appear to function properly, and 4% of
them are unreachable, which means that they are unreachable on IPv6
altogether so no ICMP applies either.
Now, if we look at the number of domains, this is even better because 19% of
the domains which have an IPv6?enabled name server, are indeed reachable.
So the DNS does reply.
And now I also looked at the mail service, as I said, and I also started
from the domains and it turns out that 90% of the domains have MX record and
10% don't want to receive mail, probably, and out of those 10% which are not
?? do not have MX records, most of them simply do not have an MX record;
some of them are not reachable because the MX record given belongs to an
unexisting domain and so on, or it is simply not responding.
Now, those that have an MX record, it turns out that the very small
percentage, namely 0.6%, has an IPv6?enabled MX. So this is kind of very
ugly picture. However, if we look at the ?? ?? so out of these 0.6%, there
are several which have several IP v6 addresses, so in this case, up to 4,
but we shouldn't forget that that is very small percentage. If we look at
the number of mail servers, though, then it is ?? the situation is not that
bad, because 4.28% are ?? have an MX reachable or over IPv6.
So we can see here better. Now, out of these domains ?? these name ??
sorry, MX records which have IPv6, it turns out that more than half have
several IPv6 addresses. Some of them have as many as eight IPv6 addresses,
which means that mail is important for those domains, most probably.
Now, I also made a quick comparison with the IPv6 world ?? sorry, the IPv6
world with the IPv4 world, and the figures are very different. 90% of the
MXes have IPv4 addresses, so that is, as a reminder, that is the other graph
shown, which is completely different, and out of these 90% MXes, a
reasonably large percentage, roughly one?third, have several IPv4 addresses,
and it was kind of a surprise that some domains had 48 different IPv4
addresses for the MXes. So apparently these people are very, very keen to
receive e?mail.
I also investigated the percentage of errors, which is probably not that
interesting; however, I also investigated whether the MXes are indeed
reachable or not, and it turns out that over IPv6, 70% of the mail servers
which do have IPv6, are indeed reachable, which is kind of a good result.
Now, as far as the web is concerned, I started from Alexa, which is probably
well no one to everybody, kind of something we could expect is that the top
4 are actually not from Hungary, so Google dot Co. dot HU Facebook, probably
YouTube YouTube YouTube, so it's not a surprise, and 93% of the websites are
not available over IPv6, so ?? which is not very encouraging. But some of
them have several IPv6 addresses.
Now, if we look at the statistics of the Internet exchange when I first
looked at in February, the situation was that basically, roughly half a
gigabit per second traffic peak was a daily average. It appears that in
April this took up somewhat so there are peaks of 12 gigabits, but this is
far from being constant, so if we look at the statistics, this is very
different from what we see over IPv4, which is 160 gigabits per second on
the average.
Now, if we come to the conclusions, I think that one of the major
conclusions we can draw is that the differences which we can see on IPv6
deployment, depends whether you look at the access side or at the server
side or content side, and I think we are much better with the content.
There is a large topolgical diversity. There is room for improvement, I
will come back to this, and also we can conclude that where IPv6 is
available, the diversity is not that big as in IPv4, which probably means
that resilience and availability is not as good as in IPv4.
And I think that is ?? for this group in particular, I think there is a lot
of work to be done with clearing up the database if we want to abide to the
policies.
Just as a summary, there are about 13% of the domains that resolve over
IPv6; 3% can get mail; and 7% of the website are available, so of the
content probably is available over IPv6. And the traffic is many, many
times lower at the Internet Exchange as we have seen.
And I just want to thank you.
SHANE KERR: Great. Thank you. I think that was really interesting. We
have a few questions I saw on the Jabber room. I have a question, though:
It seems weird to me that mail is such a low penetration because it seems to
me like the easiest thing to turn on. Do you have any theories or did you
talk to anyone about this stuff here?
JANOS ZSAKO: Well, actually, I do not know what the reason is and I didn't
have the opportunity to talk to the providers to see ?? to find out why this
is the case. But I am kind of ?? I kind of think that this is also because
the access, as I said, is not much deployed, so there is not ?? it is not
widely spread so the servers in the backbone or in the core could have IPv6
but it doesn't help much, probably. So that is my impression at least, I
may be wrong.
SHANE KERR: And I could also be wrong about how easy it is, as well.
AUDIENCE SPEAKER: Andrei SIS net. I have a few remarks for the e?mail
service because I am operating automated responder test, it ?? where you can
send mail and take a reply over IPv6 and see if you are able to send to IPv6
only and receive from IPv6 only mail server, and I observed few other things
that just ?? address ?? for instance, many addresses like 30% of MX records
with IPv6 address doesn't respond to DC P connect to the port, when you are
lucky enough to connect to DCM P service you can ?? for instance, some IPv6
only host name and it responds with invalid host name. And there is also
other anti?spam, anti?malware, our measures that are IPv4 only, even if you
are communicating with IPv6 with SMTP server it mean you can deliver mail
with IPv6 only so it's quite horrible in the case.
JANOS ZSAKO: Yes, I agree. I have also looked at kind of common errors in
the MX records and it turns out many times it's local host, for example, or
there are IP addresses inside instead of F Q D N and so on so there is a lot
of bugs but I don't think I have enough time to show all the results. But
it's a very valid remark, thank you.
SHANE KERR: I am going to actually cut the lines at this point. There is a
lot of interest ?? one more.
Ingrid: A question from Alexander in the chat room, he asks if this
percentage of MX web service or percentage of dot HU domains with working
servers? And his second question is who are the champions of turning IPv6
on in Hungary?
JANOS ZSAKO: Well, I think the first question was probably addressed so I
tried to put on the slides every time whether I am talking about name
servers, mail servers or other domains served by those. And obviously, we
can see a big difference and the percentage of servers which we see is much
lower than the percentage of domains served by those servers. I think this
is what the first question was referring to.
The second one, it is very difficult to tell, actually, but obviously the
academic network was one of the pioneers to introduce IPv6 in Hungary and
that was many, many years ago, so I was not trying to investigate history; I
was just trying to concentrate on the current situation.
AUDIENCE SPEAKER: Sebastian. We run a scan on the zone to find out this
very same information and we see that kind of the same proportion of ?? so
higher level of adoption on name servers compared to adoption on mail
servers and web servers but we go in and scan all domain names and we scan
for A records and AAAA records so we can share notes after this. So this is
very interesting.
We also have IPv6 task force in New Zealand and we compile 9 different
metrics of IPv6 adoption in the country so you can actually go and take a
look and grab some ideas of how to measure all this stuff.
JANOS ZSAKO: Thank you.
JAN ZORZ: So, regarding the mail server, of course, I ask many operators
around the world why they are not enabling the mail on v6, and also running
my own mail server, I see the same issues as everyone else. So this people
usually uses the black?listing as a spam litigation thing on IPv6. Oh, my
God, it doesn't work. I tell them, why don't you use SPF, all these things
that are working on IPv6 also. And they don't know because that is quite
new for them, right? And the problem is, the problem is not quite a bit
soft because frank Martin from linked in wrote a brilliant paper how to run
e?mail on IPv6 and I am trying to talk to him about turning that into
pick?up document and shipping it over here to the 6 Working Group, together
with certificate /TKPWA*EU ?? coming from Mirjam, it's on RIPE Labs.
AUDIENCE SPEAKER: That was very interesting, I will try to be quick.
George. We do a simple quantitative measure, we measure at the edge, end
user capability and preference and we are getting around 90 to 100,000
thousand measurements a month from your economy so at the quantitative
measure of end user capability, yes, we see a low number and it is different
to Cisco's number and to Google's but I think there are differences between
how Cisco, Google and we construct our numbers and ours are very simple and
straightforward, where I think Cisco is a combination, I don't understand
their mechanism, and Google they are quite owe paying about the mechanisms
they use to arrive at that number. What you are doing I think in some
senses is a qualitative assessment of capacity and capability. Yes, it had
/TPHAOUPL Erik qualities but you were assessing qualities of MXes and NSes,
/ of different behaviours. They are at the core, they tend to be in the
/ centre and we all know the centre is better than the edge. So it doesn't
/ surprise me that an edge measure that we do is so much lower than your
/ sense of capability.
Third thing ?? sorry, I will try to be quick. I looked in HE, that lovely
display Martin has done of BGP connectivity and almost all of the top set in
Hungary are covered through tunnels of HE, tel /STPHAR I can't so there is
the much richness coming out and there is a possibility because we are
measuring from ? there is a point problem a lot of our visibility is covered
by a similarly small set of people and there may just be specific problems
along the path. I will say from this network and from our network in /H*ETS
in a, I was struggling to get trace routes to complete inside the Hungarian
v6 space so I suspect there is engineering around traffic transport that
still have to be looked at. The richness of the peering it narrows very
quickly and it's not as rich as 4 thank you for the talk that was lovely.
JANOS ZSAKO: Thank you very much. I am glad that you have mentioned
Electric because they are carrying a large portion of the traffic which you
saw on the Internet Exchange there.
AUDIENCE SPEAKER: And NCC registration services. I would like to comment
about the point that you brought up about the quality of the registration
data of IPv6 compared to IPv4. And yes, this is something that we have been
thinking about a lot as well. The difference between IPv6 and IPv4 is for
IPv4 an LIR would come to us once every six months, once a year, would
request more IPv4 addresses, we would explain in the meantime what changes
there had been in the policy, we would help them to keep the registration
data accurate so that is why the very high percentage of accuracy.
For IPv6 we are not received addition
JOHAN AHLEN: Ication request yet so that shows with the regular pool of v4
running out and no additional request for v6 we are contacted far less by
LIR so far.
Especially in the cases with the registration of data, the policy changed in
2011, before 2011 you were not required to register user assignments the
RIPE database. So many LIRs are not aware of this change that happened over
time. We have decided to prove the process that we had to contact LIRs
practically ourselves. We used to do this through an auditing process which
was very heavyweight and we received that feedback during the RIPE meetings
as well so we reviewed this process and created registry check which is a
very lightweight process to help LIRs to keep their data accurate. So we
contacted them, we do all the preparation work in one or two e?mails and a
phone call, we help them to do that and from the mobile policy changes. So
that is one side that we are working on and we did the first trial of 50
cases in the last couple of months, it was very successful, received good
feedback and we will start with this after the RIPE meeting. And the plan
is to contact 3,000 LIRs per year so every is contacted every three years so
we can keep maintaining this data.
And the second point is to make it easy for LIRs to manage their IPv6
address space to make it easy for LIRs to create objects in the RIPE
database and not time consuming, but my colleague Alex Band will present and
that is one of the mechanisms that we have been working on to make it easy
for LIRs to do so.
SHANE KERR: It sounds like we need to you do a short talk at the next RIPE
meeting. I apologise, we do have to close ??
AUDIENCE SPEAKER: A small one. Manuel from Romania. We are operating the
largest residential network in Romania and also we are number 3 in the
Hungarian market. At World IPv6 Day we had almost the highest adoption rate
with IPv6 in Romania but we couldn't start it up in Hungary and guess what
the reason was? The reason was the Hungarian authorities didn't authorise
lawful intercept with IPv6.
SHANE KERR: Did not authorise it?
AUDIENCE SPEAKER: That's right. They are still working on it, we cannot
start it up tomorrow, even we have the same provisioning system, the same B
NGs, everything.
JANOS ZSAKO: That is interesting. I was not aware of that.
SHANE KERR: Thank you very much. I think this is a very interesting talk.
Thank you.
(Applause)
So, our next talk is by Helge Holz, and I am glad we didn't have this talk
first in the morning, it's a little bit of math, geometry and colouring, it
should be interesting.
HELGE HOLZ: I will be talking about visualisation of structured IPv6
addressing and I called the presentation painting by numbers because what I
am doing is I am just colouring squares instead of calculating numbers.
I will start why I had to invent this. So ?? I am working for data port
which is governmental owned by the host countries that you have ?? ? you can
see there on that slide. You can think that I work for a local government
in Schleswig?Holstein, that is north State in Germany just near to Denmark.
In 1994, I was responsible for the IPv4 addressing of the whole State but
from the RIPE I only got class C network so I spread the 10 /8 over the
whole State and lived happily ten years until 2004 when we merged with
Hamburg, who had the same idea. They pulled me up and said you are
responsible for that mess, fix it.
Two years later, we merged with Mechelbeng and with Bremen and with three
months ago we merged with ?? always the same problems. So, you can imagine
what I am doing for the last years. And why I wanted to switch to IPv6.
So I was very glad when in the end of 2009, the Germany, the Ministry of
Interior, received 26 block for IPv6 for governmental use. In 2010, they
created an IPv6 Working Group and I was called to it because I was
responsible for the IP addressing in the two States of Schelswig?Holstein
and Hamburg.
The first thing we did was to give every State a /32. That required a
structured address template because the 6 group if a State gets such a large
number of addresses that as many networks as there are IP addresses in the
Internet, the routing tables would explode because you don't give this /32
to networking people but to important people, and they don't know anything
addressing.
When I said that, I I want the task to do an example so I had to do the IPv6
addressing of Schelswig?Holstein and it should be the blueprint for or used
as a template for the other States. I did that but I was not thinking about
that. I can explain it, not to networking people but to important people.
If you talk to important people you can't do anything like this. That is
normally structured, one?dimensional painting of structured IPv6 addressing.
You just can't do it so I thought just draw a picture. I always draw a
picture when I am explaining what is a network specialist, so I draw some
clouds and some lines and some arrows and then I ?? they do understand what
I am doing. So I think ?? I thought, could I draw a picture about
structured IP v6 addressing. A two dimensional picture, not just a
one?dimensional tree.
So what would be inside such picture: IP addresses, OK. And the structure
means aggregatable IP addresses. What are they? They are IP addresses
where the first lead in bits are all the same. Now draw the picture. What
are IP addresses? IP addresses are numbers, 128 bit numbers. But they are
discrete. So how can you build a two dimensional picture? The only thing I
thought of was a square. Put all these numbers in the square and how can we
see the aggregatable addresses? Sub squares. So I wanted to create a
square with all sub squares have only those numbers with the same leading
bits. That is ?? where is the flaw in this discussion? There are much too
many IP addresses, if I put one pixel for each and draw the picture, nobody
can see the picture.
So I am a mathematician, I am not squared about large numbers, I reduce the
problem, they reduce until the problem vanishes.
So just start with the most simple picture, just don't do 180 bit but start
with less. So let's start to paint a picture, a square containing numbers
with the bit lengths of zero. Done. One bit, OK, that won't be a square,
it's arrow and one, so two bits. That is not quite difficult, there are 24
possibilities to do that but that is one of them. There are only 8 I would
choose because you should be sure that the 00 is directly opposite the 11.
OK, that was not difficult.
Next square. I am going to four bits. Now, comes the trick. I want to be
the sub squares containing the same leading bits, so I quadrupled that, the
square, you see it on the right side, and now I put just the connecting bits
from this white square and that white square from that red square and that
red square and so on. Now, you have a square here of four bits and all sub
squares are containing only the four bit binaries with the same leading
bits. That is what I wanted to achieve and since I am a mathematician, I am
done, it's already done.
But you wouldn't recognise addresses, so we have to go to one more slide and
then we are finished.
OK. You have to do the same again. I put there the 16 tiered matrix and
there I should have done 16 squares but it would be too large so I only ??
no, the squares would go too large so I changed tracks because four digit
binaries are one digit ?? it's all the same, even in these squares, the
leading bits are the same and this square and in this square.
So, now I do the iteration ?? I didn't do 16 squares of that, just one
sample. So, I do every 8 in this blue square, when you mention the other
squares and the result is that the propending bits are all the same. So you
get this. What do you see? You see nothing? But it's a magic square. I
will make you see that you can see aggregatable IPv6 addresses inside that
just by doing colour into that squares.
What I want you to see is matrix where you can see the dividing the 2001 ??
sorry, the 20010 dB 8 /32 to any possible sub squares of addresses because
they are inside that square. I have just coloured them. It's the same
square as before but I put some colours in that. So if you think of this
square as the whole numbers of addresses I do have, then you have a sub
square, you have this, a quarter of them there with the blue square, and
what is more, in the left upper square there is a network number.
For those who don't see it and somebody will hate me for that, I translate
that to decimal, because I think most of you have seen much more IPv4
addresses than IPv6 addresses and now you would recognise the special
numbers here, 192 and directly opposite the 255. You can pick any square,
69 at the network address, at 111, at the broadcast address. They are all
there.
What does happen in addressing? Take it you have /32 and you have to split
it up, since this is an H bit matrix you just do colouring squares and say
this quarter is for the police, they love blue; and don't laugh, it was when
I presented first this at the theoretical method they understood it, they
saw the blue square and said we take this blue square. It took me one year
to dissuade them from that square because they took a quarter of my peer
addresses, only because of the blue square.
So, it helps, but sometimes it doesn't help. So you shouldn't do ?? show
this square to the police.
That is, somehow, the theoretical thing, but we have split address range
from /32 /40 but we have to go on to /48. We can do another iteration, I
have done it by computer and not by hand because now I would have to
multiply this by 256, I printed it out and I worked with my address concept,
but that is not really scaling. But is it necessary? No, you can just to
pick one of any of these/ ?? of these sub squares, which is presenting a
/40, put it after your /32, name it the Net dot path, wipe the whole square
/ and say now you are subscribing the rest and doing it from 40 to 48. It's
/ quite easy. So I wanted to show a picture of a three dimensional picture
/ of sub squares and the best I found in the Internet was that one. So, if
/ you think that the upper square is /32, then the /40, OK, it should be 256
/ times the site lengths but something like that.
OK. That is done for the theoretical time. Now I want to implement a
practical path but since I was not allowed to use my own notebook, the
programme was not ready and the old one is only running on Microsoft, I am a
?? I have little screenshots to show you how you should programme a
programme which you can use to make address concepts.
So, that is roughly the German government where ?? which I wanted to break
down to IP addresses. So I started with is blank square, not surprising,
and here, you have got the IP address I got. I named ?? I am starting to
dividing it to sub spaces. Very easy. I marked that square, click on plus,
then I have to name it, it's for the police, not surprising, in blue, and
the Net mass is calculated automatically I click on on OK" it's done. The
next one on a subset, this is for rural municipalities, mark it green and
the Net mass is calculated. So now, I have the rulers. One is big
/STKPWHRA*BG, I mark it. You see it, I mark it in brown. Click on "OK" and
/ I am ready. They are missing a screen shot but it doesn't matter.
Now, I want to subdivide this 42 and other squares with larger net masks so
I double click on that 42 and here down there you see that I am now dividing
the sub square 2001 DB 8, 40 ?? and I am dividing the municipality. When I
am marking the wrong square because that is not a square, the programme
wouldn't do it, so if I do try it, I just mark it, put it in, and that is
finished. Then for the municipalities I do something more ?? I take this
square and that is maybe the village of /SRA*RPBLG State, then I do sub
square, and the ruling municipalities in the national State in Germany. And
you are very fast, it's very structured, and you can fail. And if you give
this to someone who is not very accustomed to routing and really structured
IP addressing, it's very easy; he can't fail. And that is why we invented
it, the IPv6 Working Group, to make people do better IP address concepts.
OK. I will skip the last slide and I am finished.
(Applause)
AUDIENCE SPEAKER: Thank you it's brilliant. A comment. I hope nobody from
your important people were coloured blind, yeah? (Jen Linkova) but yes the
question is the software available so can we delegate to child care in
primary school.
HELGE HOLZ: It's not very stable, but my collator wrote it at home so he
has a small database, maybe he wrote it at night between 2:00 and 3:00 so
it's not very stable but you can write to me and I can write to him, I think
you can get this, yes.
JEN LINKOVA: I think you should make it public or web service or something
like that so people could ??
HELGE HOLZ: That is why I am here, because it's widespread, it's quite old,
three years' old and nobody wanted to hear it and so I think I could publish
it here.
MARCO HOGEWONING: I will take Geoff and then I will close the queue as we
are ?? well Niall, then.
GEOFF HUSTON: What if all the libraries wanted to connect separately from
all the schools?
HELGE HOLZ: In Germany that won't be that way.
NIALL O'REILLY: You have explained to me the bug in the mapping system, I
have been using for IPv4 forever so long. This has properties that I needed
and couldn't work out how to do. Congratulations.
MARCO HOGEWONING: Thank you, Helge, wonderful presentation. Sorry about
rushing you a bit, as people are noticing we are a bit time constrained so
we are going to swap a bit of the agenda, Alex Band has agreed to to move
his presentation to the second slot which leaves us with about seven minutes
left for Andrei to give us a brief overview in changes of Knot DNS.
ONDREJ SURY: Sorry for the intrusion to IPv6 Working Group. I just wanted
to show you a few slides for an OpenSource Working Group if you want to see
whole presentation, and so, we have something in development called dynamic
modules and you can synthesize resource records with that and it's for IPv6
IPv4, because we were approached by some ISP that they have the problems if
mail bouncing because there is no reverse addresses and it's not possible to
generate all the IPv6 reverse records into the memory, so the customers are
complaining so we have developed something we called synthesized resource
records, the configuration is simple, you just tell it's forward reverse,
which prefix you want to use, which is just some strange, to T L and address
that will generate for. There is no DNSSEC signing yet but it will come
this year. So this is the example configuration. For example, example.org
you can generate both IPv6 and IPv4 forward records here, and here this is
the IPv4 reverse record which is ?? generate the PTR and here is the same
for IPv6.
So if you are running IPv6 networks, this might be interest of you. And
here is example output, how does this look into the ?? if you ask for it.
This is the prefix, here are the TTL somewhere which has been cut because
it's ?? yeah, here is the TTL and the domain name is somehow generated
according to pattern. It also supports the static records so if you have
some, well, IPv6 resource records you can, this will just hit only if the
domain name is not found in the zone file. So that is it. I won't stop you
from break any more. Thanks for letting me in in so quickly time notice.
SHANE KERR: Any questions or suggestions about that?
WILFRIED WOEBER: Just a little question because I am not a DNS specialist.
Have you just been saying that if you have a particular entry for the 4 bit
zone, that you cannot automatically give the answer if queried for the
reverse?
ONDREJ SURY: No, it doesn't ?? it doesn't match the zones together it's
just you create a pattern that will generate on the fly, well if somebody
asks for the name.
SHANE KERR: OK, thank you. We have an AOB apparently
AUDIENCE SPEAKER: I got a question, I believe it was just after ??
January?ish Tim Roy has anybody left looked into L5 ?? this might be a good
work around for the mail service until further investigations are done
surrounding the issue.
SHANE KERR: I think it's too warm for the people to parse that properly.
Great, well this brings us to the end of the first session. We have another
session completely after the coffee break. Don't come back here, we are
going to the main room, unless for some weird reason you want to go to
cooperation. But v6 will be in the main room and we will see you in a half
hour.
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
