These are unedited transcripts and may contain errors.IPv6 Working Group session on Thursday, 19 April, 2012, 2 p.m. to 3:30 p.m.:
MARCO HOGEWONING: Yes, we are back. Welcome back. Find yourselves a seat. Second session of the IPv6 Working Group, again for those of you who weren't here the first time, be aware the session is broadcasted, so you are on TV, smile to the camera. Secondly, if you wish to make a comment, please use the microphones that are in the room and please statement your name and affiliation so we can put that information in the minutes and relay that to the remote participants.
This is the agenda for the second session, as I explained earlier this morning we are going to start off with Jari from Ericsson showing his experiences in automatic home networking with respect to IPv6, and then the main beef of this session will be a discussion about profiles, changed that were discussed in Vienna and at other platforms and meetings. Before that we asked both Erik van Uden and Tahar to join in to show how the current document is used and handled from the perspective of a equipment vendor and Tahar is going to show the same answers but from the perspective of the German public administration.
As far as AOB is concerned, I have got people approach me there would be an announcement about the programme committee elections after that so please don't run off immediately once we are done. Again, if there is any other business that you'd like address, please find us, the three Working Group Chairs at the front, and we will try to fit you in. With that, I would say let's go, and I give it up to Jari.
JARI ARKKO: Hello everyone. I am going to talk about automatic home networking, and at RIPE and many other forums, you have had plenty of discussions about home gateway routers and how they support IPv6 or don't support IPv6. We also had plenty of discussion about fixed ISPs and mobile ISPs, how they can provide IPv6 service to their customers. This presentation is not really about those topics, and they are important things of course we have to have IPv6 service and capable gateways, but what I wanted to talk about is the network in the home, what kind of architectures are possible, what the problems are and what the IETF is doing about it and also some experience about running some implementations in this space.
And this is also related to an IETF Working Group, the HOMENET Working Group that was established last year, that is working in the space, trying to come up with mechanisms where you can automatically configure a home network without the humans touching it. And my dream is that no matter how many boxes you have, no matter how you connect your boxes at home, you shall have a network that is automatically configured, all parts of the network shall have addresses, the routers know where the sender ?? where to send their packets, names result addresses in usual manner and no human touch involved in this. In particular, I don't want my mother to have to configure IPv6 prefixes and the like, God bless her, she is a nice person but not very good at configuring IPv6 stuff or IPv4 stuff so I'd really like this to be sort of a completely automatic and not requiring any attention from humans.
And many of you are probably thinking that, oh, we can actually do this. If you assume one router and one somebody set behind that router the problem is pretty easy, we know how this code that does that, the only problem is I am not entirely sure that those assumptions hold true if all cases, can we live with one router and one sub net. I don't know, but I will offer you a couple of counter examples of this situation. One thing is today if you go to the shop and buy a wireless LAN access point router you are likely to get a device that actually offers multiple different networks for guest and private and so on. We also have hitter genius link?layer technologies, some of which can't be bridged together so you basically have to route or NAT between two different networks. Some of it you can bridge together, but there is a huge speed difference between some sensor networking technology and gigabit ethernet or 10 gig so you may not want to because you overpower the slower network with all the traffic on the bigger network, particularly if you have lots of multicasts and broadcast traffic.
We will also experience an explosion in the number of devices we have at our homes so it needs for structuring your network in different ways in the future. Finally, this is something that has happened on the v4 side: Today, if people have a problem in their homes and they can't reach all parts of the house as an example with the wireless LAN they will go to the shop and buy a new device and plug that into the network and lot of the cases is that actually introduces another layer of Nap or another routing had you been, and I predict that something like that is going to halve happen in the v6 world as well, so networks are not always nicely designed; they will just gather junk as time goes by.
So I had a dream but I also had a nightmare, so we could also fail in this effort and get this wrong, and the primary danger actually is that IPv6 becomes too hard to use, so people will see that, OK, it's easier for me to extend my network by buying this IPv4 devices and NATS, I will use that and not bother with this v6 thing at all. Or there is other possibilities I keep worrying about seeing these environments where we have two IPv6 networks connected by gnat 66, I call this the number of the ?? solution for 666 and it may not be the best thing but if that is the only thing that is available for people, that is what they will use. And we will also, whatever we do we might end up with similar chain NATS have had had on IPv4 so even within your home you might have areas where it's not easy to communicate between two devices some of because NATS in between.
So to address these issues the IETF home networking group was established last summer, very active working group, lots of participants, I am one of the authors of the document and also author of a couple of the different individual proposals for solutions in this space. And the Working Group is basically starting from plain old IPv6 basic specifications, DHCP 6, PD, 6204, the CP requirements document, the simple security document and so forth and the goal is to support multiple subnets and routers. And do it so that you will have automatically configured prefixes around the network, running routing automatically and still being able to do naming and service discovery within the network or within the entire home and mot just restricted to a single sub net.
And to give you one example, as some experiences about the types of environments where this technology might be useful, I will talk about my own home network for a bit.
So, this is the network diagram from my network, it has all the usual stuff like 200 ports of ethernet, 4 kilometres of cat 6 cable and my laundry is talking to Facebook or to me on Facebook, so useful stuff. What is interesting in this is not the applications per se but how the network is internally constructed so I ended up creating roughly a dozen, 11 or 12 different subnets or prefixes out of my sorter prefix and of course, I needed one prefix for the external phasing ISP interface and naturally also I needed my primary private network side prefix but why did I need those ten other things? Well, I wanted to have a visitor network so that needed one prefix, and then I was experimenting with this NAT 64 or IPv6 only technology, and if you know that technology you basically need one prefix for devices behind that NAT thing, and then you need another prefix to represent the IPv4 universe inside IPv6 address space so you burn two prefixes per one NAT 64 device and I actually wanted two because I needed one internal and one for the visitors.
And then I also had a few special case networks, utility networks, gateways to legacy centres and these too often for various reasons needed to have their own address space, utilities they really want to run their thing on their own rather than mix it with my Internet. Today, much of that is v4 but in the future I think we will see v6. But the res own is that I ended up for various reasons having very many sub networks within my bigger network.
And having done this and having lived with it for several years, I have some experience to relay to you. So, one thing is that I started with doing all this manually, I configured everything manually, and we are the geeks and you can do it and I can, right? Well, not really it, I later realised I had to run a routing protocol in one case and I realised I don't know how many devices I have in my network or what they are, maybe I should discover that with a tool, and now I have lost track of what prefixes I have where. It's ?? I don't want to remember all those numbers so it's difficult, so I have forgotten, apologies for that.
And then one day, I woke up and realised my ISP had renumbered me, which means that OK I have to redo everything again, so not very nice. I am a geek but I can't could it, I have to have automation even for myself.
So the home networking group is trying to address this space, and we are going about it in a couple of different ways. So first of all, we try to make recommendations to turn on things that already exist, so obviously prefix delegation would be something useful to turn on on your interface towards the ISP because that is how you can get address space for yourself. Obviously you will need to put in the prefixes in their RAs in the usual manner, if you need routing then the usual routing protocols probably will work for you. And then on top of this existing things we then have to do a little bit of tweeking to make sure that we have fully automatic self?configuration. And so the focus is really on running code plus some minor improvements and our architecture roughly speaking follow the IPv4 model in the sense wherever you had a NAT 44 device plug in a v6 router instead so it's very much the same. And we have plenty of solutions in the routing space, proposals so far the Working Group has not chosen any particular one. We have some based on on RIPng, some on Ripple, we even have some proposals on extending neighbour discovery with some very simple distance vector based routing scheme. We also have prefix configuration solutions of two kinds, one is based on routing protocols and the other one is based on hierarchical prefix delegation. And I have been personally working mostly on this routing protocol based approach for various reasons, I believe it's superior, I also wanted to learn the routing stuff better than before and this is an architecture picture of the routing model so here at the top you will see that there is a connection towards the ISP in the usual manner so you route packets to it. And you might have the HP C6 PD to ask your ISP for the address space so you have to do it manually. Either way. And then in this particular picture you have two routers and four different network segments that end up as their own subnets. And of course, any routing protocol can run the routing part of this inside this network, nothing fancy about that. What we wanted to do is make it completely automatic. When do you this set?ups you have professionals like yourself actually setting it up, but if this is my mother or someone else, you know, not a specialist sitting it up, they don't want to do it. And what we needed to do is to tweak the defaults a little bit, like picking the right area numbers and ID numbers, we needed to automatically generate the router IDs because that is how OSPF works, and we added ability to do prefix assignment. If one of the routers in the home network let's say the gate way home in address space had a we can use, then it can tell the others and they can together coordinate how they slice that up and who needs what /64.
So that is basically the idea. The Working Group has talked about other stuff, multi?homing and disconnected mode. I will skip those for the interests of time now.
And move on right to the second part of my presentation, which is about nice theoretical stuff, can we actually do that stuff, and we can, so I have implemented some of this stuff and so have some experience on the implementation and using it.
So I think I actually had the world's first home network implementation, I have been working on it for the last couple of months, a little here and there, evening week or something like that. What it does today is that it's first of all, capable of running OSPF and and automatically generating all all the OSPF parameters like router IDs and distributing prefixes around the network, multiple routers and each gets one slice of the prefix. And what it also does is that automatically configures router advertiser demons so you will send whatever you configured as the prefix here, you will advertise that prefix on the router advertisements on that interface. And what I have been doing actually this week, adding some code to this is make it integrated to Ericsson's NAT 64 implementation and it's actually pretty nice now because you don't have to do anything for the NAT 64 so unless you had the NAT 64 implementation around, it can configure itself completely automatically so there is two prefixes they come from this system, completely automatically.
Now, if I could go to the next slide. So, what were the goals: Obviously, I needed to understanding what this ?? what the real needs in this space are and how well the designs actually work and validate some of the specification that is we had been proposing without duly doing this stuff, it's only on paper. You don't really know if it works and there is many things that experience will show as we actually go through this exercise. But I also wanted to build on implementation that would keep my home network autoconfigured, like NAT 64 and prefix assignment, so I don't have to remember the prefix allocation any more. I also wanted to understand routing a bit better and maybe some part of this implementation can be used in the future for some testing if the home networking group will do that.
And my implementation is pretty incomplete for now, it's a hack or prototype, but I do have some experiences; I claim that the technology itself works as intended. It seems to be nice. It may even be useful outside home environment so this was made for the home networking group in particular but our OSPF auto configure extensions are probably applicable even in some enterprise networks. The OSPF V3 draft was very easy to implement, trivial almost. The prefix assignment part was not so trivial, it needed more work but it was still possible or relatively easy to do. OSPF V3 itself was very difficult to implement. I did it from scratch, but any sane person would have actually used an existing implementation and just added to it. And I have also gathered a fair bit of technical feedback on exactly how we need to go about this specifications and designs and I won't go into the details of that; I will just highlight one big thing which is we did not fully understand how fully tied up these things are with the rest of the environment. And just to highlight some of those interactions with the rest of the system, so of course if you have something that runs OSPF V3 you need to talk to other routers that do the same. That is well understood. But in this particular case you also need some other interfaces. So first of all, you have wherever you get your prefixes from or your address space from, so this might come from the ISP with DHCP PD, one option, it might come or from manual configures if your ISP is like mine, or it might be that if you ?? if you are coming up for the first time and never had a contact with your ISP before and you can't find your ISP anywhere in the network so maybe it would be better to generate your own address space using this ULA or unique local address space. Which we can do. So three sources for the information.
Then you have multiple places where could you put the information once you asign the prefixes, you need to configure router advertisements. In my particular case the NAT 64, also something that I didn't mention earlier but I have some gateways to sensor networks that burn IPv6 address space as well so there is multiple places where you use this information. And finally if you are routing and you are forwarding all works and you have address space, your host will not be happy or users will not be happy unless their name resolution systems work as well and for that we need to discover or start some DNS servers. And once you know what the DNS servers are you can distribute that information once again with DHCP personally or routing advertisements using 06. There is a couple of interesting problems left that we have not fully solved yet, so one of them is sort of timing related, some of these things like generating your own address space through ULAs is something that you would want to do but maybe not immediately, since wait a little bit, ten seconds or one second or five minutes, when do you start that. It might be harmful to generate that too early because maybe the other router that have is giving you IPv6 connectivity to the Internet is just coming out. The other thing is dual stack and v6 only networks have differences, most people think in terms of dual stacks and that is what I would recommend for most people to use as well, but I have been sort of testing this v6 only technology at the bleeding ? in some sense, and there are some differences, so one difference is that in v6 only you absolutely have to have DNS discovery, otherwise you don't get anything to work. On dual stack ?? resolve your names. That is completely fine. But it's not possible in v6 only. Another difference in v6 only if you are using NAT 64 you might find that you have DNS server DNS 64 server that is doing some translation from the real information into some mapped information so you can do the NAT 64 thing. And you really want to use that behind your NAT 64 device, but ?? and you really don't want to use it elsewhere. Because the mapped information is incorrect elsewhere and you should not rely on it. So discovering that and finding what you can ?? what name service you can advertise where, is really important.
So, with that, it's time for summary. I believe this technology is interesting, I am excited myself of trying to use it and it seems to work. I think it's potentially interesting for multiple applications, not just home. The home network Working Group at the IETF is very active in discussions and meeting, so please join the discussions, your viewpoints would be appreciated. I know of several implementation efforts, I think mine is the first one that actually runs, but there are at least one and maybe three others that are in progress. And I would also claim that we are still in the exploration phase, that I am not necessarily doing this because I am get to go release a product next month, but I am doing this because I want to understand and see how well it works and maybe this is the right solution, maybe we need to go back to some other solution but without actual practical experience we don't know, so we are in the exploration stage, if you have opinions on what you think would work well, what kind of requirements you have, what kind of things you would like to auto configure or if you have opinions on how we should do this auto configures, then those would be appreciated.
So that is the end of my presentation. I will be happy to take questions and comments.
AUDIENCE SPEAKER: Benedikt Stockebrand. Why do you use OSPF rather than RIP, is there a specific reason for that?
JARI ARKKO: That is a good question. That is one of the things that we are sort of playing with. I think RIP would be more easily available. I think a lot of code bases that exist for home routers already, they have RIP inside, even though it's probably not used much but it's there. So that would be an advantage for RIP. I think it's ?? with a links routing protocol I think it's easier to do this building a topology map and then understanding what is where and where do I need the address space. And it's also theoretically a bit bet in terms of coping with network ??
AUDIENCE SPEAKER: The advantage for RIP in my opinion, main advantage, people running home nets or small company networks, when they run into trouble and actually are just about capable to start a wire shock or whatever, they have a fighting chance when dealing with RIP but not really with OSPF, not if you touch it maybe every second year or so. RIP is much easier to understanding and get along with that.
JARI ARKKO: Let's do an experiment, we will go meet my mother and so one with RIP and one with OSPF and see which she understands better.
AUDIENCE SPEAKER: Yes, but your mother is very unusual because ?? not ?? no, no, she is very unusual because she has a son who can deal with OSPF. There are a lot of people out there who have one sort of jack?of?all trade generic administrator person, and those are the people who have to deal with so many different things. RIP is easier for them. I have had a couple of these in various trainings and OSPF is simply way out of scope for these people and it's important for home networks and for small companies.
JARI ARKKO: Yes, I mean, I won't argue too much against your point. I think the jury is still out on that and we have to see. That is one of the things we want to experiment with, is this working well or not and who can play with it and can you find code for these different implementations, I want to ring up myself ?? out of the blue before I started this project and started hacking with routing stuff, you mow, if I had looked at RIP and TCP done by wire socket and RIP it would have been useless without some ?? maybe it's just me.
AUDIENCE SPEAKER: We will talk about that later, maybe.
MARCO HOGEWONING: Dave and Randy standing up and after that we move along.
RANDY BUSH: IIJ. I think your mother would find a TCP dump of IS IS much easier to read. And you left out VRRP for when you have multiple exhibits.
JARI ARKKO: Yes, I mean, I didn't want to go too much into this multiple exits business.
RANDY BUSH: You got deep into everything else.
JARI ARKKO: True. I mean, just for historical explanation, I think the IETF Working Group has been discussing quite a bit this multiple exhibits and homing of various sorts and there is also a history of different Working Groups in the IETF looking at this space and pretty much now ?? not getting any success over the years so I am reluctant to go into this multi?homing thing. I think we can do it but, yeah, anyway. Should I do VRRP.
MARCO HOGEWONING: Randy, we are so confident in our ISPs we don't need multiple exits.
RANDY BUSH: You are just very lucky in the Netherlands to have everything so reliable.
DAVID FREEDMAN: Claranet. I just wanted to follow up on this as well, having watched this new Working Group in the IETF form, which I think is incredibly useful and will produce a lot, I hope. I must say that the argument about the choice of routing protocol, that was very painful to actually, to watch, because, you know, RIP has got all sorts of problems with it, robustness being one of them, not that you may need as much at home, do we need routing at all, can any of this be achieved by bridging and out of the people coming out of the woodwork, no, it's too hard, we can't bring. This is a combination of a lot of work gone on behind the scenes and has involved a lot of vendors about what they think is feasible. I was surprised hear that OSPF V3 may be more feasible than some of the things but one of the better suggestions so far.
RANDY BUSH: Do not be confused. I in no way was suggesting RIP. Right. And I do have some sympathy for routing protocol within this environment, and I like routing protocols but I just think you might think of something simpler than OSPF. I mean, you couldn't think of something more complicated.
JARI ARKKO: I am all ears, Randy.
RANDY BUSH: I was serious in my suggestion.
JARI ARKKO: OK.
RANDY BUSH: 1912 be dammed, right. Something simple.
MARCO HOGEWONING: Thank you, Randy. Last word to Gert.
GERT DORING: IPv6 user. I am quite happy to see this happening and to see progress on that front and I am sorry to hear that we are rat?holing ourselves into RIP or OSPF the protocol of choice again, because I am absolutely convince that had anything shipped to a home user either needs to work on auto pilot or will be thrown into the junk bin anyway. 99.99% of all home households will never, ever look at a TCP dump or try to troubleshoot it. This is not for small office, this is HOMENET and homes need to be on auto pilot and work automaticly. I don't really care which protocol is in there at all as long as it's properly standarised and works. That is the point I am interested in.
JARI ARKKO: Absolutely. We do have some real data about people throwing this home gait face and routers away, even simpler things than routing not working, typical address that they select for their enter face and if that collides with something else in the chain of NATS that is a problem and people return the box or throw it away and get another one, that randomly has a different address space that it uses and then it just works. Throw the thing away if it doesn't work, that is the way people deal with this at homes. So thank you.
MARCO HOGEWONING: And of course, there is the IETF HOMENET list for further comments. With this discussion actually, quite a nice bridge to our next speaker, I invited Erik here and I asked him one simple question: We, the community, the operators, are throwing loads and loads of standards and profiles to you, to the equipment vendors. Erik is one of those people that built this little boxes and here we are discussing whether he should implement RIP or we should implement OSPF. So I was clear in asking him to answer that simple question: What is your take on all this? What do you prioritise and find important? So up to you to answer that one.
ERIC VAN UDEN: Thanks, Marco. Good afternoon, and that is a very nice simple question. Obviously, it isn't a simple question. In this short presentation, I want to show you some thoughts we have to implement new versions of software and stacks and in this case, I used IPv6 but of course, you can say this ?? you can't say this for every protocol would have to be implemented in our products. I am just a poor sales guy so I am not really deep technical but I try to explain the ways and how we think you should implement stuff into products.
Some words about AVM, one slide, don't be afraid. We are German company and we are producing CPEs in several techniques like LTE and DSL and like the cable environment. We do this since a very long time.
But, coming back to the question that was raised by Marco. IPv6, yes, we want to have this in the FRITZ box, and how? And who is setting standard, and who has the, let's say the strongest word on this, and so on and so on.
So first of all, the influencing factors in this case: Just an example; we have in our customer base a customer who really doesn't have enough IPv4 addresses left. So he needs to implement stuff, in this case DS light, into his product to have the growth in their network. The second is, that they have some customers from us, they want to have the new technology into the FRITZ box and want to be ahead of the competition. In this case we could say example is Dutch ISP access for all, first in the customer environment. The second is road map decision, more internal discussion. It's for AVM it's important we are in front of the competition and we show we are technology driven company, we produce products for the end customer. That is the way we work and the way we have these products and in this case a few years ago there popped up IPv6. Do we need this, question?mark? And the answer was very quick: Yes, we do.
And the other hand, same as you heard here, it's a discussions find from developments in the market from other sources, very good example in this case is the home network. There are some movements in the home networks, we are just the home Gateway, so we have to do the discussions with those guys who are sitting behind us like de... and like s... boxes and so on. But standards, again there are a lot of them. One important one is the E router standard, this came from the cable environment. Well?known IEEE, well?known IETF and in this case we have for IPv6 really looking at what's happeneing in the RFC 6204. The last RIPE meeting in Vienna, the RIPE and the ISOC and so on. Again, there are a lot of standard organisations who wants that we use their standard and they wants that we use their ideas to implement in the FRITZ boxes.
But, if you look a little bit more deeper and we just take as an example the IETF 6204, and you see there also in the RFCs there is a must, must not, required and so on. But the problems are mostly related in the ? should, the mays and the optional. There is the point of discussion and where we run into sometimes very long discussions with our customers, examples are on 6 RD, the size of the networks. This is a very interesting discussion.
There is also another way of sorts where we have our new implementations of our new functionalities and to our products and we call this labor and something called beta firmware for the FRITZ box products. And we ship this out to customers in several versions and can implement this into their FRITZ box and play with it and give some feedback on what they like or don't like. Of course, when it's got this version into the field it's already tested within AVM with colleagues of AVM, but it's still a beta firmware, so there are still possibilities that something won't work in the field. We did it as well with IPv6, we started just an example again, we start with IPv6 in the labs, we did some testing with some ISPs and we find out some interesting points, we want to have this and that and then we say AVM, OK we see this question coming up several times, let's do it, or just one question we don't implement this.
It all ends in the stable version of software called FRITZ OS and a lot of functions came internally from our development department and from the labor laboratory versions, and that is why we have, let's say, two, three times per year a new major framework update with new versions. By the end of the results in complete IPv6 home gait with all the things we like. Just an example to go back in the beginning, we had just IPv6, just and now there is implementation of DS light, we implemented functions like firewalls and so on. And firewalls in this case opening the firewalls because in the beginning it was the firewall was closed for everything.
And now, all this stuff implementing this, we are for the other side we have questions from a lot of standard organisations: If do you this, we like that you have a logo on it, and now becomes interesting for us as a vendor, and I am afraid I have stepping on some toes now but let's be honest; if you look to the whole stuff and that is why I have some sentence written down on this presentation, so where is the guarantee? And it means guarantee that a product can have an IPv6 logo that won't run on European network because there is just BBPOE implemented and not BBPalpha, just an example. Another example is what does it bring us? The same example is if you look to the DLNA, there are a lot of products on the market that say and they say and they claim we have DNLA logo but doesn't guarantee at all that you can move movie ?? watch a movie on your television coming from a sat at that box. There is no guarantees of network sources. We have this logo but I already explained we do every year two, three new firmwares. How about this: We test again? I don't know. And big installed numbers, they have just bought at my premises more than 60,000 CPE IPv6 capable CPEs, tells me a lot more and the customers tell me a lot more than just a small logo. So for us, we had let's ?? a big hurdle and a big question, how to handle this and just an example is IPv6 logo, what is pushed by the ISOC. And now we didn't do it. And the same question we could ask, OK, what is relevant? Is it relevant for the ISP community? I don't think so. Because when it won't work, they come to us. That is our experience from the past. All the large ISPs comes to us, doesn't work, fix it, AVM. That is the whole solution.
This was more my small, very small presentation, with some ideas and with some feed for discussion, mainly focused on this logo standards. Thank you for your attention.
MARCO HOGEWONING: Thank you.
If there are any questions for Erik, please mind a Mick. I have one, a bit of a philosophical one, you sometimes hear this sentence about killing your darlings. You introduced ?? okay, we have got this lab versions and beta versions which we introduce new features. Is there also a point where, based on lack of feedback or progress, you say you know what, kill it, move it away, we have tested this in the lab and we are not ?? we are not happy or nobody said I like this and we will drop it out again?
ERIC VAN UDEN: Yes, we had a lot of this stuff. One example is the whole ENUM. This is a very ?? I have noticed was a topic a few days ago here. We implemented ENUM into FRITZ boxes a very years ago. No one was asking for it so it's more or less taken out. Other functionalities like we changed was the automatic set?up in IPv6, in the beginning maybe you remembered when we didn't receive fixed IPv6 we just used a tunnel, and now we changed this behaviour. So, yes, it's always, it also depends on what was coming back and sometimes you send out a lab and there is no feedback at all but you see downloads. It's very complicated. For the international customers you have to learn about this feedback because if you look to the German figures there is more feedback coming on software back than we have in international market. It's becoming more and more because our position in the European market is becoming more and more stronger and also branding is becoming stronger but you still see that also in percentages from the German market it's more common to have this feedback to us.
MARCO HOGEWONING: OK. Thank you. If there are no further questions, then thank you, Erik, for this short update, that is really clear and also for the experience in the CP surveys, yes, having a logo on a box doesn't say much at all, that is unfortunately still a fact. So thank you. Which brings me to the next more or less lightning talk, was last minute addition to the agenda but we have not Tahar here, Tahar Schaa who is working for and with the German government. Last meeting we had Constanze presenting their project, some details on implementing equipment profiles and what message to give to their vendors and suppliers.
TAHAR SCHAA: I am happy to be Constanze's consultant to introduce IPv6 and in a sense making way in German administration. And I would like to give you a brief update about the activities there.
We made IPv6 research project in Germany to develop a profile and give some guidelines. What was the initial position in German governmental networks, we had long growing IP networks with all the same, 1000 /8 addresses, so many overlapping internal address space and so public organisations, when they get connected to each other and has to communicate with each other, has to do several times gnat 44, horrible. The services which are used and are still used is e?mail mainly, web, and some web applications for e?government process work flows.
What would be really nice to be used in governmental networks is voice?over IP and video?conferencing due to fix ?? to quick communicate with each other, not to travel around. And of course, in the beginning, IPv6 was not in use.
So to give you an overview of what is this all about. This is some of the scheme and overview about governmental networks in Germany. What you see is every organisation, if it's a municipality or federal State network, is somehow connected to another internal governmental network and to the Internet in parallel.
So, what we first did, and Constanze reported about this before, we take care about address space, so we get an allocation from the RIPE founded LIR and now we have a/26 for the whole German public administration. And we made address framework to do this. This is somehow unique, some countries are really looking at it and say we would like to have this because with this you get an organisational anchor to communicate with all the relevant people, and then you can talk to them and you have an organisational structure.
Yes, the LIRs is operated by the ministry of interior and an agency beneath it. Now we have got addresses but what next? So in the reality of the public officers ready to introduction IPv6 in their organisations, are they ready to procure? No, OK, they need help. What are the difficulties? First thing is of course, IPv6 is important and in every tender in the past years they said, OK, if you want to take part in this tender and you want to offer, you have to provide IPv6, but only some IPv6. So, the manufacturers and the bidders said no problem, we provide some IPv6, but of course this was only to match the requirement, if you want to ?? if you try to use these implementations in real life networks they won't run, you have big problems. This was not implemented and this but the manufacturers and the bidders said to us OK but you didn't say it before. We didn't know. You just said you need some IPv6 and that is what we thought about some IPv6. In addition, the responsible persons shrink back a little bit from IPv6 migration because they don't know how to go there, they need something like IPv6 introduction into administration for dummies, with step one to N, so they need best practices and guidelines because they fear about doing something wrong. When they don't do anything, they can't do mistakes.
So, the second part of our preparation in German administration for IPv6 was to set up an R and D project to develop these two things and IPv6 profile which contains an IPv6 profile matrix for components. We made also one for applications, so we a little bit looked up on software too and made a description how to read it. And in addition, we made a migration support document, so migration guideline and some workshop slides at the organisation in the public administrations are able to deal with this topic, IPv6, in the first step for themselves so they can set up a workshop and discuss where does it be relevant for us, in which part of the network, who has to do what and who is responsible and so on. And in some checklist that they can check that they never, that they don't lose some topics to make their mind about it.
So what has to be migrated? This is a question not too easy to answer because first you have to think what is a typical architecture of a German administration network, and so we ask many people, we looked up on several networks and something like a reference architecture and based on this architecture, we tried to justify our profile. And then we switched to the profile. Of course, IPv6 is defined in many RFCs, much too many RFCs for procurement officers to check within tenders so we have to do it much easier. First we looked up on the existing other profiles, of course, also RIPE?501 was the main basis for our work but all the others, too. And then we created structuring, because for us, with the existing profile we somehow was a little bit confused because we didn't really saw a structure within it. The first structure was with this device classes, of course, a note and in addition, end system, router, the security devices, not really often mentioned in the other profiles, and also the infrastructure server because what we found out where the manufacturers have often the transport and the addressing, everything is in place but if you ask for management and monitoring, it's a little bit a black hole where nothing is implemented.
And another structuring was we structured all the requirements and all the related RFCs within function blocks, so we started with IS MP transfer, then all the RFCs and requirement for addressing, DNS, migration mechanisms, securing multicast and in addition management, so we didn't go through the numbers of the RFCs but looked for the functions.
How does our profile look within our matrix? We ?? here you see on the left side the function blocks, here is base things and there is ICMP, neighbourhood discovery and beneath this all the related RFCs, some comment on this and here in the rows, our recommendation, what to do with this requirement. And if you doubt our recommendations, you can look behind this for the other profiles, what they thought. Normally, we are not so far away from the other profiles, and what we did, we looked up on every recommendation from any other profile, so you see here some profiles have here white cells because they don't state something for this requirement, but if one profile has a statement for this, we have a statement also. And if we differ from what the other says, we have here the justification.
We have done this a little bit also for applications. This was a really not so easy thing because we first thought about the structure, how to structure it for applications, and we ended up with this. We thought, OK, if you have an application which does network, you have to make up our mind what are the paths of this application, what does this application need to function correctly. So we looked up here, there is some web application, what does this mean ?? need? It answers them, the end system has to communicate with packet filters and proxies, the server itself, consist of web server and database and then you have to look, OK, web server. And then you see here web server. What does this need to run IPv6? And then you see this, this and this, and then you can have a look at the real product, does this product match your requirements to run IPv6.
Thank you very much. Only a brief overview.
MARCO HOGEWONING: Are there any questions?
AUDIENCE SPEAKER: Jan Zorz, co?author of RIPE?501. Thank you for making our work and the work of this community useful, and I think did you it in proper German organised way. Thank you.
MARCO HOGEWONING: Before you run off Tahar, is the resulting document public domain or is this available or are you considering making this available?
TAHAR SCHAA: I hope and assume it will be available within the next two months, also in English. And then it will be published.
MARCO HOGEWONING: Thank you. Basically, it's more not to you but to the room because one of the comments raised, I think it was two meetings back in Amsterdam, where there was actually a vendor at the microphone saying we don't need another profile, but I am not sure whether that specific vendor is here today.
TAHAR SCHAA: I may something to this. We invited some vendors, it was in this project, also Cisco and some special security vendors from Germany and they were really happy to get this profile because they said we are ourselves are not quite happy with the situation that in these tenders and from our customers in the public sector only comes, we need some IPv6. At the end, they are all unhappy because they don't know, they don't get what they expected because there is no specification. So, my impression was they are happy with this.
JAN ZORZ: May I comment on this, another profile, what is going on currently with JAN 6 project one of the recommendations for European Commission on IPv6 profile, and we are still deciding on a template, probably the template for this work will be based on a 501 base or replacement or whatever way you want to call it, and the work done in, by Tahar and Constanze Germany, so probably this will kind of merge together again and be a basis for another profile that will be strictly governmental.
MARCO HOGEWONING: Thank you for that comment and thank you, Tahar, for your brief show of what is going on. I hope to see more, please if you have the document, please cycle it to the list. Which brings us to the next topic, and we have got about half an hour left.
And that is this one: Replacing 501. Where does this come from? Well, there was some discussion at RIPE 62 about pushing out this document and some new references needed, some more definition, people thought, to add to Jan whether it's called 501 base or basically if you want to update the RIPE document, you give it to new number and publish it.
There was quite some discussion, where are we now? Well, a draft replacement was cycled to the mailing list and put to last call, just before RIPE 63. At the mailing list it was fairly silent. Jan and Sander gave presentation in Vienna. Got quite a number of suggestions and feedback from the room. And also on the mailing list right there, people were posting comments. Which meant that they, the authors, Jan, /PH*EUR /KA, Sander, decided to pull back, let's edit it, let's do it again, take some suggestions into account, and try again. So, this is where we are now. The document was cycled to the mailing list by or at least linked to the document. We are in the process of also publishing it on the RIPE website but it was a bit of a close call to this meeting and people were busy. So, Jan and Sander or Jan is going to present a bit on the latest implemented changes and hopefully after that we can discuss thousand approach this further. So, Jan, if you want to take it.
JAN ZORZ: Hello, it's me again. So, thank you Marco for the quick update. Since then, what happened, we went through the whole suggestions and comments from Yoni and Yari and from Erik and also the other ones and we fixed in there what we meant it was about to fix, and then later on a lot of work was done, not on a mailing list because you guys just don't write e?mails. I don't know why. But the mailing list was just silent. So we did some work during the NANOG meeting and the IETF meeting in Paris, we sat down with certain individuals, experts in the industry, on IPsec on mobile world and this and that and went through and fixed things that they don't look wrong any more. But now, I will let Sander walk you through all the changes and then after some more procedures we will try to answer any possible questions that you had. But, I think the document is very stable now, very close to what we, the primary quarters want ?? let's check if you want the same thing.
SANDER STEFFANN: As Jan said I will walk you through the changes here and have an idea what we changed since Vienna and since some stuff happened off?list, it's not unreasonable to let you know. We had some global changes. Basically, between Vienna and now, RFC 6434 was published which contains IPv6 node requirements so we thought it was not more than logical to include the results of that in our document. And in the meantime we found out we were not very good at IPsec specifications because there were and lots of inconsistencies there. Sometimes, IPsec version 2, version 3 was specified, version 1 and 2, it was a bit messy so we just now say IPsec and we replaced this everywhere in the documents so they are now consistent in this.
Also, the Type 0 routing heading source routing was optional and we thought that this was important to make mandatory so we moved that. And there were some things in there that were actually not about v4 but about tunneling, dual stack, things like that. So to be prepared for the future, we actually added a line that says if you actually need to dual stack you need to follow this. So, we are preparing a bit for v6 only environment already.
Then we have a few extra optional requirements, so nothing mandatory but we thought it was appropriate to at least make people think about host router load sharing and default router preference and more specific routes. So they are optional, they are not in the mandatory part by default so this is just something we want to bring to everybody's attention.
Then we have a big change in the consumer grade layer 2 switch. It said that MLD version 2 snooping was mandatory and a lot of people said there is really small five port switches cannot handle this so we moved this from mandatory to optional. It's just for the consumer grade stuff. The enterprise level stuff still states it as mandatory of course.
We did some cleaning up in the mobile node devices, mobile node, this caused mobile node so we now call it mobile device. Just a terminology change. And we made a bit of a mess of the 3 GP P references because we are not very familiar with them so we had some outside help from people with more experience and we cleaned that up so that part is consistent now as well.
So, that was just a quick overview of those changes. Now, the most difficult one, and this is the one I want to pay a bit more attention to. The RFCs have changed a bit in regard to IPsec. It used to be mandatory for everything, but at some point there were devices that had limited resources or were known that they would only ever need to support a limited set of applications, so the RFCs changed from a must to a should, which is still a strong recommendation, you need good reasons to leave it out, but for us it caused the confusion, should we then still make it mandatory? So, one was must, we say it's mandatory, but now it is a should, it's not ?? word optional gives the wrong feeling, it's still very strongly recommended but not mandatory any more.
So, what do we do?
It's optional but it's not ?? it's not really optional but it's not really mandatory. So, we put it in the optional section of the document, but we added some extra text that said every organisation that uses this template, because RIPE?501 or its successor is a template for you to use, you don't have to copy and paste it exactly and send it out like that, so people who think that in their situation they need IPsec or they might require IPsec in the future, can still move it up to mandatory and, remember, it's a template, so before using it, think about all the things you want.
This goes of course, for all the stuff that is in optional. Some organisations it might be mandatory for some organisations, so ?? what we didn't feel it was appropriate any more to put it in the mandatory section by default. There were a lot of discussions about this, some people feel very strongly about it and I think this is the best compromise we could do. But we would like some feedback on that.
So, where are we now? The latest and hopefully last version is sent to the mailing list. It's going to be published. And what we want to know now is is this document good enough to be published as a RIPE document? We realise it will never be finished, there will always be new requirements and new developments, I mean, so I would ?? our recommendation is to accept the current version as it is. We think it's a really good document, so unless there are strong objections we would like to go to last call but we will appreciate your feedback on that.
And with that, I want to give it back to Marco.
MARCO HOGEWONING: Can you push up my slides again. As Sander said, a bit of procedural comment here. We have been using these words "review" and "last call". Be clear: This is BCP and not sub to the policy development process so although we use the same terminology, we don't have to follow the same procedure. Basically to phrase it like Rob said is every Working Group thinks this is a good idea, we will publish it, if there is consensus and support. So, our basic questions, us, as you the Working Group chairs, and as Sander stated as well is: Where do we go from here? We can probably go to another cycle and another cycle and another cycle, because sooner or later somewhere some RFC will be updated and somebody doesn't agree to it. So we can go over another review cycle and can ask for comments on the mailing list, edit it, push it out again. We can issue a last call and see what happens. I believe the authors really want this to push forward. Feedback from my ?? what I got in the field is also that people would like us to push forward because we see RIPE?501 reference more and more, Tahar showed it, Erika didn't really mention it but it's also listed in the Swedish document as a suggested profile so in that sense, the sooner we get the replacement out, the sooner it's being used.
Where do we take it from here? And I see Rob now standing at the microphone with probably a valuable comment.
ROB BLOKZIJL: I don't know, it's for you to judge. But I would strongly recommend to publish it next week and start a review cycle that runs until the next RIPE meeting.
MARCO HOGEWONING: That is the other approach, indeed we can just publish it and give it a number and ?? feedback is that if we update it too many times, then a lot of people that use this document or reference this document, have no clue of what this community is doing. If we go over too many numbers, then we might lose them because they lose track of what is what.
ROB BLOKZIJL: That is why I say judging about half a year's time whether there is enough material republish it. But as you said yourself, this is a typical example of a document that will never be in its final stage, and I think there is enough valuable material in it to publish it again.
MARCO HOGEWONING: Duly noted. One other addition I would like to make is bear in mind that this is not ?? as an operator you can always refer to it, if you start buying stuff you can use this document, point to it or steal stuff for your tender. Be aware that when reviewing this, there is a fairly likely chance you get confronted with this from the demand side. Some of your customers might use this and some of your customers might push this via the sales channel into your desk, Hi, we want to buy this when you are compliant. So keep that in mind when commenting or reviewing that. It might not be you buying the equipment, it might be people buying services or equipment from you that required this document.
With that, I would say, I open the floor, if there are any comments or questions for the authors, questions about the procedure.
JAN ZORZ: I think all the authors are strongly agree with Rob.
MARCO HOGEWONING: And then it was silent. Does the lack of comment mean that like Rob said, just push it out, we will clean up the text a bit because that is why it's not published yet, need to go over the nitty?gritty details, dots and commas and get it out as soon as possible.
DAVID FREEDMAN: If nobody is going to comment I would suggest that we get it out as soon as possible and let people comment on the text. I think trying to ?? leaving it off?line and trying to make it picture perfect is probably not preferable to having people see it and be able to ?? and feel that they can be able to comment on it now.
JAN ZORZ: David, I would like to thank you for all your time you spent with us during IETF and changing the organisation to organisation, from American to proper British English.
DAVID FREEDMAN: You are welcome.
MARCO HOGEWONING: So the question ??
AUDIENCE SPEAKER: I think we should publish it as soon as possible. Many people ?? many people feel that this document is unfinished if it does not get the real number from the RIPE so make it useable by finishing it and by publishing it. If we need another number in one year it's fine, I don't think it's any problem if we put references in the document that it's deprecated that you get a new one so please give it a number.
MARCO HOGEWONING: I guess Tahar?
TAHAR SCHAA: I agree totally on this because in our project we want to reference into the new one and we are confused should we take the old one or not finished new one so please publish.
JAN ZORZ: I take the new one as very stable one now.
SANDER STEFFANN: I think we have consensus on giving it a number.
MARCO HOGEWONING: Not everybody is in the room, not everybody is currently involved in this, so what we will push out is one final warning that unless somebody raises his voice in that sense, issue a last call, raises his voice within the next five working days we will ask the RIPE NCC to go ahead and publish this as soon as possible, give it a new number and then the one remaining thing is we will probably include really big warning on the old document stating it's deprecated and please use the new one.
JAN ZORZ: I have another question. Do this community want us and you to work further on this and to keep it updated or we stop here and have a beer?
MARCO HOGEWONING: It's actually a good question, should we set up like a monitoring task force that keeps an eye out for changes that are relevant to this document that, as Rob suggested come back in six months' time, we have seen this and this changes and we are going to push out the new one, or we don't?
JAN ZORZ: We all need the help we can get so please be more active, OK?
SANDER STEFFANN: I think if people want something changed in the document they will speak up on the mailing list.
MARCO HOGEWONING: Feel free to ignore it of course, that is the main thing. It's optional document, it's not the law. And again we are finishing slightly ahead of schedule. We will proceed then as David suggested, we are going to ask one more time to the mailing list whether everybody agrees and basically we are going to push the button on it. Thank you all for your time. A big thank you to the authors and everybody behind the scenes who spent late nights in bars trying to fix this and comment on this. It is a good document, got a lot of feedback on it also from the field and from other conferences, so let's push ahead. Thank you.
Which, before you all run?out, I am not sure whether Filiz is still here and want to make her comment about the programme committee elections once more.
FILIZ YILMAZ: Still the same. The page is up?to?date now, everybody is there and the photos are there and bios are there, there are eight great people so have a look, please, and vote tomorrow.
MARCO HOGEWONING: Thank you all for being here. I guess you don't have any on?line comments, Philip? Thank you for attending. See you all back in Amsterdam, RIPE 65. I have lost the dates. Keep the comments coming on the mailing list, IPv6?WG [at] ripe [dot] net for all your IPv6 related topics. Thank you.