These are unedited transcripts and may contain errors.
Plenary session on September 25, 2012, at 9 a.m.:
CHAIR: Good morning. Our next speaker is Paul from Infoblox he is going to be talking about SLAACer prisoner of state.
PAUL EBERSMAN: Most of you folks here are probably doing things with static routing and routers and stuff at fairly low levels, and you don't on a day?to?day have to support some of the higher level stuff, but it is coming, your customers are going to be dealing with it and you need to have some idea of what the issues are and there are a few things relating to it that you may need to do services for your customers.
So, starting with the how things had worked, with IPv4, you pretty much had two choices: You either statically configured the interface on whatever host or router you were on, or you could choose to use DHCP and that was how everything worked and you had choices of actual useable address space, public routable address space or in then cases of course, we are now using large chunks of 1918 private space, and though it's not really a type of address in V 26 seems to be classed that way, we have anycast. It's essentially a silly little routing trick we all used but it is frequently classed as an address type. All of those are known and familiar to us. With IPv6 of course, the IETF gave us a wealth of choices for better or worse. We can still statically configure, though typos and other little issues do come in with the addresses that are so much longer. The biggest new change is the stateless auto configuration where the host can get information from its local subnet about the world around it and configure itself, and then you have DHCP which is very similar to IPv4, there were some design changes and some things like it's not Boot P with other stuff stuffed on top of it, it was actually designed so there are some improvements.
And then as far as address types, there is unicast which is what we are used to in v4 you have a single sender going to a single recipient, one of the things I think is a significant improvement, we do not have broadcast any more. What we have instead is multicast and, thank you, IETF, for reusing a term for something similar but not the same, it is not the multicast MPLS or leaf?and?flooding, it is a single sender to multiple recipients where based on function, you can subscribe and say, I provide this service or I am interested in messages of this type, and with multicast when I send it out, only those people have to listen. And actual improvement on the subnet a little less overhead, and there is still the anycast, which is again simply just a routing trick.
Now, SLAAC, stateless auto configuration, uses what are called RA or router advertisement messages. What that means is that instead of statically configuring which is local to the machine that you are doing or DHCP where you are usually being back hauled via relays to some central DHCP server, the routing entity closest to you actually gives you the information about how to get out on the network. So what has happened is, instead of having a centralised policy that many enterprises are used to where the DHCP servers give you all of your network and security policy, we have actually pushed it to the point where you have to go to the edges, and one of the reasons this affects us is that in a DHCP world, it's very common that the server group configures and supports all of the workstations and all of the servers and does DHCP, and the networking guys do the routers and sometimes the firewalls, and they are not necessarily the same group. And that can function, you can actually work that way in v4. In v6, the networking and the systems groups have to work together in order for everybody to get a useable experience.
So, very quickly, what happens is when I come up as a client on the local network, the first thing I do is I generate a unique host ID, I then put that on to FE80, create a link local address which is my address that I use only on that subnet. And then I go and see if anybody else is using that, I say, hey, is anybody else using this address? If no one else answers, I know that it's unique and I go ahead. If somebody else responds I go, oh OK, sorry, do a little random twiddling, try again. At that point I have the right most 64 bits of my address known unique on my network.
What that now means is that I can then go off and try and get other addresses that allow me to get out beyond that single wire, that virtual broadcast domain. And what I do is, I send out a router solicitation, multicast message that goes only to all of the routers on that subnet. And all of the routers then respond, and what they do is they give me a router advertisement which tells me what prefixes are available, whether I am allowed to construct my own addresses or whether I am going to use DHCP, unlike v4 where you can configure on the host to use DHCP the network tells you in v6. Again, one of those things where suddenly the network is affecting what is going to happen on your host.
One of the things in that advertisement is the A flag or the auto configuration flag. If that is on, what that tells me is I can take same host idea I used for my link local address, slim it on to whatever prefixes I am given and do duplicate address detection, which might be global unicast address, one of the other forms of IP 6 address.
One of the other things you get are the default route. Including preference. So, one of the things potentially we can get rid of are all of the HSRP, VRRP and various other means we have of not running an active protocol or and we can control it from our routers and the people who run our back bones and configure our our routers are probably the ones can make the best decision about what can he fault routes and what relative desirability there is of using those. Maybe one of your providers has highest cost or maybe use a different peer. The flag says get an actual IP address from your DHCP server and then the 0 flag other configuration, says all of the other stuff that we normally get in DHCP, antiP servers, resurf sieve DNS, FDP, TFDP, all of the stuff for our phones, everything we use going through, and it gives an MTU, how big is the pipe.
Now, there are some things that unfortunately are not in our RA messages. One of the things for quite a while was you couldn't get a resurftive serve which meant you could get up on the income and could you get a default route and get out on the Internet, but you couldn't do any DNS lookups. That is now in the RA messages. Unfortunately, it doesn't get as much support on the client side, so you can't assume that everybody who comes up on your network will be able to take that RDNS in the RA message and use it correctly unless you can control every host that goes on there and you know it's there. And you don't get all of that other configuration that we tend to bundle into the DHCP that we have used for years so you don't get N TP servers, literally all you get do I use DHCP or not? Do I get a default route? What is the size of the pipe upstream for me?
DHCP can give you public useable addresses, it can give you the privacy or temporary addresses that are a new feature in v6 and all of the other things that you would normally expect, your N TP server, RDNS, all of the vendor optings to make our cable boxes work, all of the doc sys stuff that we have bundled, but big change: You can't get the default route. So, we have got tone this place where you can't really do RA only because not all the clients get a DNS server, and you can't do other configuration. And you can't not have DHCP or you can't do it only because you don't get a default route that way and you won't DHCP until you are told to by an RA. So, what we have now is a reality is, it's not really a choice between SLAAC and DHCP. You are going to be running both in almost any network that you have.
So, decisions: How do you figure out which one are appropriate for you? People are doing DHCP, are the ones who want to do filtering, walled gardens, figure out who is on their network before in theory they give them an address, though of course bad guys can self configure and inanother your instructions. People who have IP address management systems which certainly with v6 is going to be even more useful automating, you have so many more addresses to keep track of, instead of 256 on a single subnet of a common size, you have 18 quintillion, 4 billion times 4 billion potential addresses. It's quite common that people who do centralised management in DHCP will have the DHCP server dot forward and reverse in DNS rather than allowing every client to scribble in your zone files directly and if you are not a peer window shop that is probably a good decision.
It does mean that you are looking at relays just like in v4 and it does mean that the client doesn't get all of its information from the local subnet so you have to plan for that if you have a wide area network. It does allow for much more complex configurations, this is where, again, phones, printers, cable modems, all sorts of other things where the vendors have decided that the easy way to do it is to attack that horrible set of saddle bags that we have bolted on the side of DHCP and vendor options and have it hold everything. The text blob of the networking world.
SLAAC has some distinct advantages for certain applications. It's very local, it is right on the subnet, so you are guaranteed that the first router you hit is where you get all of your information. It's very lightweight. So people who are writing stacks can write very efficient, very small code in embedded devices. It is much less complex than DHCP. It is decentralised, because you can get a useable experience as long as that subnet can get on the Internet, you don't have to get back to some central repository to get to that DHCP server. There are some things that if you don't care about them, if you don't need to log, if you don't need to have audit trails, if you don't have any kind of accounting requirements, if you don't really care about updating DNS because they are just coming and going, it's transient, you don't really care who is using that address, it doesn't really matter that you are not doing those dynamic updates and not using an IP update management system and don't care how much or exactly which addresses have been in use out of that /64, SLAAC works very well.
It's all about your priorities or your your customers' priorities and that is usually what breaks it down. If you do have to do centralised logging, if you have legal requirements, healthcare or law enforcement requirements, auditing whatever, you will probably not be as inclined to go with SLAAC; you will want the least file in all of the logging that you get from a DHCP. If you want to do centralised management of your addresses because you are one of those folks that ties the address you get to your security identity, you will probably not go there. And if you have technical support that is fairly sophisticated, you have an actual IT department, DHCP is not an issue for you, if you are a coffee house where you want the guys making coffee not playing with your router, no DNS at all and SLAAC makes a lot of sense. You don't really care nor do you usually have law enforcement coming in and saying who was in the coffee shop. It's quite common to say we don't know, we don't track it. Do you have to support a wide range of gear? If you do, you probably need to DHCP because that gear unfortunately will probably expect to be able to do all of those things and give all of that extra baggage to the client as part of the configuration process.
So, if you were currently using DHCPv4 and you are happy with how that works for you and v6 is not what you really want, you don't want people randomly picking their own addresses, the sort of classic formation is, what you will do is you will set that A bit off, auto config off, telling the client don't produce your own addresses, and then you put the O and the M flag on, manage address and other configuration, turn those on saying get all of your configuration and your IPv6 addresss from your DHCP servers, and then you will pretty much use the RA message to do nothing other than tell it DHCP for everything and here is the MTU for your network. And you will probably have your DHCP server doing your forward and your reverse. And we will talk in a moment about some of the challenges with the reverse lookups.
Now if you are doing something where it's a coffee house or might be a manufacturing where starting to talk about things like smart homes and your refrigerator might be saying you need milk or your TV is going back to the manufacturer saying we need, we have got a new update and you need to download it so you get the latest movies, whatever, you may decide that SLAAC actually is much better. You don't care what the host name of your TV is because no one will ever use T you want to small embedable system. In those cases, the RA is probably going to be saying, A flag on, i.e. auto config self. You will get other config from a DHCP server because you do probably still need to get your resurftive DNS and you may need the other vendor options to bring up, and you may choose if you think your clients can do it or you control your clients you may even have them do the RDNS in the RA messages.
And the DHCP server doesn't do any leases; it's literally just handing out here is the DNS server. So, you could have very under powered DHCP server, it just works great and that handles the people who can't do the RDNS and RA message and the odds really it is at the stage where you can power cycle your server if anything happens.
So, the last bit and this does creep up into where we usually play, it's most of you probably have to support the reverse lookups for the folks that you give your addresses to. And I will start with a little bit of the how it started. I actually go back to the days where we originally were playing around with this stuff and why we did it and we were still using I?dent?D in those days as well. One of the places where it started getting used with pointer records for actual filtering were some of the big FTP sites and we got tired of people who didn't have a clue and didn't understand how anonymous DNS worked, calling up or e?mailing us and we had this very quick thing said if you can't figure out how to put a pointer record into a zone file you probably don't deserve to get our software.
And for better or for worse, it did certainly cut down our support e?mail, and what changed, we got people, what is a RTR record and we had a form letter, here is all the stuff until you figure this out just go away. And then we started get to go this point where we were getting very tired of people with MTAs that were broken and e?mail had some interesting behaviours and somebody started doing, if we can't do a reverse pointer and it doesn't match your forward, that is a nice quick clue that these guys aren't doing things cleanly, so we won't accept any incoming SNTP connections. And it has mushroomed beyond that to it's used for VPNs and security tokens and all sorts of things, websites use it to decide whether you are a legitimate client and we now have this point where nobody knows how many things break if you don't do pointer records for all the addresses you have. So of course, what do we do in v4 right now? We usually pre?generate the entire range of all the addresss that we were assigned, so if I gate /24 by by some means create a file with 256 entries, by hand, if I'm really a masochist or I love VI, most of us have scripts or will use magic lying buy and sell or generate or we have an IP management system which will automatically reassign it, will shovel things into a file, we have a little script, things go off, and magically it all works. OK, fine. Well that works with 256 hosts. Most of the time we are now recommending that a 64 is the correct size of subnet for an actual local broadcast domain. That is 4 billion times 4 billion addresses. Well... and because there are 32 nibbles or 4 bit chunks in a single IPv6 address and IP 6.arpa, every label is a nibble and it's 34 labels and you can't just autofill those, you have to actually fill it out or use magic within your zone file, so we are talking about 50 to 60 bytes of data.
There is no way that any of us have machines or RAM that can hold those kinds of zones. So what are we left with? My personal favourite would be I would love to say let's admit it's a bad idea and get rid of all of it. Unfortunately we can't because we don't know it will break. Pre?populate is not an option unless we figure out to exceed the speed of light, it doesn't physically work with our gear. We can pre?populate for certain areas where we don't use a lot of space, but realistically, the two choices we are going to have your DHCP server does it only for the addresses in use, or none of the servers do it now but people will say make my DNS server lie and just give the point of record, and that is what we are left with.
So, questions?
AUDIENCE SPEAKER: My name is Ilijitsh van Bejnum. What about dynamic DNS, the clients just talk to the DNS server?
PAUL EBERSMAN: The issue is that many places for security reasons won't do it. And some clients do, Linux, DH client scripts don't always do the right things where you have to hack it. It depends on your environment, for more purely Microsoft and Mac where you are dealing with the Mac idiosyncrasies it works.
AUDIENCE SPEAKER: You should really put it on your slide. One thing I was missing, what is your call to action? What is it you are trying to tell us we should do in the future?
PAUL EBERSMAN: Essentially this is for ?? as I said, I don't expect most of the folks here are going to have end user but we are going to have clients who are going to be asking us because in theory it's a network issue and so we need to be able to give them guidance what are the issues they need to figure out so they can make a good decision.
AUDIENCE SPEAKER: In the IETF people asking, we want to get rid of this insane, stateless auto configuration, because it's anarchy there is no oversight and we don't like that. This is not the way the Internet should work. They want to run the Internet the same way as ?? but I will spare you all the counter arguments why this is bad.
PAUL EBERSMAN: Where the blood has been spilled over that particular feature request.
AUDIENCE SPEAKER: I want to warn you people, don't think that making IPv6 like IPv4 is easy and problem?free.
PAUL EBERSMAN: No, and the if you set the A bit to 0 and O and M bit to one and you feed them a default route that is as close as you will get to a v4 experience.
LORENZO COLITTI: One thing that I would like to see in the slides when you talk about this two ways of doing things problem, one thing that the stateless auto conf gives you that you don't in v4 is that it's dynamic.
PAUL EBERSMAN: Yes.
LORENZO COLITTI: And so this is not obvious to people who do it for the first time, I should use DHCP, which is fine. But when you use it and you have an environment that is little bit more complicated than a coffee shop, in V4, as soon as you do that you have to run VRRP, because you have got two default gateways and one of them went down. Something that might not be obvious to somebody deploying this in v6 is that you don't have to use VRRP if you use RAs, because you just send out the two and the host can pick which one is working. Maybe if you want to put a bullet saying that the RA configuration has ?? can have the advantage of being dynamic in the sense that DHCP IS a promise that can never be broken unless the lease expires.
PAUL EBERSMAN: You get that both, the same resilience. Unfortunately, this I didn't have as much time, part of cut out in 15 minutes, is exactly that of the ?? I love the fact that we can actually give without running OSPF or RIP or something hideous on your hosts, we can have useable, multiple default routes that the network can tell us because it has pretty good clue and that is definitely one of the improvements. Thank you.
AUDIENCE SPEAKER: I have a question from a remote participant, from Elliott Leer: Doesn't this beg for a problematic algorithmic approach and doesn't that already exist in some versions of same server software?
PAUL EBERSMAN: I am assuming is there an algorithm being approached for line, and actually I didn't get as much chance. One of the issues with lying about your pointer records is that is probably what most people are going to want, until they stop and think about the fact that if they have to do DNSSEC, they don't get to lie because that is exactly what it is designed to not let you do. So yes, there will be algorithmic approaches because people won't just want a wild card. I have heard multiple different reasons or ways that I think they would like to lie. And I think that the users are going to have to say this is what we need and we will wind up writing code to do just that.
AUDIENCE SPEAKER: Andrew Sullivan. I hear a lot of spooky worries about Reverse tree, particularly with respect to end points, laptops and that kind of thing but what is it that people are doing with that? I understand in the case of servers and so on if we told people it's OK, don't bother what is going to break? I always hear we don't know what is going to break. If you don't know, maybe nothing is going to break.
PAUL EBERSMAN: I would actually rather it went away and we saw if there was something there. I am aware of VPN and certain other software and websites that do indeed check it. It's pointless but they are doing it and people don't want to get the support calls when their customers scream why can't I get to this website.
AUDIENCE SPEAKER:
JIM REID: I think some of the problems about provisioning for Reverse?DNS for v6 are overstated. In my opinion, obviously this is a religious issue for a lot of folks, the things that need to have PTR records important things like the box that is Sunday mail to the outside world where you might find things you are sending doing checks that you mentioned, where one server does that itself, if you don't have a PTR record, you don't get in. Now, for a case of a client who is just doing stateless auto configure, you can automatically have, use a dynamic update client software on their box you will be automatically able to provision a PTR and a AAAA record for your host without having any fancy authentication tokens, this authoritative for the two domains and updated policy to allow that. So it's not that bad if there is a requirement for end host like a laptop or something like that, there needs to have a name for itself with reverse entry in the DNS it can be done without a lot of hassle and you don't have to provision huge numbers of essentially place holder PTR records. And at the same time that is also work with secure DNS because the name server potentially can sign those zones on the fly as well.
PAUL EBERSMAN: If you don't have security reasons why you are not allowing client updates and you don't have to deal with a lot of non?PC and non?Mcyou can certainly do it with the client.
AUDIENCE SPEAKER: To answer Andrew, I have been running IPv6 on a server free BTSB box and on my host at home for nine years and I think seven out of those were without any Reverse?DNS on the server and I think at home still without Reverse?DNS because of these temporary addresses, so the only thing I know for sure that breaks in this environment is the mail server, so if my serve goes out to another mail serve and says I have a message, there are a few out there that say I don't want to talk to you and that will solve by adding the Reverse?DNS. Other than that, I have no examples of anything that breaks. And also in the serve logs I see about ?? I see tonnes of IPv6 addresses, so tonnes of people don't have reverse address in IPv6.
CHAIR: Thank you.
PAUL EBERSMAN: Thank you very much.
(Applause)
CHAIR: Our next presenter is Stefan Plug from AMS?IX. Can you come up to the stage, please.
STEFAN PLUG: Hi, first of all good morning from me. I am here to present you an interesting RFC. RFC 5549 about BGP with IPv6 next hop and this is a possible solution to the problem AMS?IX is probably going to have in a few years, which is the problem about IPv4 depletion.
First, I will talk to you a little bit about the problem itself, being no more IPv4, then about some other possible solutions, and then the RFC itself.
So first a little bit about AMS?IX, you probably already know this but just a quick remainder. AMS?IX is basically nothing more than one big switch, it's one big broadcast domain and currently we are use ago /22 gives us a 1,024 addresses, this sounds like a lot but it isn't that much. User data from the last few years shows that we are actually growing, that is not a surprise of course, but we are actually growing with used IPv4 addresses we use, so currently we already use 657, that was two weeks ago, leaving us only 367 more IPv4 addresses.
You can see the slope increases in over there on the graph and actually when we zoom in on the growth itself, it actually gets quite more, the growth. We can see that in 2010 it just started like growing exponentially right there. This probably has to do with the AMS?IX started its reseller programme there and reseller programme allows ours directly corrected clients, members, to actually re?sell a connection to their own clients making it possible for their own clients to directly connect to AMS?IX which is a very good thing of course, but the bad ?? a very bad thing in perspective to this presentation because those clients, those sub clients also need an IPv4 address.
So, probably this year we are going to grow with another 75 IPv4 addresses.
So when we look at the future of the IPv4 usage as AMS?IX we can see probably if we predict around 100 addresses each year then we won't have any more IPv4 addresses at around 2016.
Now, this was actually quite a good guess at the beginning of this year but we have new data from two weeks of course, and that is probably more of 75, then still we are going to run out in 2017. Which is quite close by, of course.
So, what is the solution to this? Of course, I also have to say that when this happened and AMS?IX won't of course die but simply new members cannot join in which is something we want because we want to grow. So possible solutions to this problem:
Well the most obvious one of course is just a bigger subnet, right? You get a /21 right there and you will have 2000 IP addresses and you are done for another ten years probably. Now, ten years sounds like a lot of time but maybe some of you will be retired but I probably won't be, at least I don't hope so, it is just, it's not really a solution; it's really just work around and in ten years we have to tackle this problem yet again with even less IP addresses available and of course, right now it's already very difficult to get that /21, of course.
Yeah, a bigger IPv4 broadcast domain also has another issue. We have a big broadcast domain /22 and it gives us a lot of broadcast problems. We already use so?called Arp sponge, sponging away a lot of the Arp broadcast messages. Without it some older members could actually fall down and just lose their connection, which is not a good thing. And bigger subnet would just increase that problem. But this is actually a very good close term solution, just not very original one and this was a graduation project so we wanted lass little bit more original and more long?term solution.
So, another solution could be just to use private IPv4 for addresses of course. The problem here being can you not really use the same internal IPv4 space on the AMS?IX network because you probably will have problems with members using the same IPv4 private address range and the router wouldn't know where to forward that problem.
Now, it would just say it's just one or two members and you can renumber them. Well, no, because we have over 500 members so it would be quite a hassle and if we were to use, like the range 172 /16, maybe member A says you cannot do that because we use that and we will say, yeah OK you are very important, so we are going to the next range and use the ten /8, and member B will say can you not do that because we use that, and you see where this is going.
So that is not a very good solution, either. Can't we just use IPv6 instead of IPv4 at all? So let's say about the following scenario: Router A over there has IPv4 network, 1985100 network and it tells its peering router to each this IPv4 network just send your traffic to our next?hop address 2001.1. Now, if this was possible, then we wouldn't need to use IPv4 at all on our network, we could just use IPv6 with the added benefit with the broadcasts because the Neighbour Discovery protocol uses a lot less CPU cycles. There was a research by the University ofAmsterdam saying if we go to IPv6 then we woudn't need to use the Arp sponge any more.
So yeah, this in theory looks like a very good solution of course, but how can you do this, send an IPv4 packet to IPv6 next?hop address? Well, one of the first things you might think of is a 4in6 tunnel, encapsulate your IPV4 packet with IPv6 header and send it along. Now, when you actually look at the normal kind of 4 and 6 tunnel it is not possible. It wouldn't even solve our problem really, because a normal tunnel it begins with an IPv4 address and it terminates at IPv4 address, making, yeah, not a solution because would you still need the IPv4 address right there. So if we were to eliminate the middle router over there we would still need the IPv4 addresses to actually build the tunnel, solving nothing really because we still need it.
There is another kind of tunnel though called software mesh tunnel, described in RFC 5565, and which the RFC I am going to talk about actually is in the same Working Group as this one so they recommend this. And this term ?? this kind of tunnel doesn't terminate at an IP address but in the router itself and they call that router an address family border router, and this basically is just dual stack router who can on the one side there is an IPv4 address and on the other interface an IPv6 address and it's smart enough to know I have to send this to IPv6, just encapsulate it with IPv6 address on there and send it on along.
This is a very good solution, we are still researching if this is going to work at AMS?IX itself. The problem, if you can call it that, is we have to encapsulate every IPv4 packet with a 40 bytes IPv6 header of course. Now, this sounds a lot if you think about all the traffic that goes along but actually 40 bytes out of 1,500 is 2% or something extra over that which might or might not be a lot.
So, the question is, isn't there another way to just send it out along, because if you go back to basics, to just forwarding IP packets and forwarding frames, you see that you actually do not need a next?hop IP address. Why do you need it? You don't. You actually only need the next?hop Layer 2 address. What happens here is really basics of forwarding, the computer A wants to send a packet, an IPv4 packet to its destination. Computer B over there. And the first thing it does is create that IPv4 packet with the destination with the computer B. It isn't done yet, of course. It needs also a frame for the next?hop, so it looks into its routing table and looks up what the next hop is going to be. It's 192 O21. It knows its Mac address via Arp and sends it on along. Router A over there, receives that frame it, knows that frame is for him, it says Mac address, it looks at the packet itself and it sees it's not for him actually, it's for the next destination. So what looks up in its own routing table, it sees to reach the 198.51.100 network, it needs to sent it to the next hop, IPv6 in this case, 200.1.2. It goes, OK, I can do that, but instead of looking in my Arp table just look into my Neighbour Discovery table and sees it needs to go to Mac RSBB0, it's still an IPv4 packet, just encapsulate that with your next hop Mac address and send it out along. Router B decapsulates the Layer 2 frame, it knows that it is an IPv4 packet, it can just handle that because it's dual stack, and it sees it does the normal routing lookup and sends it out along. So actually for next hop in the case of AMS?IX because it's only next hop and we are pretty sure it's going to be dual stack we do not need to encapsulate anything right there so could send it out along. There is no encapslation no overhead and everything would just work merrily along.
So forwarding shouldn't be too big a problem. We can look at the RFC which doesn't talk about forwarding itself, it only talks about the advertisement of the IPv6 next hop route.
It does advise you to use the Softwire tunnel but that is also probably because it's in the same Working Group at the IETF.
Very important to note, the last presentation I did I actually thought I wrote it. No, I didn't write it. These are the guys who wrote it, and it's called: Advertising IPv4 network layer reachability information with IPv6 next hop IP address.
So basically what this does is pretty easy, this is actually entirely what it does in pseudocode. So when we receive an MB BGP update message look at the reach and, every MP BGP update does that, but if the update identifier equals IPv4, then look at the length of next?hop address to determine if this actually is an IPv4 next hop address or if this is going to be an IPV6 next hop address. Now, IPv4 address of course is only 4 bytes so if the length of next hop equals 4 bytes then it's just a normal update and we can just do all regular stuff but if the length of next?hop equals 16 or 32 bytes and one IPv6 address equals 16 bytes then we know that at least one or two IPv6 addresses are going to be in the next?hop address. So why could it also be 32 then? Well we could also send our link local address along which is quite normal in IPv6 routing there.
Yeah, this really easy, this RFC. An example, MP reach NLRI would be like this. The subsequent address family identifier is unicast, one, and this combination shows that the NLRI, or the next?hop, or the destination network itself is going to be an IPv4 Unicast network. But the next?hop length is going to be 32 and indicating at least two IPv6 addresses, and indeed the next?hop address is going to be our own IPv6 address and our link local address. Now we create add proof of concept for this and the update looks like this in wire shark. It looks very complicated but it isn't. When we begin at the beginning we can see it is MP reach NLRI with 14. The address family identifier equals one at the top there. Then the subsequent family identifier equals one, Unicast, and the next equals 32 bytes, indicating that there are going to be two IPv6 addresses in there. Now, you have a lot of gobbledygook over there which actually wire shark doesn't know thousand handle this but it contains two IPv6 addresses and when you look at the bytes itself you can actually see right here it's going to be 2001, 00 FE80 our link local address is actually in the update itself so actually, there are two IPv6 updates in there. And the last portion we see the network layer reachability information, the destination network is just regular IPv4 network right there.
So this is an entire RFC 5549 update in Wireshark right there.
So, this is the actual working part of the RFC. Nothing more, really. But we also have BGP capability advertisements, and BGP capabilities are being sent over a long when a peerage is being set up, and they tell each other what they can do and can't do. This RFC states when you see a capability code of five it means extended next?hop encoding which says we can do this and also with the following options that we can actually send updates with them an OSPF of one and a reOSPF of one, Unicast and IPv6, and the proof of concept this would look like this, again Wireshark doesn't know this but we can see in the bytes that we have a capability unknown capability of five, with a code of five and length of six and the bytes itself are 0001, 01 and O2, being IPv4 Unicast with a next?hop, IPv6.
There are also other combinations possible between AF I and OSPF, for us only the 112 combination is of relevance but could you also of course do other nice things. The RFC talks about ?? with the subsequent address family identifier Unicast multicast, also to include MPLS label and also MPLS label VPN address but for us only really the Unicast is of importance.
So, to conclude: The pros of this RFC would be that IXPs wouldn't need any IPv4 address any more at all so this would also of course solve the old Arp floating problem we encounter.
Some cons of course: The forwarding might be complicated but it isn't that really. Also, a real con there are no real implementations yet, aside from the proof of concept of course, as far as we know. So if anybody in this room knows about this, then please contact me and I would like to see that.
Also, a very big con is that AMS?IX itself cannot implement this. This is something our members need to actually deploy. We cannot say to our clients, yeah, you have to do this; we can only suggest that they do this because if they don't we will be stuck in four years and we cannot grow any more and we really would like to grow, it's also in the best interests of the members ourself, bigger Internet Exchange means more peering possibilities, means bigger and happier Internet.
So yeah, this concludes this presentation and so any questions, comments or brilliant suggestion, brilliant solutions, on the way to make this happen, please mail us or say it.
AUDIENCE SPEAKER: Aaron Hughes. Curious about one of your initial objections relating to 1918 space, it seems surprise to go me that anybody would be injecting peering connecting interface into their IGP to begin with and likely case you would have an exact match on a peering router that was in conflict with IGP is fairly unlikely. In fact, probably so much that you could very easily use any old arbitrary 1918 space and expect they are segment the next?hop to the look back address and the problem simply goes away.
SPEAKER: My colleague who helped very much in this project is much more knowledgeable on this subject.
ARIEN VIJN: The issue is we don't tell people how to run their networks and we do see RFC 1918 Arp on our platform, we see people use these, it just happens. We have to deal with 500?plus networks. I am looking for in telling you have to run your network like this or if you have run your network like that.
MR. HUGHES: That is not entirely true. The reality is we put our ports in a state of quarantine and validate we are not sending junk across the switch. Operational ?? we do set operational standards. I am just saying this seems a bit frankly overcomplicated for resolving a problem that, you know, I think we can deal with as a community. I think it's perfectly fine solution, don't get me wrong. I am just suggesting the community could probably handle a single 1918 prefix at a fixed length that is connected interface on one router.
ARIEN VIJN: As I said, dealing with 500 different cultures, 500 different ?? networks, is quite a different game than dealing with your own network. We do see it, we put people in ?? when they connect, once they are in production, things change as well. I know that RFC 1918 is being used inside people's networks. I know that I advertisement the prefix into their IGP, some people even announce it on BGP and that happens, and I am not looking forward chasing people around, not to use some RFC 1918, I am not looking forward into B M and LAR for RFC 1918 and it will be more Internet Exchanges that are starting to use RFC 1918 space. It's meant as another space somewhere in private networks and not in a public network that connects many, many different networks. It's more like an administration issue or support issue than a technical issue, that is true.
LORENZO COLITTI: There is something ingeniously twisted about this that I like. Things that came up quick discussion with my colleague, trace route might be a little bit confusing because right now you get the interface on the other end and tomorrow you will get maybe the loop back or something else, some other random interface on the box. It might be an issue operationally to see for operations say OK that is v6 peering, it's probably carrying v6 traffic, all my v4 traffic went away as well but that can be overcome, I think. The question I had, really, is: Supposing that a customer did want to do this, is there anything that is not ready from the perspective, can somebody say dull or vendor please implement this.
STEFAN PLUG: I think it can, the direct forwarding one, they are not to my knowledge, that is an actual RFC for that but the Softwire one there is an RFC on the standard strike I showed you, it's in the Softwire Working Group so yeah there are RFCs to do this.
Lorenzo: Do you ?? one thing that might be useful to aid implementation of this is if somebody were to write a very brief IETF document saying here is how you might do it in the case of direct forwarding and then it comes easier to say hey, please implement this, and then a customer can more lease easily communicate to the vendor exactly what needs to be implemented.
STEFAN PLUG: Definitely, so we are thinking about writing that document.
Lorenzo: Should probably attack it to v6 Ops or something like that.
STEFAN PLUG: Thank you for the suggestion.
ARIEN VIJN: This we did implement the direct forwarding thing in a proof of concept using Quagga. Plug it's a very easy solution but you have to keep in mind it only works when the next?hop is a dual stack, we are still searching for options when the next?hop is a dual stack if, the next is going to be IPv6 then the direct forwarding is not going to work so we really need to be absolutely sure that the next?hop is going to be dual stack. I think right now, that is always the case on the AMS?IX case, but yeah, why is that the case? I have an inherent thought that it must be, but you might actually have a thing that might be the direct router connected to AMS?IX itself might be only IPv6, it does only IPv6 routing, and and we make a connection to the router behind that, it's a very strange concept, you know, but it might be possible.
Lorenzo: So sure you can fix that by saying don't announce v4 routes if you are not willing to accept v4 packets.
STEFAN PLUG: That is very good idea, we cannot say to your members you shouldn't do that, but yeah, we could also do that, sure.
AUDIENCE SPEAKER: I have a question from Toré Anderson from Redpill Linpro: Did you consider using the IPv4 link local range 16925400 /16.
STEFAN PLUG: We had an entire discussion with ARIN and me over that, it's an ongoing debate, actually. It has been a while back but my argument was that, what was my argument? It was actually, it was an entire discussion but it was over half a year ago, though. Arien, maybe you remember.
ARIEN VIJN: We can use that. The problem is again trace route, but because can you not really ping that anywhere else. Our entire discussion was because we implemented the direct forwarding solution using some kind of internal hack by using internal data structures, IPv4 are the best range. My idea was to use the local link addresses for that and Steffann's idea was to use the experimental range addresses for that, that was the whole discussion.
STEFAN PLUG: It was about the translation table. Yeah, that is an entire different presentation, though. So ??
ARIEN VIJN: I remember that in local link IPv6 addresses there was a BGP draft for that, to use that in BGP and it has never been ?? never became an RFC. I can't remember really the reasons for that. But it seems also tricky to use local link addresses on the Internet Exchange.
STEFAN PLUG: We might have to look at it again, though.
AUDIENCE SPEAKER: It seems to me ??
GEOFF HUSTON: You can generalise this because in iBGP, the NLRI is simply the encoding of the exhibit point, how to get rid of the packet, and this idea that the address you are looking up and the encoding of the exit point needs to be in the same protocol family, is just some kind of historical hangup, it doesn't need to be like that. And what you can do is basically encode the NLRIs in v4 or v6 or anything you like, including deck knit for all anyone cares, it's not conjoined and you can do this hack, which is basically doing 4 over 6, you can just as easily do it the other way or bring back Apple talk.
STEFAN PLUG: Exactly. And this RFC only states about the IPv6 but it does of course introduce the capability code, code 5, and this RFC only states you can use IPv4 but there is no reason why not to do. Again, the only thing we need actually to forward something is to Layer 2 address, so all the IP addresses above that is only a label. So we don't actually need that.
CHAIR: Thank you, Steffann.
(Applause)
CHAIR: Rick from OpenFortress is our next presenter.
RICK VAN REIN: If I had it my way, we would switch to IPv6 tomorrow like this, but I probably won't have it my way. Well, we all have our reasons to want it and my reason to want this is for SIP telephony. One of the still being closed and logged down in the world is telephony and SIP has the power to change this in, combination with NAT is a disaster, what I would very much like to do is use SIP over IPv6 and only IPv6. I have done a lot of research to see if this is possible and with a few simple tools you can get very far but you always have the problem of I want to buy a phone and plug it into a network, it should run SIP over IPv6 however this customer has got an ISP which hasn't got a clue about IPv6. What you end up doing then is starting to look into tunneling, and I have investigated just about all the tunnels I could find and much to my surprise, none of them is out a suitability for this usage profile, is capable of specifically of two things I have put up here, zero configuration, just plug and play and peer to peer communication, it's generally not possible.
So, even though I know there have been six or seven tunnel proposals already, I am standing here proposing yet another one in the hope that it serves this particular application and top of my surprise, I find people everywhere saying, hey, wow, this is very simple, this is keep it simple stupid approach and at the same time it's generally very useful so that is why I am presenting it here today.
And specifically a preview of how I do the peer to peer thing, I don't make a model of what NAT route you have, because you are quite likely to do there. This 6bed4 tunnel is simply try to if you can communicate to remote port directly. If you can't it will use backup port somewhere in a network.
Now, I will go through the proposal, through the tunnel proposal by looking at requirements and telling how they are implemented with 6 bed 4, I am going to rely on to you understand the existing protocols to see what goes wrong or doesn't in others. I have a slide comparing the things where you won't be surprised to hear the 6bed4 is the only one can thank can implement all requirements.
The first one is a very important one, this is the it's a big one it called 6 to 4, anything you build that has to do ?? any tunnel protocol that you build should be able to peer through NAT. The solution is just as simple as the problem statement, it's just doing it over UDP and IPv4. So that is fairly straightforward, nothing new here.
Of course, we want to have an open and simple protocol, that is always the best thing to have. And one of the problems you run into when you start tunnel is you can start shipping off packets, you need to know your own IPv6 address and how do you get that? To use your own protocol, I have seen XML fragments being exchanged, asking for remote address, could you look into DHCPv6, I just learned that it doesn't give you routing address, I wasn't aware of that. It's very complicated in general for a tunnel. You can use SLAAC and that is actually quite simple, just send a router advertisement to an address that you know to be a tunnel severer and what you get back is a router solicitation, it tells you what IPv6 prefix it, I am adding a standard IC P 6 option that tells you what IPv4 address and what you have on the outside and you are ready to go, you can configure IPv6 address locally and start sending traffic. Very straightforward, very simple.
Now, another thing you want to do with tunnel is of course to avoid abuse. Now, that is very simple, how do you do that? You make sure that your IPv6 address matches with IPv4 and UDP information before you toss out the layers. There are a few ways of doing that of course, within an ISP you can have all sort of control mechanisms that will work but I want anyone to talk to anyone, of course. So, what you see with global systems is very often that they are based on accounts, but accounts mean configuration, they mean an extra hurdle for end users to get on to IPv6 to be able to do telephony, that is going to confuse people, I just want something that plugs in and works. So with ?? what I am doing with 6to4, is simply embedding IP4 address in UDP port inside the IPv6 address, it's very easy to check and you can very easily route your traffic after that. It's all very simple, really.
The requirements: Zero configuration is to sooth simple consumers of course. If they don't have to configure anything, it's very simple for them to use. It's a desire, not a requirement, it would be very nice to have that, it's not a strict technical requirement but please do it if possible. The option or requirement that falls out of this is you can just configure a well?known server address because that is the only one we still need to know, where is my tunnel server and I am account are for now on well?known address and hard coding that into a phone.
Now, a tunnel server is a router basically, it may couple networks but it's a router so you want it to be stateless in order to avoid exploding data. As I said, IPv4 address and UDP port are embedded in IPv6 address so it's very, very simple, to be able to route back traffic, but just taking the address and ports out of the IPv6 address, putting into your destination for the lower layers and just pass it on. Once again, it's very straightforward.
Now come the interesting parts. You want this to scale. And if you want to have a tunnel server somewhere centrally on the Internet where the rest of the world can route calls and general traffic through you might have a scaling problem. Now, imagine that I were to send to you 6 bit 4 to send a packet to server so off server that receives a packet on a native IPv6 interface, it sees that it was sent from 6bed4 address and wants to ship back to 6bed4 address. It could do that by once again going through the tunnel server but very often because it was sent out over UDP by the client that originated the sending, very often the UDP port will be open so you could send it directly. Now, doing that with your data packet is probably going to ?? is not going to give reliable performance so you want to do something else instead to make sure that you can use the port. Once again, the IPv6 protocol stack gives a good solution which is neighbour discovery. Ask are are you there? And it will answer, yes, I am there if you the UDP port is open. By that time, you are certain that you can pass traffic back and forth to that UDP port so the server trying to send a reply is certain that it can directly pass the traffic through, and any UDP will get through because that router is not aware of what goes on inside UDP so that is a fair assumption.
So what you end up with is direct communication between end point which is exactly what you desire for SIP telephony because your intermediate network between you and your remote partner can actually be connected peer to peer and the only thing that determines the call quality is the between you and your calling partner.
How does 6bed4 relate to the IPv6 stack? Of course you do not want to tinker with it, do not touch something as pristine and beautiful, you run it on top of 6bed4 and basically in terms of Linux implementation you would have a tunnel interface face what goes on behind that interface.
Interestingly, to the IPv6 stack there are link layer addresses tied to each of the interfaces, and also to the peers that it talks to directly. If you take a /64 that can be recognised as the 6bed4 address range, and you want to route something to 6bed4 remote and you would automatically go through that interface, you would automatically trigger Neighbour Discovery and automatically get back link local address if that remote is available through that interface. And what that means is you can use the neighbour cache and all its timing and retrying and this actually benefits the entire protocol because the retries will be so often that NAT is kept open as long as you are communicating to remote partner.
So actually doing it this way is very, very easy to do it, very much alliance with the rest of the IPv6 stack and the tunnel hardly has to do a thing.
Now, I spoke about well?known address for a tunnel server and that is always an itchy topic because I am saying we need an anycast topic because otherwise we can't scale. Even if the server has to do little more than handing out routeless stations still you want to have redundancy and be able to pass it around. Now, we have acquired a few addresses that are suitable for anycast, the second someone experimental, the IPv6 range, we have got it for a year to experiment with. We currently have one node actually running this stuff, and we are very keen on finding other people to join into this network in order to be able to experiment with this anycast and the related problems. A few problems we have already heard people mention and I think we can answer to them: First of all, people often say when you use anycast, especially for the return address, you can't control your return route. That is definitely valid argument.
It has been tested in relation to 6 to 4 however, by Geoff Huston, he tried if that was the cause of 6 to 4 problems and he test it had out by trying to run on the server that he was using for the test, he implemented return route and he didn't notice any difference or hardly any difference between quality of set?up of connections, so it's safe to assume that this is not a big problem in reality. And of course, if you are an ISP, and you would say I am going to support 6bed4 to do it locally, would you just do it en route, you would just have something in your own network as local to the customer as possible, perhaps, perhaps even inside your router that would do this translation and it's perfectly safe because you know the traffic is going to return through that same route, and it's perfectly safe to use your own IPv6 address on the ?? your own IPv6 range on the exterior side. The only thing you need, really, is the well?known address, which is an IPv4 address to be able to address this 6bed4 service.
If you were to do this in the wider Internet, you might get connection breakdowns if routing changes from one implementation to another implementation node.
Another thing I have heard about anycast complaints is that it's very hard to monitor anycast services, and that is definitely true, but I think mostly it can be solved by having not just anycast addresses up on your server, but also having locally routing addresses, you pass traffic to the local addresses, it comes out the other end, you can see if it does come out and if it does, the same programme is apparently working for the local addresses as well as for your 6bed4 addresses which is used for anycast, there shouldn't be an enormous problem there. Please talk to me if I am overlooking things. I am not by nature a router guy, I might be missing things here very much.
Then, the cause of anycast services uncontrollable is something you sometimes hear people mumbling, published over BGP I would point to that for a solution. You decide who routes ?? who can route through your services, use BGP to that end.
Now, a bit of context: Because this is just what I have done, but what have others done? These are the tunnels that I have looked into, in comparison, and I have put down all the goals above the middle line are the strict requirements and below are the designs. As you can see, 6bed4 implements all of them. 6 to 4 comes pretty close, the protocols actually very close to 6 to 4 except for the one red cross that is actually killed it because that is what Geoff Huston found to be the big problem with 6 to 4. I am sure I will be corrected if I am quoting him wrong.
This is work in progress. I have written an Internet draft, it's in second version, expired last week but I thought I would get a chance of getting you guys feedback before getting a third version. There is the first public note run the serve net, getting support from NL net in form of founding, so there is people who really believe in this. Serve net is working ?? surf net has port this to Android so you can have IPv6 anywhere on your mobile because it's really that simple, I have tried it so many places it just works. We will be testing anycast performance and other issues next year. Please, once again, your input is very kindly appreciated. And that ?? white paper by surf net which compares all the ?? all the pros and cons, in more objective way than I could every do. It will attack 6bed4 into account, though.
Now, in conclusions:
Specifically for the application I have looked at, SIP RTP introduces new requirements, it serves end users and is a service. The peer to peer nature to get the best out of Internet connectivity possible. These requirements are actually generally useful for a tunnel. I think we should seriously look into them for any tunnel proposal that we consider.
And the existing tunnels turn out to leave ?? some of those requirements unfulfilled and for now, 6bed4 appears to be, from my perspective, but once again, prove me wrong if I am, resolve these identified requirements and as far as I am concerned, 6bed4 is so simple, it's such an easy thing to install, you don't have to configure everything, we have the infrastructure in place, basic infrastructure, I think we are ready to serve the masses with IPv6.
That is a bald statement, I know, and I am sure there is going to be responses. If there are any questions, please...
AUDIENCE SPEAKER: I am Lars Liman from Netnod. I just want to caution you a bit about oversimplifying monitoring of anycast. The fact that, well going through the path announcing Unicast as well and trusting what you see of Unicast, it's simply not true because when do you it you have clashes of routes and reverse path forwarding checks and stuff that kind of ties into this that makes it much more complicated than you first think. I have the scars.
RICK VAN REIN: OK, I would like to see those scars, perhaps we could meet up later.
AUDIENCE SPEAKER: I am happy to hand them over to you. Any time.
RICK VAN REIN: Thank you.
AUDIENCE SPEAKER: Lorenzo Colitti: You are creating a hybrid between Teredo and 6 to 4. What you are trying to do is risky. I can think of long ?? a lot of things that might not work. Off the top of my head, a few things: So Neighbour Discovery, you are saying that it, what you propose does not requirement modifications to the stack. Neighbour Discovery isn't really designed to do what you are trying to do. It has scaling limitations, because it's designed to handle on link neighbours, and that is in the order of a few thousands, and so if you try do this on Linux, you will hit those limits, so it's also very tightly coupled to the link layer because it has to deal with link local addresses and things like that, so it's not going to be as easy as you think to just build a new link layer and have it working at least in Linux.
Second thing: It seems to me, I am not sure, but your 6bed4 IPv6 address depends on the IP v4 address and UDP port that you use to talk to the server which may not be that IPv4 address and a port that you use to talk to the peer. Because you can't depend on anything; it's a NAT, all bets are off so you could be bedded to ?? one peering port and in another case to another peering port, so the peer, how long does a peer wait before sending you a packet through the server? It sends you a packet, it didn't get there, what is it going to do?
And the third thing is, 6 to 4 depended on the kindness of strangers and that didn't work so well.
RICK VAN REIN: It depends on?
LORENZO COLITTI: : The kindness of strangers. For example, some of the performance issues with 6 to 4 are due to intermediate relays being rate limiting your packets, you're dropping 50% of them because they are out of bandwidth, and this is another challenge you will have to consider because the serve path will be used in these difficult cases.
RICK VAN REIN: Let's see... Your first issue was the sizing of the neighbour cache. This is definitely an issue for a server. It's much less an issue for a client. And the point is well taken on the server, thank you for that. This is very much intended towards peer to peer communication where everyone is a client so it's less of a concern there but what you are saying there limits the possibilities of the tunnel and it makes it less general. That is a very good point.
Your second point is your external addresses can change while switching communication channels, this is what happens with symmetric nodes and this is why the protocol tries to contact you on the UDP port and was bounced through the tunnel initially. It tries to get there using just plain Neighbour Discovery and if advertisement comes back, apparently it works; if it doesn't, you go back to the tunnel. You are asking how long does it attack before you start sending things through the tunnel? That is actually an implementation choice, if you are impatient because you think the traffic is realtime and your co?deck requires to you hit a sample rate whatever, you can already do that while you are in neighbourless station process, that is an implementation choice. I will agree, however, that it's application?dependent implication choice and it's a bit hairy to put that into interface.
AUDIENCE SPEAKER: Erik Klein: On your comparison of tunnels slide, you marked 6to4, I think, as symmetric. Symmetry. What does it mean there, 6to4?
RICK VAN REIN: Oh, gosh, I made these slides last week and a lot has happened. Yes, of course, symmetry, yeah, it's very short because there was so little space, symmetry indicates that sending and receiving, whether you send to the tunnel or get something back, it always looks the same. And this is, for example, where S turn looks different, it's not ??
AUDIENCE SPEAKER: It looks the same. I don't quite understand what you mean there.
RICK VAN REIN: The packet format is the same.
AUDIENCE SPEAKER: So one thing that is maybe not covered by any one of these things, is that the routing is very, very asymmetric, right?
RICK VAN REIN: Mm?hmm.
AUDIENCE SPEAKER: It was a big problem in 6to4 as well, right? . The path from client to server is not necessarily the same or even remotely close, as the path from the server back to the client.
RICK VAN REIN: I have read something else Geoff Huston story he is nodding behind you, he is going to make a remark about that. You had a you had a if you have any roughly symmetric ideas for routing in terms of 6bed4 and how that would work.
RICK VAN REIN: What you can always do is assume that you will ?? always be routed to the same 6bed4 tunnel serve through anycast mechanism, you can pick an IP address for that purpose, a non?anycast IP address, I mean, and that tunnel serve can have external IP address that is externally routable and then traffic comes back.
AUDIENCE SPEAKER: Then it looks more like 6RD with UDP in the middle.
RICK VAN REIN: With the exception it could be a public service.
AUDIENCE SPEAKER: I mean, so one of the other things, there is no guarantee of any actual performance characteristic of this, right?
RICK VAN REIN: Yes, welcome on the Internet. Sorry.
GEOFF HUSTON: I would just like to make a couple of observations, and that slide is a good thing to put up. We do a lot of measurement around failure rates where the connection doesn't work. Teredo's failure rate, as far as we can measure, is around 4 out of every 10 connection attempts fail and the reason why it's so shocking is that trying to set up three party rendezvous, which is what Teredo is trying to do to get symmetry through the NAT, is really difficult when every NAT is different and you are driving UDP. 6to4 also has a pretty lousy failure rate, it varies between 10 and 15 percent of connections fail but that reasons more obvious, it's because its encapsulation is in protocol 41 and a huge number of firewalls, 10 to 15% don't like protocol 41. The lesson that we have learned is that there is only one application that actually works through these tunnels, and that is bit torrent, and the reason why bit torrent works is a massively redundant architecture use, there are gazillions of servers and points where the data is replicate sod if one fails you are not lost. I think it's a lesson that anyone trying to design these kinds of tunneling rendezvouses and I would put 6bed4 in the same family, you will succeed if you make the thing massively redundant, which is actually not anycast; it's a huge number of Unicast and there is rapid fire approach of just try everything you possibly can and if one comes back ring the bells and say it's success. Because any other approach you are going to get failure rates that are annoyingly high and simply make the whole thing an exercise in frustration, so that is the only advice I can give you from what we have seen in 6to4 in Teredo.
RICK VAN REIN: The reason for having a tunnel server as a fall?back is exactly this: You are going to bounce into not routers that are not going to work and you have to fall back to that at some point. You reminded me of a question he was also asking but you asked so many that I may have missed a bit. And that is, if you are going to fail at some point you have just lost a connection and that is not true because at some point you are going to retry your Neighbour Discovery, actually both sides are going to try, and one side might fail and the other might succeed because one is symmetric and the other is not and at the later point you can still renegotiate that connection and get back to the 6bed4 performance that you were hoping to get. If not you still have to fall back to the tunnel server.
GEOFF HUSTON: Send out 30 requests to 30 servers, whichever one comes back, go with it. Thinking serially is what got 6to4 and Teredo into the mire that it got into? And there is ?? we have learned one lesson: There is a huge number of things out there; parallelism seems to work.
RICK VAN REIN: Please... Are ?? I am asking questions so probably you need to get back to the mic, if you would. Are you saying that trying many things is not going to be an option for peer to peer contact? You are talking about finding a tunnel server, right? Or are you talking about the anycast address versus having a long list of fixed IP addresses or fixed locations?
GEOFF HUSTON: In 6to4 the single anycast addresses has been problemical. If you had a large dictionary of address that has got circulated, you would find 6to4 would be so ever slightly better because the anycast routing is bizarre. Exactly where these things exist is entirely non?deterministic relative to a single client.
RICK VAN REIN: It sounds like in the beginning of this year I should read up on your blog and read interesting things.
GEOFF HUSTON: The closet Teredo server that I could find in Australia happened to be located about one kilometre from here on precisely the other side of the world. Anycast routing is weird.
RICK VAN REIN: You are welcome to use that router. Thank you.
Richard Barns: This discussion reminded me of ICE, you know, the SIV community developed this protocol that tries its best to find something that will for sure work between these two peers and exchange lots of candidates and do lots of negotiation to try out a whole bunch of different combinations to get between two points via two NATs of arbitrary character. So, I wonder, this thing in a lot of ways is very simplified version of ICE for negotiating a particular type of UDP stream, and if you are going to go to all that trouble, I don't know why you add IPv6 at intermediate layer for SIP. Otherwise you wouldn't just do RTP over that stream so that, you know, adding IPv6 and UDP as two intermediate layers.
RICK VAN REIN: The reason for putting IPv6 in there that is where you want to go in the long run and you have got the best performance interaction and network stack. Otherwise I do agree, ICE is a very interesting solution. The problem with that is a security problem. You are going to claim external ports that may or may not be yours as a process to own. I mean, with many processes and in the future, even many people behind NAT router, as in carry great NAT, you might end up claiming somebody else's port. That is the reason why I am very cautious about this. But you are definitely right, ICE does very interesting things. Yeah.
LORENZO COLITTI: I think what people are telling you is a lot of this has been tried before and it's never worked so far. Now, that doesn't mean it won't work this time but it's the Internet, right? That any sort of failure that you could possibly imagine and stuff that should be impossible, happens all the time. So, you know, I mean, good luck and so one thing that I would please, you know, I would really hope that would you do is if you get standardisation and if you do, do you measurements of reliability, remember that we got stuck as an industry over a 0.05% failure rate, OK? You need to be very, very, very reliable to use this in normal operation. So if you do get standardisation, please make sure that this is not preferred compared to native v6 or 6 RD or stuff that is managed and by ISPs, please make sure this is not preferred, OK? If you just design a new link layer, things like Linux will say v6 address, I am going to prefer that and then we are back to 2010, so please don't do that.
Erik: That was my comment as well. One of the work we learned was the importance of being able to debref these kind of things, because for non?latency sensitive applications who don't care using this all the time is probably fine but for everything else that makes money on the Internet the stuff really sucks.
RICK VAN REIN: I am aiming for 100 percent hit rate of course, and remarks about anycast are very well noted. Thank you.
CHAIR: Thank you.
(Applause)
We are almost done, but not fully done. We looked at the feedback that we got yesterday, that wasn't that much; it was actually very, very low, and we are trying to think of ways to make the feedback much easier, in fact feedback is very, very important to us because it helps us know how to improve and how we did in the past but helps us improve the future talks, so, if anybody has any suggestions how to make the feedback much easier, my idea instead of web forums or drop down box, make it demand line, I think it would make it much easier for this group. NCC is suggesting that I do a memo for you to make sure that it's very easy for everybody.
So it's RIPE 65.ripe.net. I can't see the log in box, actually. It is very complicated, we will go back to the command line. So, see here on the right, just click on "sign in", I already have a sign in, it's very easy to do and really quick. But it's blue on the "OK". Then you just quick on this right here and you select the rating. I am going to keep my ratings private, I don't want everybody to see mine, click on those and that is pretty much it. For example, I will give it 10 here and that is it. And you might win a prize but honestly, I mean, I would do it for the community, right? We want to improve this, so thank you very much, and see you back at 11:00. Thank you. And thank you to all the speakers today.
(Applause)
(Coffee break)
