Transcript - IPv6 Plenary 1

http://conference.apnic.net/34/program/ipv6-plenary

DISCLAIMER: Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC and Media Scriptz accepts no liability for any event or action resulting from the transcripts.

Vu The Binh: Good afternoon, everyone. We should start the afternoon session. My name is Binh, I'm from Viet Nam, I'm managing an ISP in Viet Nam to do something related to IPv6. It is my pleasure today to join the three experts, famous speakers with you, in this IPv6 addressing planning session.

This session, as you know, is a practical session and it is a very important topic, addressing planning for an operational network with IPv6.

As reported by APNIC Secretariat, this kind of questioning about addressing is the most asked question for them.

We all know that IPv6 is long, 128 bits, compared with 32 bits in IPv4, and we can see that the number of IPv6 is really huge, and we should consider if it is more difficult or easier than IPv4 for making addressing.

Whenever we have the addressing plan, a good plan, we can have many things easier, such as managing security, tracing the address or making scalable things or efficient network management.

We also would like to be able to share lessons and experience from the speakers and from all of you, and on behalf of the organizers we request your active participation for this session, so you can have questions and share experiences whenever you think.

Feel free to ask a question any time you like.

We have three experts today: Mr Aftab Siddiqui from Cybernet for Pakistan; Mr Yoshinobu Matsuzaki; and I think you all know Philip Smith.

At the beginning we will have three talks from our speakers. Firstly, Mr Aftab Siddiqui will make some sharing about IPv6 addressing with his work in Cyber Internet Services. He has more than six years in technology and management for service provider and enterprise environments. He has a lot of expertise in implementing, designing, for service providers and enterprise networks, including MPRS, IPv6, QS, FTTH, Wimax, routing, protocol security, NMS, et cetera, so a lot of expertise and experience.

Let's welcome Aftab.

Aftab Siddiqui: Thank you for inviting me. I have been

coming to many APNIC and APRICOT meetings and representing IPv6 Task Force for Pakistan and this is the first time I am presenting Cybernet, because it is something technical to discuss rather than a policy matter and how things are going on in Pakistan in terms of IPv6, which we will do in another session.

I am Aftab Siddiqui, I represent Cybernet and we have been doing IPv6 for quite some time, at least five years now. Again, till date, we don't have any commercial customers, everybody is just evaluating it.

So let's do it.

To start with, this is the introduction and these are the introductory questions I get all the time.

People ask me, it's a huge space, how to do it, how to deal with it, how to subnet and how to make it future proof, it is difficult to subnet, it adds up to a lot of operational costs and I don't have to teach subnetting in HEX, it is difficult for them to understand, I don't know why.

One question I always ask people: how do you do it in IPv4? Then just do it in IPv6. There's one question, while checking the blogs, I found out that people say that IPv4 historically was not limited, it was as unlimited as IPv6 today is for us. So let's see how things work out.

In my opinion and in our company's opinion and in many others' opinion it's okay to be wasteful. I hope Owen DeLong is not listening to me, otherwise he'll say, no, don't be wasteful at all. You can see that number, it's a huge number. You'll get that much, 4.3 billion addresses in every allocation, like Cybernet has one /32 and it is enough forever, I believe.

It is okay to be wasteful in terms of assigning IP addresses to the end customers and end sites, it is up to them how to use it.

I just want to quote one thing from Jeff Doyle that I read in a book by him, that being conservative in IPv6 is like spending $200 just to save $2. So don't be conservative at all. Think out of the IPv4 box because we are still dealing with IPv4 and there's no need to be in that mindset at all.

There are certain considerations which we suggest all the time. Don't think in IPv4 terms, as I said, but always plan the way you plan IPv4. Evaluate IPv4 address management, if you had any. Usually, people don't put everything in perspective before making a plan. If you have a plan for IPv4, just plan the way you did it for IPv6 as well.

Do you have any security plan for IPv4? Usually people do, all the time, and the routing plan as well.

Just plan your IPv6 security and routing like that.

There is not much difference. There are some things, which I'll share later on, but there's not much difference between the routing and the security, it's more or less the same.

How do you manage IPv4 address management? How do you give out IP addresses? Where do you record it? If you have been doing it on Excel, don't do it any more.

If you have any in-house development, make sure it supports HEX. There are so many open source IPAM solutions available, so get one of them.

Routing development remains the same, nothing new to it, other than a few syntax, as long as you are not planning to change your IDP from OSPF to ISIS. This is the solution that everybody knows. We get /32 because we are an ISP/LIR, if you are an end site or enterprise you will get most probably a /48, it's up to you how to further subnet it.

For medium and small enterprises, this is our suggestion, we take it from the RIPE document, the RIPE addressing plan. For me, it is not a good idea, but people do use it. I have seen a couple of enterprises in Pakistan who are doing the same thing. What they do is they have 192.168.1.0/24, they use the second last octet and put it in the IPv4 address. It's not scalable

at all, because in IPv4 we don't use 192.168.1.0/24 and then 2.0/24, because we usually use 1.0 sometimes, then 10, then 20, then 40, then 50. So it's up to you how you plan it, but you cannot scale it in IPv6 if you are doing it this way.

What Cybernet has done so far, we have many POPs spread all around the country, three regional headquarters and each headquarters has at least five to six cities and every city has five or six POPs connecting to it, so we have allocated /36 for every regional headquarter, which was enough for any headquarter to manage the IPv6; then /36 for the critical services, /36 for the infrastructure only, and then /64 is reserved for loopback addresses.

We can do it for the infrastructure only as well, but we said we would take one /36 and take one /64 out of it. It's a big task. Don't try to subnet that much, from /36 to /64, it will eat up all the CPU power of your system.

Enterprise assignments. No commercial users so far, but we have a handful of customers using and evaluating, thanks to certain laws from the European Union, which forces all the call centres in our region to be IPv6 compliant by the year end. So almost every call centre is evaluating it.

We initially decided to hand over /48, but then nobody was asking for it, so we said, fine, we will assign /56 and no more /48 any more, we then give /48, so the result is /64 for point-to-point connectivity, but we configure /127 for the point-to-point enterprises. We have not faced any issues so far. BGP is mandatory for all the customers.

Cybernet local network, how we are doing it, it's not Cybernet only, we are part of the group of companies, we have 15 to 25 companies we provide Internet services to. We assign /64 to those which are only looking for Internet, it's SLAAC, it works well for them, they don't need to have the SEP or anything else, they are happy with it and are doing dual stack, with letting the IPv4 part and v6 is going live, so they are happy with it because most of the traffic is hitting the IPv6 because of the Facebook, YouTube and the Google stuff.

Those who are posting some services, like servers and other things, we assign them /56 at times, but usually multiple /64s, so that they do not have to do subnetting on their own, we do it for them.

Then Cybernet LAN is all SLAAC, totally SLAAC.

Again, the LAN part, v4 is native and v6 is going live, without any issues, we don't face any breakage in the

Internet.

Upstream connectivity, we are native for the last two years because one upstream provider is providing native connectivity, the other one is not. We have only two upstream providers in Pakistan, so we are connected to Hurricane Electric as back-up in case of any disaster. We had one during the summer, two months back, the upstream v6 connectivity went down and we went to the Hurricane Electric tunnel.

Of course, it caused a little delay, but v6 works.

We strongly discourage all the customers not to create tunnels. We don't block it, but we discourage them.

It is impossible to do IPv6 management with Excel, as I said before, you need to have an IPAM solution.

There are many IPAM solutions available open source and for certain pricing as well. We use IPplan and PHP IPAM is also available. We were using PHP IP before but it doesn't support IPv6, they have a different version for it, it doesn't work in one place.

The lessons learned so far, IPv4 and IPv6 are two different protocols, this is one thing all engineers should remember. Address planning should be done way before create configuring the first interface on a production router because we end up renumbering it after

two years. We started with the lab and just put the lab in production, so that was not a good case, it was a bad mistake for us. We ended up doing renumbering and it took us six months to do so.

You cannot block ICPMv6, I made it clear to many of our engineers, but somehow they did, it's not a good thing. It breaks. It breaks the IPv6 Internet.

Simple.

IPv6 address also has a, b, c, d, e, f. Engineers tend to forget that. They only assign the numerical addresses, and sometimes it is convenient for them, I don't know why. I made a mistake once and now we have a full capacity of IPAM solutions so we don't make that mistake any more.

In summary, IPv6 address management and planning cannot be generalised. What Cybernet has done has nothing to do with what you are doing in your company.

It can be done in different ways, it can be done with different perspectives, but one thing is clear: you have to do it. Address planning should be done before you are going to a live router. We have tried VLAN ID, we have tried IPv4 3 octet and interface ID. You can put anything you like in the v6 address, like Facebook has FACEB00C, it's good for them but not for us. Cybernet doesn't fall into the category with the way we can use

those characters. You can use anything but it should be easy to understand and easy to remember.

Don't play with link-local addresses. We don't play with it. We tried it in the lab and it was a nightmare to find out what's going on.

Infrastructure protection should be considered beforehand, because ACL and all the security infrastructure we had before, for IPv4, we end up reconsidering it for v6. We had a couple of, you can say, thousands of spam going out on the Internet because we didn't configure it properly for IPv6.

I just want to conclude, do whatever best suits you rather than following any common best practices because there are no common best practices for IPv6 address planning. There are a couple but I believe there are certain flaws in them. You can do it as per your own environment.

The large address space allocation will make you future proof. Design your network accordingly. If you have a /32 or /48, don't waste it illogically, you can waste it logically. It's fine to subnet at nibble boundaries, with 4 bits it's okay, /36 is fine, /40 is fine as well. We are doing it and it's fine.

Learn to subnet in HEX, hexadecimal as well, it will help you understand how IPv6 works. These are all the

considerations we believe Cybernet has learned in the past three or four years, after renumbering it. So I thought it would be useful for all of us. Thank you from my side. Any questions? I guess it was very self-explanatory. Thank you.

APPLAUSE

Vu The Binh: Thank you, Aftab, for the quick presentation.

I would like to ask if the presentation is okay, I mean in speed, or does it need to be slower or faster? Any comments?

Tachibana: The speed is real good, real good, I think.

Vu The Binh: So that's okay.

Bertrand Cherrier: Can we get the slides?

Vu The Binh: The slide will be on the website for the IPv6 plenary session.

We have a long session, this session will be 90 minutes, so we would like to have your active participation, and I think this presentation really focuses on engineers, so I would like to check how many engineers we have in this room. Who are the engineers and dealing with addressing? Please raise your hands.

We have about one third -- a lot.

Before getting other questions, I have some questions to Aftab. The first question is, learning

hexadecimal is easy or difficult? You said something about hexadecimal.

Aftab Siddiqui: Is Champika around? He has been teaching hexadecimal since at APNIC. It is easy for anybody who is doing it on a daily basis. I use IPv6 calculator all the time so I'm one of the culprits. It's not difficult, it's easy, as long as you are doing it on a day-to-day basis. We don't subnet IPv4 on a day-to-day basis. If I ask you how many hosts, how many subnets, it's difficult, it's more like a theoretical thing, but hexadecimal, you have to learn it once so you get familiar with what hexadecimal is.

In my experience, I end up doing a whiteboard thing in an enterprise, in a multinational, just to explain how a /64 works. So my point is, just learn how hexadecimal works. That's it.

Vu The Binh: We have a new subject to learn, hexadecimal.

For me, remember 0 and 1 is easier, decimal is easier, but hexadecimal for me is not really an easy task. I can't remember my address in the PC IPv6 in my office, but for IPv4 I can remember it. Especially for DNS. Very important.

Any questions from you? Before getting to the second presentation, Aftab, could you share something related to comparison between

addressing with IPv4 compared with IPv6? Because, as we know, IPv4, we have the internal address in case of lacking of public IPv4 address, so 192.168-something, but IPv6 we don't have that.

Aftab Siddiqui: No, we only have the global unicast addresses, GUA, as people usually call it, and addressing is not as difficult as anything else, it is only the perception. IPv4 and IPv6 addressing is more or less similar, as long as you understand you have to waste a million IPs per site. It's okay, you can waste that much.

As I said, there are certain people, certain groups, who seriously are against it, not to waste IPs at all.

But for us, we believe we cannot expend that much that we will end up using the /32 by any means, and even if we waste that much amount, I guess APNIC has enough space to get from -- right? I don't know. This is what I believe. It's okay to be wasteful in terms of IP addresses, and there's not much difference.

You just have to understand that once you are on the PC, once you are on a router, IP works the same, more or less. There's not much difference. It's only the syntax what you see and what you understand from it.

It's almost the same thing. It's only a difference in perception.

As long as we try to make it difficult for us and for everybody else, it will remain a difficulty. That's my take.

Vu The Binh: In some cases we can say that addressing planning for v6 is a little bit easier, somehow.

Aftab Siddiqui: Because we have ample time to do it. In IPv4 when I graduated, half of the IPv4 address space was gone. So you have time to do it, so it's easier than IPv4.

Vu The Binh: It is good if we have dollars as much as the IPv6 number, money? (Laughter). Just kidding.

If there are no questions, we hope to have more questions during the discussion part, after the three presentations.

Let me introduce the second speaker, Mr Yoshinobu Matsuzaki, from IIJ. He will do the second presentation. He's a senior engineer at Internet Initiative Japan, IIJ, and the AS number is 2497, a pioneer commercial ISP in Japan, so he must have a lot of experience. He has more than a decade of network operation experience. He still looks young, but has more than a decade of experience. With IIJ background network team, he has experience in many things, including network design, operation, network security, DNS, and he has made a lot of presentations at JANOG,

NANOG, RIPE and APNIC meetings, and a lot of others.

Let's welcome Mr Mazu.

Yoshinobu Matsuzaki: Let's get started. People call me Maz, working for IIJ. This time I will share about our case on addressing planning.

I think there is uncertainty in IPv6 address planning. It is a little bit different from IPv4 because we have 128 bits in IPv6, a little bit longer than IPv4. Also, there is another concern, not another, we have a linklocal in IPv4, but in IPv6 we use it more aggressively.

There could be concerns about internal routing because probably you can have a thousand or millions of internal routes on IPv6, theoretically, and also we always assume there could be a smarter way to manage IP addressing.

I will show the IIJ case. We are mostly focused on enterprise, the big enterprise, including government, academics and big enterprise companies as well. We have about 6,000 or 7,000 customers. Also, we are providing consumer services. We have about half a million consumers using FTTH, ADSL access networks.

This is the prefix length we are using -- of course, /127 for loopbacks and /64 for links. As usual, we assign /48 for enterprise customers. Before, we

assigned /48 for consumers as well, but then we changed our mind and now we are assigning /56 for consumers, because /48 is a little bit bigger -- too big for consumers. You don't have a 60K segment at home, no.

Probably /56 is enough for home users.

Then we have a mobile service, and these days people are using 3G for 4G device to connect to the Internet, and then we assign /64 for these users.

Talking about the global unicast address, an inter-router link inside AS does not require global address, because we are using OSPFv3 for the link-local address, so you do not need a global address. Only the loopback interface needs a global address to configure iBGP sessions, but we configure global address on every interface in our network, because we check availability by ping, so we need a ping destination for iBPG. That's why we configure global address interfaces.

There was a discussion about the linklocal. As far as I know, there's one operator who configures the link-local address by hand, manually. But we don't.

Most routers use a modified EUI-64 format address, so we just use it. We don't want to waste our time with that.

There are a bunch of other addresses for vrrp/hsrp, another story.

Our customers might configure a static route on

their device, so the address should be something easy to configure. So in our office network we use fe80::1 as an address, to the default router. That's easier for us.

Route aggregation. We are not so aggressive inside AS. We are doing a similar thing to the IPv4 case.

Actually, we do aggregate where it's easily possible, like consumer service, we have an aggregation router then we can aggregate routers there, so we do aggregate there. But for enterprise customers we don't, so just announce /48 to the BGP.

BGP can handle many prefixes. For IPv4 we have 400,000 now. It's working pretty well.

For IPv4 and IPv6, BGP carries most prefixes, including customers, and IGP is just for topology and minimum routes, like on loopbacks and BGP net talks, something like that.

Of course aggregation is important, so we announce aggregated prefixes only to other ASs. So if there's someone who is de-aggregating announcement, please filter it and please aggregate.

We thought about the infrastructure protection. We might deploy access control or policing to protect our infrastructure, I mean routers. So we thought it's better to reserve a block based on this kind of purpose,

to simplify rules. So we decided to reserve a block for inter-router links inside AS and also loopbacks.

There could be other purpose, like inter-router links with other parties, like customers, like peering partners. This is a little bit different categories, because we need to communicate with other parties' devices, it could be a BGP router or a static router, but there could be a ping destination or a BGP TCP communication. So this is a little bit different category. Also, users and the server segment should be globally reachable.

Now, this is our reserving policy. We use /40 to reserve a block. Actually, first block was fully used.

This is a full example, not an actual case, but very similar. At that time, we assigned everything from this first block, so we assigned address for customers, for our infrastructure, for our servers, from the first /40 block, and then we revised our policy. So we reserved /40 for our infrastructure, then the number of routers, and then when we started the commercial service for consumers and enterprise then we reserved /40 for them.

Management. Actually, we use plain text to reserve /40, by hand. It's easy.

Then, for infrastructure, we reserve /56 blocks based on purpose. We actually reserved /56 for each

POPs, to be used on inter-router links inside the POP.

Also, we developed an in-house tool to help our assignment, to use for new allocations and also returning, in case of cancelled service.

As we have configured the tunnel service that is bound to IPv4 connectivity, so if the IPv4 connectivity service is cancelled somehow then we need to return the related IPv6 address as well. So that's why we need an in-house tool.

This is a little bit different ISP point of view, this is kind of an enterprise point of view, talking about the IIJ office network. As an enterprise, we got /48, then we split it into two /49s. It's an outside and inside with a firewall. I think this could be wrong, as we don't need that much outside, because it's an office network, so we have much more segments inside the firewall, but so far the /49 is still enough for our needs. But probably we need to reconsider this in the future some time.

From /49 we reserved /56 based on purpose, a segment for servers or a segment for clients or a segment for testing, something like that, and then actually assign /64 to be used on each link.

For our lessons learned, we can estimate, we actually can estimate needs based on IPv4 experience.

We have a number of customers, links and number of servers and we can know about the use or trend and then we can estimate how much we need address block for that.

You need your reservation boundary. As an enterprise, we use /56, and as an ISP we use /40. Then break it into /56, if needed.

Lesson number 2 is HEX. At the moment we assign addresses by hand manually, so sometimes we notice it.

Someone put a 10 next to the 9, so we forget about the a, b, c, d, e, f. This is also the reason we need a tool to help your assignment, not use this kind of a, b, c, d, e, f HEXing things.

In summary, we don't care about internal routing much. BGP can handle many prefixes well in our case.

We did care about infrastructure blocks, to put security stuff, and we care about the human friendly boundary -- /40, /48, /56 and /64. This size just fits our needs as an ISP, so we are happy using this human eyeball friendly boundary now.

That's all.

Vu The Binh: Thanks, Mr Maz. Any questions yet?

Philip Smith: This is meant to be a bit more of an informal setting here, rather than sitting behind a big table.

My question is: /64 and mobile users, what happens

when the mobile user has a 3G dongle that plugs into a computer that is providing a local area network for the office? This question was asked at the VNNIC IPv6 Conference at the end of May, which you might remember, the exact same question came up there. For a mobile user, /64 is fine, but what happens when they are using the computer with the dongle to provide routing access to the rest of the network? Or do you have that issue in Japan?

Yoshinobu Matsuzaki: So far we don't have such case that the 3G dongle provides an office connectivity, because in Japan we have a strict company policy that you need the firewall security stuff to be connected to the Internet. Then employees need the network separately.

Probably you are not allowed to connect the office network and the Internet at the same time.

Philip Smith: I am just thinking in the case of where somebody doesn't have, say, broadband to the house but instead uses 3G to connect up all the subnets in their house. I am wondering about that. That's all. It was just a curious, interesting, innocent question.

Dean Pemberton (InternetNZ): Just going on from what Philip was saying about the 3G dongle with the computer and the network, we see that sort of 3G dongle deployed as a back-up link, so maybe they have a fixed line

primary, where you have the right amount of subnets down there, but they could also be using that 3G connectivity in case something goes wrong with that one.

It's not always the case that everything 3G is just connected to one device. Certainly we are seeing it being used to offer an alternative way, and certainly in countries like India where you have this massive, huge amount more mobiles than fixed line, I think you will find that the concept of 3G just being one device won't hold forever.

Vu The Binh: Thank you. Any other questions?

Cyrille Jerabek: Good afternoon. I'm Cyrille from New Caledonia.

A question for Maz. Can you tell us a little more about the tool you use to manage all your IPplan?

Yoshinobu Matsuzaki: I can't share this because it is a totally internal system dedicated for our management purpose, so I'm not sure I can share. I will contact you later in person.

Aftab Siddiqui: I can comment on that. As I said, we are using IPplan, it's an open source management tool, and you can use PHP IPAM, as both are open source. We have tried both of them, we believe IPplan is better than that. We use only for IPv6, not for IPv4. For IPv4 we have PHP IP, which has been there for seven or eight

years and works really fine. It's open source, you can use that.

As far as Maz is using, they are using in-house developed, so it must be much better than what we are using, hopefully.

Andy Linton: Andy Linton from Citylink in Wellington.

Someone asked about the tool to manage this. We use a tool called NetDot, which comes from the University of Oregon, which is a documentation tool for the network which does a whole bunch of things, but one thing it does is both IPv4 and IPv6 address plan management and will generate stuff and stick it into the DNS for you and a whole bunch of other things.

In the workshop we did in Cambodia last week for the campus network development as part of the precursor to this, that is one of the tools we were showing people as a way to manage this stuff. That is freely available, and you can download it and get on with it.

Vu The Binh: Did you want to add something more?

Yoshinobu Matsuzaki: No.

Vu The Binh: We will move to the third presentation, from Dr Philip Smith, from Learning and Development Centre of APNIC. Philip now is the Learning and Development Director of APNIC. Previously he was working for Cisco, since a long time ago, 1998, and he was also part of the

infrastructure group in the CTO Consulting Engineering.

He spent five years at IPEX, now is the global Internet ISP, and the first commercial ISP in the UK, and he was one of the first engineers working in the commercial Internet in the UK, and played a very key role in building the model Internet in Europe. So we have Philip here for a very interesting presentation.

Philip Smith: I hope it's interesting. Thank you very much.

This is really just going to kind of carry on from what Aftab and Maz were talking about, filling in one or two more gaps.

This is not really my manifest about how to do IPv6 address planning. It is really based on my experiences in the last six or seven years, helping service providers deploy v6, what are the discussions and debates we have had about how to do v6 address plan for the network infrastructure.

When I look at what I wrote -- the first draft of this presentation, when I first put it together six or seven years ago, it's changed quite a bit for these days.

With the v6 address planning, of course you need to remember that the v6 address space that you will get as a network operator -- I'm not saying just Internet

service provider, I do mean network operator -- is going to be very large compared with IPv4. So it's pretty important to design a scalable plan.

In v4 we were always chopping and using tiny little scraps to try to make the network be addressed properly, but in v6 we can sit down and design something that will scale pretty well.

Another one -- I think it is pretty important to be aware of industry current practices. Notice I didn't put in "best practices", because even those change all the time. In the last three or four years, the current practices have changed quite a bit. I look at some of the first providers I helped deploy, what they did and what we do now, there's a little bit of difference, just as we have got more used to, more people have experiences to share in fora like this.

The other thing we find is really important is to separate infrastructure from what you give to your customers. In v4, again, we were trying to grab bits and pieces and make it all work, but v6, we need to have a very clear delineation between infrastructure and what we give to the customers.

Also trying to distribute address space according to the actual functions, what it is going to be used for, which is kind of what Maz alluded to in his presentation

about IIJ.

Why do we create one? V4 was severely limited.

I know people who can probably remember their v4 address plan, just because, again, we had a limited amount of space and what they were giving and what they were using was pretty easily memorable. V6, because of the huge range we have, we can do an awful lot more. We can actually put in security policies that are easier to implement.

Yesterday I was looking at an access list for some providers, the v4 access list is as long as my arm, the v6 access list can have two lines. It's that kind of difference, because we can design a scalable addressing plan.

Addresses become easier to trace. You know what certain addresses look like. If they are going to be used for POP number 3 they come out of a certain address block used for that particular point of presence. It also lets us do much more efficient network management as well, in all senses of the network management term.

Aftab mentioned nibble boundaries. I'll explain those, for those who don't know what they are. The nibble boundary basically means subdividing an address space based on the actual numbering. Every number in IPv6 represents four bits. Before, in v4 we did

subnetting to try to maximise the use of each subnet, whereas in v6 subnetting based on nibble boundaries makes things a lot easier for managing the address space or the planning within your actual network.

We can do a lot of addressing based on these 4-bit boundaries, so the boundaries of each number in the actual address.

I have an example here. If you look at the address block, this is a /61 as an example. In v4, doing this type of thing was fairly common but in IPv6 you can look at the /61, it makes it awkward because /61, that part highlighted in red, 0010 to 0017, that's fine, that's the subnet, that's the 61, but the adjacent 61 runs from 0018 to 001f. So you are confining yourself more than you necessarily need to.

Why not just use a /60, then you get the entire range here. So these blocks don't use the entire nibble range, whereas if we use the /60, as I point out on this slide, then you have got the whole range of addresses and it's easier for you to document and implement on the routers and so forth. So this makes the numbering plan much easier.

Addressing plans for infrastructure. Operators will get a /32 from the registry, that's how the process works. As the other two speakers suggested, try to

segment the address space according to what it is being used for. A /48 for your infrastructure makes good sense. A /48 gives you 65,000 subnets in the backbone.

Out of that, you pool out an address block for all the loopbacks on the router. Each router has one loopback, needs one address, a single /28. A /64 gives you whatever the big number was, but it's more routers than you will ever have so there's no scalability problem in doing that.

Point-to-point links -- when we started off many years ago, point-to-point links were /64s. Pretty much these days folks are addressing those as /127s, but reserving the /64 that it comes out of. There's an RFC that Maz mentioned that covers that.

LAN, /64 for a LAN is the standard. Looking at some of the detail, generally the original intention was always that customers get one /48. But most providers I'm seeing say, "Hm, /48?" As Maz said, 65,000 subnets is an awful lot to give to a small user.

I've seen providers do all kinds of things. /64 for one LAN. I've seen some people even give a /60 for what they call a small network. Given this is meant to be a brave new world, I think this is probably overly stingy.

/56 for medium size, /48 for a large network. I have listed the subnet sizes there so you can get some

understanding of how big these are.

As I said, most providers are using /56 as the default delegation to a customer, and it's only when they get to the really big ones that /48s are being distributed.

As I note there, it's still a very active discussion area. I'm not presenting this as, "This is what you should do." I'm presenting this as, "Well, this is what I've seen over the last three or four years." This will evolve, I'm sure. This is part of the reason for sessions like this, where we can have a bit of conversation about whether these operationally make sense, never mind the political part, whether operationally some of this makes sense.

I prefer simple things and I think giving /48 to customers from the word go is probably the best plan, but that's my opinion.

Documentation. As I said earlier, v4 addresses are probably easy enough to memorise. I certainly memorized all the v4 addresses in the UK Internet at UUnet. IPv6 addresses, no way. Even if you come up with an efficient scalable plan with hints of what each block might be used for, no. Maybe I'm getting too old to memorise things but I think trying to memorise a v6 address plan is too hard. Do the documentation. As the

other two said, it's absolutely vital, especially when it comes to populating the DNS, setting up the DNS in v6, especially the reverse DNS, is a little bit more challenge than it was in IPv4.

Examples of addressing tools. Others mentioned tools; these are a lot of the common ones. NetDot, I really recommend that. It's a network documentation tool, as Andy Linton mentioned, but it handles v4 and v6 addressing, builds your DNS for you and so forth. HaCi I have seen people use; that one seems pretty nice, too.

IPat I don't know anything about; Freeipdb; Aftab mentioned the PHP IP and IPplan. The two IPv6 subnet calculators, if you can't do those, I'm sure there are others out there as well. These are examples, I'm sure there are more.

That should answer the question: how do I manage it? Don't use Excel, it's too difficult. I still see people using text files. That works.

A deployable address plan. I have always tried to pick the first /48 for the infrastructure simply because it keeps the numbers short. I have done a load of workshops in my years at Cisco and a lot of the workshops have been introducing folks to IPv6. Even though people can do all the routing and everything else, fine, the biggest issue I always had with the

workshops is the start, when we deploy the IPv6 addressing. It's amazing how zeros can be missed out and colons missed out or added to. I found keeping the v6 addresses really short for the service provider infrastructure stops errors or reduces the amount of errors later on. Pick the first /48 for the infrastructure because then the router addresses are really short, as I give in the example there.

Out of this first /48 for infrastructure, pick the first /64 for loopbacks, again, to keep the numbers short.

Pick the second /48 for point-to-point links to customers. The customer is not part of the infrastructure, the point-to-point link addresses going to the customers is not a trusted part of the infrastructure so they don't fit inside the security cordon. If a /48 doesn't make sense, I see a lot of providers setting aside one /48 per point of presence, the regional networks probably go even bigger than this, it just depends completely on the size of the infrastructure, whether we are dealing with a small provider or a multinational. One size is not going to fit all here, so try to think of something that will be scalable as well as reasonably logical. I have given one example here.

Some folks use unnumbered interfaces in v4, they can carry on doing that in v6, using unnumbered interfaces as well. A lot of folks prefer to use numbered interfaces for link monitoring and testing and so forth.

For infrastructure /48, first /64 for loopbacks, maybe reserve the final /60 for the network operation centre, again because it's part of the trusted core network. Some people don't do this, some people do this. Again, there is not a right or a wrong but it tries to keep the core infrastructure out of the same /48 address block, really to manage the security, to keep the security as straightforward as possible.

I have given you some examples here. For example, 2001:db8:0::/48 is used for infrastructure, we take 2001:db8:0::/64 for loopbacks. Suppose the operator has 20 POPs, we can pick a scheme like 2001:db8::XXYY/128 for the loopbacks, where X is the POP number, it gives us 255 POPs, so it will be way bigger than what we have at the moment. Likewise the router number, are we going to have 255 routers in the point of presence? Probably not. That at least lets you scale up to a fairly sizeable network and keeps the loopback addresses on the routers nice and short, so it looks like this.

There you have the beginnings of a recognisable address scheme. When you see a router with an address

2001:db8::A10, you know it's point of presence number 10 and 10 or 1-0 is my access route to number 1, and you start having a recognisable, memorable address scheme which you can replicate through all points of presence, so when operational staff are in the POP looking at routers they know exactly what the router is based on its address.

We couldn't do this in IPv4. We could back in the early 1990s, we could do this type of planning, pick a /8 that wasn't being used and so on. But v6, we are back to the possibilities of using the addresses to identify where we are within the infrastructure.

Point-to-point links. Again, we work with the 20 POPs idea, so here we adopt the 2001:db8:0, then the XXYY construct for the /64s. Again, POP number 01 through to 255 is the LAN number, so we can split whether it's a broadcast media or a point-to-point link.

Sometimes that's useful, again for the purpose of filtering, so we can come up with that scheme and recognise what the link is based on the actual address.

Then Z is the interface address, it could be 0, 1, 2, 3, 4, 5 or whatever you wish but we are numbering it as a /127, we can use something that will be recognisable.

This example is what it could look like. You see

the address, you see the subnet, recognise its use and which part of the network it comes from.

Links to customers. As I said, some operators use unnumbered IPv4 interface links, so we can replicate with v6. If I think about it, way back when we started with v6 at UUnet UK in 1996, we were using v4 unnumbered for a lot of our customer links, so the first folks who wanted to play with v6, we used unnumbered v6. It was 1996 or 1997. We replicated that. Other folks who do the same thing might want to do this too. It saves a /48, but honestly, we've got such an amount of address space in comparison with what we had in v4. Do we want to do this, where the alternative is to number the point-to-point links? It makes it easier to do link testing, monitoring, managing and so forth. Again, up to you.

Other operators are using global unicast addresses, so we can set aside a second /48 for this purpose and divide it amongst the POPs or set aside a single /48 per POP, it just depends on the size. If you have a large point of presence, a huge number of customers, you probably need one per POP.

Again, an example scheme might be 2001:db8:00XX where XX is the POP number, which is good for 255 points of presence with 65,000 point-to-point links to

customers, which would be more than enough for most providers.

It could look something like this and you can identify the point-to-point link based on which the point of presence is sitting at.

The allocation documentation could look like this, listing out the /48s and delegate out of the /48s the individual bits and pieces. I am listing possibilities here. We might have the first 256 /48s being used for infrastructure and point-to-point links to customers, then the rest of them, all 65,000 of them, could be delegated for customers' own use in the infrastructure.

The summary of all that: use the first /48 for the infrastructure, so it is literally the backbone point-to-point links. Out of that, take the first /64 for loopbacks. This is a scheme I have used for workshops for many years. The folks there seem to understand it pretty easily and it works pretty well.

So it seems a pretty reasonable thing to do.

Define the structure that you are going to use within your v6 addressing, then it becomes recognisable where the subnet is being used. We have much greater flexibility than we had with v4. You could always come up with a scheme that is almost memorable. That's the thing I find a little bit scary, because I remember some

of the addressing schemes for the ISPs I have been helping in v6, which I never expected I would be able to do, given the size of the address space.

The final thing is documentation is vitally important. You could get away with not having much in v4, you have got to do it in v6. That's all I have to say.

Thank you very much.

APPLAUSE

Vu The Binh: Thank you, Philip. It's very informative presentation. Philip loves questions. So please, any questions from engineers?

Yoshinobu Matsuzaki: It's not a question, but you mentioned it's better to use the first /64 for loopbacks to even configuration, but these days we have automated tools to configure routers, even the BGP sections. So I prefer to use the first /64 for DNS server, because still we need to configure it by hand in some cases.

What do you think about that? Still do you prefer to use a short address for routers?

Philip Smith: Yes. You are from one of the more sophisticated ISPs who have got all these lovely auto-configuration tools. I think what you are doing is fine. I'm finding the folks who are still logging in and typing things, the less they have to type, the more

chances of things being correct the first time around.

But it's usually -- your mileage may vary, type of thing. Using the first /64 for DNS cache or unicast makes sense as well, because that's an address you will probably have to type in somewhere, rather than an automated tool doing it. All good to me as well.

Aftab Siddiqui: I would like to add we are not using any fancy tool of auto-configuration, but still we are using the first /64 for the DNS cache, and the whole first /36 is for infrastructure and the very first is for DNS cache and the rest is for email and all that stuff. So even still it's workable.

Vu The Binh: Any questions?

Alastair Johnson (Alcatel Lucent): A question around broadband numbering. What is the view on the numbering of the WAN between the home CPE and the B-RAS or BNG, using linklocals only or a numbered WAN interface?

Philip Smith: Numbered.

Alastair Johnson (Alcatel Lucent): Why?

Philip Smith: I have worked with one provider who uses linklocal for the backbone point-to-point links and it all seems to work just fine, there are no issues. But then when it comes to actually testing point-to-point links, which people want to do, then you do want to have a global address -- a nonlink-local address, I should

say.

Alastair Johnson (Alcatel Lucent): I agree in the backbone, absolutely, but in the case of a B-RAS to the CPE, the broadband forum recommendations never made a conclusive recommendation either way, you could support numbered WAN or unnumbered WAN. I am curious to see whether there is any view from anyone deploying the v6 broadband, what is more prevalent?

Randy Bush (IIJ): You want to ping the CPE?

Alastair Johnson (Alcatel Lucent): There is nothing stopping the CPE having a globally routable address, just not necessarily on the WAN.

Aftab Siddiqui: I hope Andy won't kill me. We don't have a mass deployment of broadband CPEs, but still we are using numbered, like the way Philip said, just basically for the tag to check the point-to-point connectivity.

Other than that, if it's unnumbered, it works fine, no issues. We tested it in a lab, we didn't ever go for the private, it's just the point-to-point testing, otherwise I don't see any difference in that.

Alastair Johnson (Alcatel Lucent): From my perspective, I was curious what people's views are. I work with a lot of operators that deploy IPv6 broadband or are in the process of deploying it and the question comes up a lot. I get asked, "What would you do?" I have been

mostly indifferent on it. If you want to ping it from a centralised location, then you need to be able to reach it.

On the other hand, very few people do that, at least in a large scale v4 broadband today. If you are ever getting to the point where someone wants to ping the WAN address, bearing in mind that most v4 CPEs today don't respond to ICMP anyway on the WAN -- and we can argue about whether that's good or bad -- you are probably getting to the point where someone will jump on the B-RAS and be able to ping that linklocal, if they need to.

One thing that has been a consideration for a lot of people in scale is what it does to the FIB on the B-RAS because if you have a numbered WAN, a linklocal and a delegated prefix, you have at least three FIB entries being installed for that same subscriber, possibly four if they are a dual stack subscriber because you have a v4 FIB entry as well. Certainly for some vendors that's a challenge and for some operators it's a challenge.

For those looking at broadband, it's something to think about.

Randy Bush (IIJ): In general, the FIB is the only reason that I have never heard, when asked the question, "linklocal or global", that the answer isn't "global".

Linklocal is just a recipe for pain in the long run and theoretically we have enough IPv6 space to last at least the small amount of my remaining career.

Alastair Johnson (Alcatel Lucent): I agree, the FIB has been one of the major constraining factors, at this point.

Vu The Binh: Thank you. It seems --

Siamak Hadinia: One question from the chat room, from David Woodgate.

This question is for Philip. Views on the extent to which /56 is seen as the industry standard now for fixed broadband services, as recommended by BBF in TR standards? Also, extent of use in industry of prefix delegation so far, other than manual configs of customer networks?

Dean Pemberton (InternetNZ): I can have a go at asking a question which sounds like that.

What's your view on the fact that /56s have for a long time been the industry standard that people would delegate out to fixed line customers? Is that what people are doing, are they larger than that, smaller than that, have you got an opinion?

Philip Smith: What I've seen, I've seen a lot of people use /56s. I think David was saying there that the /56 is recommended by the broadband forum. I don't know if

that is right or not. That seems to be what the majority are doing. I'm still a /48 person, I suppose I've just been around too long, because that was always the original design intention. But that's just me.

Dean Pemberton (InternetNZ): I think the second bit was on whether people are using things like DHCP, prefix delegation or whether they are going for manual?

Philip Smith: DHCP to PD?

Dean Pemberton (InternetNZ): Yes.

Philip Smith: Yes, we are starting to see that. This is one year old information, but anyway.

Laurie Benjamin (IIT): I am eager to know if any operators know of customers who are utilising unique local prefixes?

George Michaelson: As an informational, I see a phenomenal number of reverse DNS queries for ULAs at one of the delegation points we are in now, dot alpha, something like 34,000 a day, so they are unquestionably in use because we are seeing attempts to resolve them.

Laurie Benjamin (IIT): That raises the prospect that the carrier or the service provider has to carry their prefixes through the backbone; would that be right?

Yoshinobu Matsuzaki: No. There was one customer who was interested in using ULA, but we suggest it to use global unicast address. It's easy.

Philip Smith: I was going to say that ULA should not be routed on any backbones, they are only intended for -- well, local networks. They shouldn't be going to other networks. I'm trying to avoid the name "site local", which was the old description for this. But no, they shouldn't be routed outside the local network. The fact George is seeing all these reverse queries, it shows there's quite a lot of use but you wonder how much is actually leaking out.

Alastair Johnson (Alcatel Lucent): Just to address David's comment a little bit, and Philip as well, the BBF does recommend a /56 as a general deployment case, the documents specify at least a /60 and recommend a /56 and /48 may be used. They don't force you into any specific one but it must be a delegated prefix that at least allows for subnetting in the home. Typically, I mostly see people use /56. I have heard of a few operators using /60, a few using /48, the average is /56.

I have spoken to one operator who wants to use /62.

They were talked out of it after pointing out exactly what Philip did in his presentation before.

On the ULA question, I'm aware of, from a mailing list -- I can't name the provider because it's a private mailing list -- but there is one provider which has

mentioned they are currently configuring their CPEs to offer a ULA in the home network, but they are evaluating that and may in the future remove it.

George Michaelson: I would like to correct the numbers.

I see 150 ULA sources, which means they are leaking, and I see 500,000 unique ULAs a day.

Vu The Binh: Any comments? Any further questions? We still have some minutes before the break.

Probably, before having the break, we would like to -- if we have one sentence or -- we have more.

Siamak Hadinia: A question for Philip, again, from David Woodgate. Are you seeing any push from corporates for a NAT66 model, because they have been comfortable with the v4 model?

Philip Smith: NAT66? Again, during my Cisco days, I heard of one or two instances where people were looking at this. But in the last year I'm not party to any info like that. AJ might be able to indicate what he's seen from Alcatel Lucent point of view, but I hear one or two anecdotal things about NAT66, but that's it.

Dean Pemberton (InternetNZ): When I talk to customers that historically have had very, very firewalled networks and exert a lot of control over what flows through them, they are uncomfortable about losing what they think they gain from NAT. In talking to them, what

they are actually gaining is through application level gateways, so you squirt them down that path. But I have certainly had customers who wanted to keep one set of internal and one set of external and thought that bought them something. More than a couple had that sort of mindset.

Siamak Hadinia: The comment from David is: it doesn't mean I want one!

Alastair Johnson (Alcatel Lucent): I have heard people ask for it. It's come up a lot in the IETF recently, the site renumbering working group has taken that as an issue.

One of the domains I have heard it most vigorously from has been the defence organizations, including one organization a couple of years ago that point blank said they will not deploy IPv6 without NAT66 or NPT66.

Vu The Binh: Okay, thank you. Maybe the last sentence you want to share with the audience, before having coffee.

Philip Smith: With my APNIC learning and development hat on now, the APNIC training team gets a lot of requests for v6 training, obviously. But one of the things we are getting all the time is, "Please help us with IPv6 address planning." A lot of people are asking for the planning. They always say, "But you must have a best

practice plan." A lot of people don't realise the v6 address plan very much depends on your local conditions, how your network is designed, how big it is, how small it is.

You have heard three completely different ways of doing an address plan. They all work really well for the operators concerned. They all scale. So I hope you see that there's no one size fits all and for what we have shared here, you are actually a bit bolder to now go forth and try to figure out what your own address plan needs to be.

I'm sure I can speak for my colleagues here, we will be happy to help you, but not do it for you. Because what you need to do is very much based on what your own requirements are.

Yoshinobu Matsuzaki: From my side, address planning is to prevent confusion, so it is to help you to make a new assignment in your network. So not such a complicated one, just do comfortable for what you need. That's it.

Aftab Siddiqui: I want to add to what Philip said; even I mentioned in my presentation that there is no BCP, no best common practice. From the IPv6 Task Force Pakistan platform, I went to a couple of places and I ended up answering the same thing, like I can help, we can help, our association can help, but we cannot do it for you.

It's the same thing, like I cannot do your homework.

It's like, you know your network, you know your requirement, you know how to do it. We will tell you bits and pieces, but in the end it's your job.

It's not difficult. You have the opportunity to do things from scratch. We had no opportunity in v4, luckily we have it in v6, so let's do to properly.

About ULA, I seriously don't think that anybody should be using it. I don't know why people are using it. Even then, they are leaking it in the routing table. So I guess there should be a list. It should be in the cyber report, what do you think? It should be in the cyber report that these ASs are leaking the ULAs.

What do you think, Geoff and Michael? Just a suggestion. It's just a suggestion from my side.

Philip Smith: There is actually a v6 version of the cyber report. I don't think Geoff emails it out anywhere, but there is a v6 version and it does point out bad misses like this.

Aftab Siddiqui: Maybe it is time to email that one, because most of us seriously follow the cyber report and the routing table. Anyway, that's my point. I guess that is it from my end. Thank you.

Vu The Binh: The conclusion is that addressing planning for v6 is not difficult, that is the good news; and the

bad news is there's no one single model for every case.

So every operator, every enterprise, should have their own vision, their assessment on the network, and it's never too late to start planning today, and try to use the experience from the community, from the operators, and also using the tools effectively.

Again, thank you very much to our three speakers for very good presentations and discussion, and also thanks a lot for your questions and participation.

It's time for a break, and we will come back later on. Thank you.

APPLAUSE