Title : Ipv6 Connectivity No Network Access
link : Ipv6 Connectivity No Network Access
Ipv6 Connectivity No Network Access
>> van de velde: so this section is broadly aboutthe state of ipv6 internet and brokenness and things like that. actually, i'm wearingtwo hats but the main hat that i'm wearing today actually is the, you know, i'm the chairalso of the belgian ipv6 council. so just like, you know, we saw yesterday in one ofthose flash talks. also in belgium, the ipv6
Ipv6 Connectivity No Network Access, form has been reinvented again and we're tryingto, you know, get some things done hopefully. hopefully in about the year, two years timeactually promote, be needed anymore. actually, i have even doubts right now. it could betoo late and, you know, the use could be very, you know, minimal actually, so still thinkingabout those things. so what i'm going to speak
about is so reflect, i'm going to be tryingto set the scenery for the next three slides actually which will come, you know, in therest of this particular section. so the next things are going to be like measurement forv6, you know, in different environments. we're going to speak about the brokenness of ipv6.i'm also going to speak about white listing. and some of these things actually have a cause,you know, by the non-managed tunnels. and the reflection i want to go to, you know,the key message of this slide where actually is, you know, is, are these tunnels actuallythe future of the internet? can we actually live on the internet with the use of non-managedtunnels? so, by the way, you know, just to wake everybody up again also because we havelike 95 male population here, i put the face
of angelina jolie here. so, hopefully it willdraw some attention to happy eyeballs to the slides, huh? so, it's competent, you know.it's competent. so now some of these things also tend to be a little bit controversial.so what i've done, i've created this particular slide here, which will help people to jumpup and down on their seats when they see everything here. so, i have like this switch-on likehighly controversial, medium controversial, whatever that means, and not really controversial.so i have very little green points here. so i hope i will really satisfy your 15 minutesactually. so how these things carved up? so first before i start speaking about some ofthe artifacts of non-managed tunnels, i would like to give you an understanding of whatis a managed tunnel. and once you understand
that, it's much easy to actually explain whatis a managed tunnel and everything else, i can see that it's actually is a non-managedtunnel. the next thing is also, so some people actually are happy with what these non-managedtunnels things do. so i'm going to give you some reflections from different angles comingfrom, you know, the user case, the enterprise case and from a service provider case. thena little bit of philosophy, this one of my, probably, one of my red things like what isthe goal of the internet and how do these non-managed tunnels fit into it followed by,you know, some of these negative properties of non-managed tunnels. and what you willsee also is i will try to gauge sometimes. actually, i will try to give a balance overview,which actually means i will tell some good
things about non-managed tunnels and i havethe unfortunate look lorenzo is sitting very closely, actually mike strike out and i willtell some negative things about non-managed tunnels. and i'm, we're going to conclude,basically, i will let you actually draw the conclusion of, you know, some of the contenti've been telling you about. so basically what is a managed tunnel? now, a managed tunnelactually is what i consider a thing for which you can contact somebody. you know, somebodyhas set it up for you. you have, like, an agreed sla level agreements, it works perfectly.and the way actually it works is just as your current ipv4 native connectivity works. itshould actually even be working, you know, as good almost as your native ipv6 connectivityif you would have it. now, of course, if you
would native ipv6, you probably wouldn't needthis kind of tunnels. it also means, you know, that you actually have like, you know, a reliableset of security performance and integrity parameters attached to the tunnel itself.and also the administration of realm actually is, you know, is something you can actuallycontact. somebody you trust, somebody, you know, you pay for for delivering this particularkind of service. and, so basically, what i'm trying to say is like anything which doesn'tfall into these categories, i actually, you know, account as a non-managed tunnel; so,some tunnel experiences. so, when i speak, you know, to people and you know, and i tellthem like, "yes, 6to4 is maybe not the best thing to do." now the often answer i couldget back is like, "yeah, but it works really,
really well for me, you know, that's no problems.it's my only way to go to the internet." that maybe true, you know, even like, you know,10 or 20 or 100 users or so, you know, technologists, but imagine if you've like one million ofthem, you know, there could be a potential issue there. other comments are here is like,"oh, i didn't know i was using ipv6." that's funny. good that you tell me but i don't reallycare so much. then also the enterprise view is another thing. so when you're looking to6to4 than often, you know, what people say is like, "yes, 6to4 gives me like, you know,a very asymmetric traffic pots and perverse traffic, you know, direction is the one thatwords. now, that is actually true in some cases but not in all of them because sometimesactually, you know, 6to4, for example, can
follow uv for traffic pots with the networkif you go from a 6to4 site to another 6to4 site. only on the certain circumstances thatactually have the potential of asymmetric traffic pots. and now for the service provider,so what do i hear there actually often say about these non-managed tunnels. so some ofthem, you know, some of the good service providers they actually care about their customers andwhat they do is they want to give the internet experience, you know, the best possible angle.so what they actually do is they actually provide 6to4 relation in the network and theyeither make it available for everybody over the whole world or it just will restrict itto their own customer-based. now, one of these elements there, of course, is, you know, thatwill cost money and the question is, you know,
how much money is the service provider willingto invest to help other non-customers basically. so, that's always a question, you know, they'rethinking about. and then the other thing about these non-managed tunnels, you know, whati hear from content service providers is like, yeah, whatever. you know, but what i do seeon the internet is like, you know, with these tunnels, i see like, you know, a measurabledifference in my, you know, round trip time and in the quality i get from these guys.and as a result, you know, i cannot really enable all my v6 content right now just yet.and as a result, you know, they will have to use into different measurement, you know,different techniques and enabling v6 for the community actually, you know, in a differentkind of a way. put more enough light onwards.
so, the way i see actually, you know, howthese things fall into the internet actually as such. so the internet when it is growing,it should actually be a platform, you know, which can grow beyond what it is right now.it should be a services platform. it should--so it should be a services platform actuallyand it should be providing a simple control playing for end-to-end connectivity. and theidea should also be that, you know, all man, all machine should be able to connect to theinternet. now, the question is here, you know, do non-managed tunnels actually follow thisfundamental? that's a big question. and especially going up further, the one we just probablygoing to break it the most is, you know, the v6 internet connectivity should be as goodor better as the perceived quality of the
v4 internet. and right now, that is not thecase and i believe we will see some measurements like onwards but that actually is not thecase. so now, going further on the question why people actually, initially, invented non-managedtunnels and the main thing is actually, you know, in the beginning we're early adopters.everybody is connecting to ipv4. some people actually wanted to have ipv6 connectivityand then these tunnels a bit perfectly. at the same time it also provided, for example,a de-coupling between the infrastructure readiness for ipv6 and the application readiness ofipv6. so by using these tunnels, the application is good potentially experience some of v6connectivity there. then, of course, you also have like now if you implement ipv6 in aninfrastructure, if you want to do it in control
steps then these tunnels actually might helpalso a little better. now going further to the properties. so one of the first things,what we often see with non-managed tunnels, they think they use well-known ip addresses.now, an artifact of that is that it creates actually lots of potential asymmetric tunnels.and now the same thing actually--good potentially be happening with ipv4. but with ipv6, withnon-managed tunnels, the probability for that is actually much higher. and so i put likea little drawing in there, for example, you see on the bottom. so, you know, the laptopwith the routers, you know, it probably will select, you know, for the well-known tunnelor relay or something. the first router on the tab there and then the other one willtake the router on the other side of the slide
here. another thing is performance. so thereis like a series de-coupling of what the guy using the tunnel actually expects from thetunnel and the guy delivering the elements to create a tunnel, here is no direct correlationbetween them. and one of the questions you can actually ask yourself is like, you know,do you actually want to provide or manage service of the internet over unmanaged infrastructureelement? so, that's a question you have to think about. so, a nomad element is also like,you know--if it suddenly stop working perfectly, correct, then how does the end-user, actually,how can they complain to the guy providing the relay-router, for example, that is notworking correctly. you know, how does a guy actually even know who's the relay-router--whoowns that particular relay-router. i've just
been flagged that i have one more minute so...>> [indistinct] >> van de velde: okay. so just two more slides,and this is a great one actually. so one of the things also is the realm of control, sowhat is very important here is that a non-managed tunnel actually goes from the artifact thatyou actually use third-party involvement to actually create, you know, your ipv6 productivity.and the same thing is actually also happening, you know, in the [indistinct] of course, ifyou send the packet from one end to the other end of the internet, but that is just forwardingtraffic. in this case, you actually use third-party middleware which is a complete different equation,yeah? and the whole new set of parameters and variables which actually are in, you know--justtake into accounts. that results actually,
you know, in things like, you know, sub-optimalflows, if your middleware is not working perfectly correct, which will increase your round triptime and packet loss. if you have a low performance like relay-router, the whole thing could bescrewed up actually because you experience suddenly, you know, with this tunnel of worseexperience--much worse experience than you actually are seeing with ipv4. and then theother question is like, you know, who's going to be responsible for this degrade of, youknow, service you actually are getting of the internet. then a few words about security,so as we have seen also earlier, doing things in tunnels creates problems. so it createsissues with firewalls. it creates issues for de-packet inspection. there is like a particulardraft also, like you know, the tunnel security
concerns. and they're valid for both managedand non-managed tunnels. but the importance of the security elements actually is actuallyhigher for non-managed tunnels because you don't have control of all the different elementsplaying and generating these tunnels actually as such. and then of course, 6to4 is a specialcase, and it also has its own security considerations sections actually in--so now going to theconclusion. so what i've seen actually is that, yeah, early adopters, you know, theyhad been working very fine with non-managed tunnels, you know, in the beginning, yeah?like if you speak to tony hain, he's like super happy with his 6to4 connection. butimagine if there would be like, you know, one million tony hain. it's going to be asmall issue because both for ideas and for
many other things. so, and also for the internetin that case because they will all go to the relays and the relays will crash and burnand which may be a good thing for cisco because you will buy more of these if you want toreinvest. but that's maybe not a good way to build up the internet infrastructure. andso if you go from mainstream usage then, you know, the things what i can see actually asa result of this non-managed stability of, you know, of these tunnels is like, you know,blackholing, perverse traffic paths, you know, nobody really wants to invest in relays, youknow, hard to manage, you know, difficult security model. and the consequence what isee out of this directly is that content providers cannot just switch on ipv6 right now justyet for everybody. you just saw it earlier
with the previous talk. google also is, youknow, having some issues there with switching them on for everybody and at the same time,you know, one of the consequences also is that we are now starting to discuss all thesethings, all the complexity with white listing, you know, good citizens in the internet whoactually have proper ipv6 connectivity. so if it would be up to me, i would just, youknow, deprecate all these non-managed tunnels things going forward but that's maybe a toomuch of a high ambition but, you know, we can only try so that's what actually...>> [indistinct] >> van de velde: native connectivity, do youknow? just native. >> [indistinct]>> van de velde: yeah. so any questions.
>> [indistinct]. two points i would like tomake. the first one about 6to4, re-tunelling is asymmetric by nature and even if the serviceprovider wants to offer relay, it can offer a relay on the outbound path from the 6to4customers to the native internet. the real problem is when the packet comes back.>> van de velde: yes. >> because it has to go to somebody who isgoing to advertise 2002: : /16 essentially acting as an open relay for the entire internetand there's absolutely no way to restrict it to your own customers. so we essentiallyrely on somebody on the internet of doing free transit, and you have no way of knowingwho is going to be the one that is selected by the packet unless we don't [indistinct].and that's a really, really serious issue.
so this stuff is fine for early adopters.i'm not sure if this is a question about do we need to deprecate it or not. but it'llcreate a problem when home gateways turn this thing on by default and the customer is notaware of it. >> van de velde: yes.>> and maybe a recommendation should be "this is fine if you want to use it but don't makethis on by default." >> van de velde: yes. that is true. and ithink also next to that, the risk of degree of control element you can have, you know,you could potentially, you know, announce it in the internet like 2002, and then a setof the prefix, you know, of that particular service provider then to limit it a littlebit there. but that's maybe not very allowed,
you know. there are some procedures.>> it's against, that's said in the rfc for a really good reason because if you startthat path, you input the entire v4 routing table in v6.>> van de velde: yup. but it's a way out. >> [indistinct]>> there are possible things content providers can do too. for instance, you know, we'vefor a long time investigated trying to uncap 6to4 responses directly to users. but thatsort of [indistinct] to--but, you know, it's not totally in control on our return pathbut yes, it's quite problematic. >> van de velde: that's it. on time. thankyou. >> kisteleki: i'm robert kisteleki from theripe ncc. i lead the science group there.
and i'm actually just going to present thework of my colleague emile aben. and for those of you who don't know ripe ncc is the regionalinternet registry in the european and surround regions so just like [indistinct] around here.first of all, we would like to have more incite into the v6 deployment and how many clientsare there really using v6. and basically, most of you are interested in how this goesbut especially that's true for an rir because we are in the--we are the numbers business,so it's really important for us. it is also true that we have heard a couple of differentnumbers about how much v6 is deployed really out there. for example, if we look at ourstatistics, roughly 25% of our members have actually v6 allocations. but if you look atthe routing table, you'll see that roughly
6.1% or so of the ases actually announcedany kind of v6 prefix. we also hear different numbers between--well, today between 0.25%and 2% of web clients actually connecting over v6 to different services. so that madeus wonder, so where is the difference between the 0.25% and the 6% and 2% or 1% or whateverthat number is today? we kind of devised a method to try to make a distinction betweenthe clients themselves and the infrastructure they are using. and we were hoping that thatactually will explain some of the details. so how does that work? this is the good oldmethodology. everyone knows that. the end users connect to some participating websiteand they actually fetch some kind of a javascript or embedded code there that actually redirectsthem to some measurement network. in some
of the cases, that's actually the participatingwebsite itself but it could be a different network. that's all fine and well. most ofthe time what happens is some background image an object fetches or on v4 or v6 and on dualstacks so that you can actually check which one makes it there and which one doesn't.the other twist that we tried to put in here is to measure the provider infrastructureand a one way of doing it is to try to provide the dns queries that the users are--themselvesare actually making while doing the queries to the measurement network. so what we providehere is we built up a really small dns server as well behind this measurement and we forcethe clients to do special named object fetches and those names actually include a uniquedomain name as well for each and every request.
also the--as you can see the urls, the urlsalso contain some unique ids so that we can make a difference between different clients.so we can try different combinations of forcing the user to go through on v4, v6 and dualstack http and providing different responses on dns v4 or v6 and dual stack. so if youdraw up a matrix of what is possible to do here, you have this matrix of nine cells andactually if you really want to go for the full experience, you can do all of them butmost of the time, it's just not worth it, it's just too much. these are actually thefour measurements that we do. it's easy to understand the v4-v4. so we only take measurements thatwhere the v4-v4 actually made it through.
and then we can do that. we only provide dnsresponses over v6 but we require the client to connect to our v4 and so on and so forth.and finally, on the lower right hand, we do the dual stack-dual stack response. that actuallycovers most of the missing parts so there's not really much going to doing over line.okay. what we did was we started to measure at www.ripe.net that but ever since then,we have expanded to other sites as well. we know that there is an operator skew there.this is a technical audience, somewhat, and we also know that this is a ripe-region skewwhich is kind of intentional, so we don't really want to expand to the whole world there.we also know that not all of the clients actually use their own default dns resolver. that'sfine. some of them are using open dns. some
of them are using google. so that's okay.we also know that not all of the clients have javascript turned on. now, you can say thatthere is some relation between the clients that actually turn off javascript versus howipv6 capable they are because most of the time, those are the techy people but we canleave that with the assumptions. as long as we are aware that that might be there, it'sokay. so results. well, you cannot really see the lines there but that's--the good newshere is that you no longer have to use a microscope. it's perfectly enough to use a looking glass.so if we use the looking glass--yeah, that's good news, i believe. okay. so this is whatyou see for, again, www.ripe.net. this actually excludes the ripe-region skew's own internalinfrastructure, so we don't want to screw
the measurements there because then v6 wouldbe much higher. what you can see here--the different colored lines mean, of course, differentthings as you can see on the right-hand side. i would like to draw your attention to theblue line. that actually means clients with ipv6 capable resolver. so that's the one thatactually shows more or less the infrastructure component that the clients are using. theblue line is a v6 capability. so when the clients can actually connect to--over v6.and the red one is preference. so given the choice, they actually use v6. you can seea bump roughly in early may. that's because of the ripe meeting that we had in prague,and we provide native v6 connectivity there. so, yeah, there you go. now, if we filterout the non-managed tunnels--thank you for
the term. we--sometimes, we internally callit auto-tunneling, but it doesn't matter what you say. the picture changes differently,just a slight. if i go back and forth, you can see that they are almost exactly the same.the interesting thing here is--if you download the presentation, you can actually check itout yourself--is that the clients with v6 capable resolver line changes as well. strangebecause that means that the resolver, the dns resolvers themselves sometimes very--notvery often but very rarely--but that sometimes they do auto-tunneling as well, strange. forcomparison, this is a web log analyzers on www, again, on a longer time scale, you canactually see the peaks. those are ripe meetings as well. and, yeah, one interesting thingto see here--these are roughly the same numbers
but one interesting thing to see here is thechange of behavior roughly in march this year. and that is probably because [indistinct]changing behavior. it's 10.5, or so. ever since then, they don't prefer 6to4 anymore.okay, a different view. it's the weekend effect. you can actually see that on the weekends,the client ipv6 capability goes up. one good thing that it goes down because in the office,you might have more v6 connectivity but it turns out that--probably due to auto-tunnelingat home, more people have the capability to actually use v6. the other numbers don't reallychange. i'm not really going to go through this but some people would love this especiallyslovenians and estonians. they are really, really high above the average in terms ofv6 usage. some pockets of native v6 so we
pick some places where we can actually seemuch more native v6 than anywhere else and, of course, slovenia is on the top. that'sgood. you have a different view, and this might be interesting. so, we have seen roughly12,000 as numbers that actually had resolvers in them. roughly almost 14,000 that had webclients in them. and you can actually see the ipv6 difference is that we still havemore ases--relatively more ases with v6 capable resolvers than clients. and so, if i alsoadd the two of the numbers like that, roughly 1% of the clients actually use v6 and roughly25% of the isps have v6 allocation that you can actually make these hierarchies. with25% have v6 allocations, 4.9% have actual v6 resolvers, roughly 4% have web client--v6capable web clients and roughly 1% actually
use it. random facts that we have discovered,googlebot actually does javascript. so that was surprising at the first sight. but thenwe realized, you know, actually, that make sense. in some of the measurements, we seethat the client as is not the same as the resolver as. so we take the ip address ofthe resolver, we take the ip address of the client, and we compare whether they're onthe same as or not. this is due to google dns and open dns most of the time. we tryto draw up interesting rt graphs about this where we had blobs of ases and arrows betweenthem if they use another as for resolving stuff. and it's really, really cool to seethat there is a huge crowd. and in the middle, there's google, and the people are just pointingat it because many, many, many of the ases
are actually using google. and it's also truethat in many cases, we do see that the client v4 resolver as is not the same as the v6 resolveras, which is also kind of--but why? and that is--according to our understanding, that ismostly because of tunnel broker thing. so on v6, you end up somewhere completely differenton a v4, then it's fine. what's next? we want to keep this running especially because ofthe v4 run out and we really, really want to change--see the changes, and that wouldbe really fun. we also--there's something that's not mentioned here, is we want to introducemore precise findings so that we can actually know if there are delay differences betweenv4 and v6. but many other people are measuring that already. so it's not really in our focus.and finally, we know that www.ripe.net and
connecting--we have satellite websites arereally skewed to the techy crowd. so we really want to measure average users and we startedup a program, especially in europe, where you can just join in and you only have tohold this tiny bit of javascript that we will give you, the site statistics about your v4and v6. and that's it. i hope i'm in time. any questions? questions? okay. thank you.thank you. >> colitti: all right. so, again, these slideswere [indistinct] last minute. so this is some of the data that we've just recentlystarted collecting literally, you know, over in the last few weeks about broken this inthe internet. we have had this running for a long time and there have been several challengesto this. some on the methodology, some on
the sheer volume of data that we we're ableto collect previously. so this is more recent data than we've presented so far. but--sofirst of all, let's start to, you know, look at the problem. what is the problem? so, theproblem is that, the way this is all suppose to work. you know, it was laid down by itojunin, i think, 1998. and it's basically, you--your dual-stack application, you make a dns request,you get all--you get all the addresses that you want to connect to in order and you tryto connect to them in order, right? you take the first one that comes back. and then theidea was, well, if you have a local failure and it's fast, and you don't have any connectivity,you'll just try them, it will fail immediately, and you'll just go to the next one that works.so, and that's, you know, that's the way applications
are written because it provides a sort ofa seamless upgrade part. you know, when v6 comes available, you just start to use it.so, to that end, "getaddrinfo()" is which is deserved a function that you use in mostbrowsers use in--or applications use to look up names or ip addresses, usually returnsipv6 first. there's, you know, rfc 344 says what it actually does but if you--typically,if you have both a v4 address and a v6 address, it will return v4 first. in the applicationwith try v4, it would fall back to ip--will try ipv6, would fall back to ipv4. and so,you basically try all the v6 addresses one by one if--and when they--and if they allfail, you start trying the v4 addresses one by one. if they all fail, you give up. so,what really is the problem? how bad can this
get? so, there's various failure modes here,right? there's a host local error. if you--if your host attempts to connect to a v6 addressand has no v6 address configured, it'll fail. the kernel will give you a sort of destinationand reachable message and it'll just say, "okay", and that's essentially instant. it'sin microseconds or however fast the system call completes inet unreach, right. so, that'sno problem if the application does fall back the way it [indistinct] intended it. but someapplications, notably, java do not do this. they have the concept of an inetaddress andthe socket may only connect to one address. and if you--the canonical implementationsof java, not the android implementations do connect to only one address; and if it fails,then it fails and it gives up. so--but most
applications, you know, the exception of javaand i personally put this down on the fact that java--that java apis were designed somuch--so early on in the v6 transition that they didn't anticipate this. the good newsis that you can fairly easily find this is in java by making a connect-by-name, connectto all the addresses in sequence, although that's not compatible with other implementations,so. so, okay, so--but this case is usually easy. you'll get a nice fast failure, youknow it happened and you can try again. you could also get a network error. for example,your router could be telling you, look, i'm your default router but you can't get thatfrom here, that there's no way you can get there and the way--the canonical way to dothis really is to send on unreachables back,
right? say, no, icmp unreachable. a lot ofapplications--a lot of implementations actually completely ignore unreachables. they justsay, "okay. well, unreachable; well, i'm going to try anyway because somebody might be spoofingthe unreachable," or whatever. or so what we've seen happened in the past with networksthat have v6 addresses but no connectivity is that some element inside the network willfake rst packets and it'll say, "no, nothing here. yeah, actually i'm close port, try thenext address." so, by and large this actually works and it's a reasonably fast failure inthe sense that the time of the failure is only--the packet getting to whatever elementis spoofing your packets and then the packet coming back with the reset. i don't know.i think the people that run this network in
this room--i don't know where it's done. presumablyit's done pretty close. the important thing it's not done at service site, right. it'snot very far away. i would expect it to be less than that. so, it's reasonably fast.compared to what we're seeing--compared to the numbers you'll see in the next slides,it's, you know, golden. and so, there's also a blackholing, right, so the router couldbe advertising a default route and it could then be proceeding to blackhole the packetseither locally, because it's a bad implementation or sending them into the void or sending tosome relay that's not working or it could be blackholing anywhere in the network, right,packet lost in the core, whatever. and then there's mtu holes; typically misconfiguredfirewalls dropping icmp but mass has a presented
a whole slew of cases where this can happen.so, mass' compilation is much more comprehensive than this. but, anyway, so mtu holes are particularlybad because either you've never--a tcp never recovers, and i say that never recovers but[indistinct] corrects me, it does recover but it takes a long time because it sort ofhas to, you know, wait for various timeouts. so, anyway, so, what do os has to do in thesecases? i did some testing; i actually managed to obtain a windows laptop under the duressand try to and try to see what it does because, i mean, ultimately there are users that areusing windows. so, we need to understand what happens. so, in most cases--and i was testingbrowsers because our main motivation for making this fast is http, right. and because smtpif you get a 20-second delay failure, well,
maybe that's still okay. but if you're tryingto wait 20 seconds for google search, then it's not okay. so, for--local failures arefast, unreachables--the time it really depends on the os. if you're on windows it'll takeyou 20 seconds, and this is per aaaa record, remember. so, for every record that you try,it will take you 20 seconds. mac takes 4 seconds and linux just says, "oh, unreachable. letme try the next address," and it just, bang, it goes there. blackholing is similar, exceptlinux has a 3-minute connection timeout. so, i actually saw my--when i blackholed my routerby screwing my v6 connectivity, i saw my linux box faithfully trying to connect www.google.comfor 19 minutes before finally connecting over before. and it just stand--it just sat therespinning. so, there's a lot of--we could've--i
mean, this was from--in hindsight we could'vesort of improve that. but mtu holes again, tcp never covers, not true. it probably--iwould have thought that it would recover in the order of seconds, i don't have data onthis so this is incorrect. even if failures are fast and this--thanks again to miles forpointing this out to me--applications my have other limits; for example, ie 7 and above,it gives up completely. tries five times, it says, "well, you know, there's nobody here,move on. i don't want to waste my time." so, it fails. it just gives up. so, that's notgood, right. so in our current initial and current implementation www.google.com mayhave up to aaaa records. and this is for various details of our internal load balancing andbecause we wanted to have exactly the same
number of aaaa as we did a records becausewe want everything to look the same. well, it turns out that this is not a good ideaif you're considering a broken list. so, on a mac that means 24 second, on windows itmeans 2 minutes, and on linux it's either get some or it takes again 19 minutes. ifyou're on ie 7 and you're trying to connect it will not work. it'll just fail. it'll takea long time and it'll just give up. it'll say, "page cannot be displayed." the nicething is that if it tries again, it remembers that those three addresses failed and it goesto the other three and then it connects again. but you have to reload the page. and so, needlessto say, i mean, this is broken. we can't accept that, right. so, we are going to mitigatethis damage by publishing one aaaa record
and we haven't rolled the code that--rolledout the code to do that quite yet, but, you know, we're going to do it. that's still 20seconds, right. so, you know, would you like to wait 20 seconds when you go to google?would you like--sure the impact is over playing at http, the impact is only on the first connection.but if there's xml http request or things like that each one will be counted as a newconnection. each one will--each map tile will take 20 seconds to load. again, would youlike that? no. neither would we. okay. so, what's going on? we have some indications,some data points, some sample of things that are broken. so, typically and this is, youknow, maybe just me seeing 6to4, you know, bogeyman--bogeyman all over the place. i mean,we'll just--you know, what i've seen happened
of what had--both seen it and have first timereports of it, we'll just--we'll turn off 6to4 and go through broken relays and at bestyou'll see latency increase and--or the relay might drop your cap packets or might refuseto drop your--to route your packets if you're coming from native address. so, even if youhave native connectivity at the same time, the 6to4 relay route--the 6to4 router willimpact your connectivity and at best introduce only latency increase. routers have been knownvarious--from various vendors have been known to turn on 6to4 with private addresses, guesswhat, that won't work. it really won't. so some implementations do it anyway and thehost has no idea, right, so--oh, well, they suppose they could. there's stuff in the hostthat could be fixed as well, i mean, the host
might prefer, again, the 6to4 router or thenative router as before it--for example if the 6to4 router sends ras more frequentlyor if it sends a higher priority. for example, all right, so, we might be able to fix thisby setting ras to high in native routers but that's the only hammer we got and we probably,you know, there's nothing higher than high i think. so, we might think carefully aboutthat. host may prefer the 6to4--so this is which router i send my packet to and again,and there's another thing that the host may do, it might decide to use the 6to4 addressto send the query instead of--for example before. it probably wouldn't prefer a 6to4address over native because the rfc says, i explicitly not to do that but it might prefera 6to4 address over an ipv 4 address as a
source address, so it might prefer to use6to4 over ipv4 either if it's not using a properly rfc compliant gather informationor if it's using private addresses who uses public addresses [indistinct]. and this isa known issue in our rfc 3484, it's being fixed but the implementations that are outthere, some of them actually and notably one--notably the mac implementation, now that offer hasbeen fixed, still do this. similar consideration for teredo; teredo is an absolute nightmarefor short lived, you know, requests. there's a high setup times it might or not might work.it cycles through the various possibilities that it can have, and most implementationsdon't do this they know that teredo is to be used only for v6 only. and this is my favorite.so, please don't look at the mac addresses
and try to find out which implementation itis, i didn't have time to blur it out in the slides. but, anyway, so we have this homegateway that's sending out a router advertisement that's obviously of the prefix 0000/64. nowthat is just beautiful to me. so it's sending out a null prefix, the host is accepting itsaying, "this is my ra. this is my address." so, it's forming a nice address here that'snot even a v4 compatible address, it's a broken address. it's not a unicast address becauseit's not in 2000, it's just broken. the host is happily confirming this address in itsinterface. it's trying to use it. and the router is saying, "no. you can't get it fromhere. i don't have a route." and the host is saying, "syn" and the router is saying,"nope", "syn", "nope", "syn" and then after
four times it tries, it says, "oh, well, okay.i'll try to actually, oh, let me do neighbor unreachability to figure out if that routeris actually still here." and it says, "syn" to another address, you'll note that the firstis trying to connect to kind of call 93 and then to 63. so, this took 24 seconds because,you know, each of this takes four seconds. and so--yes, so these are the problems andlater on we'll talk about how we can fix it. so, what do we do to measure them? first ofall, we don't how many there are. so--robert talked about how this type of connectivitymeasurement is done. we've done it before, others have done it before. we basically tryasked the browser connector before and into dual-stack website and see what happens. wemade a few tweaks with respect to our initial
implementation, we use long-lived websiteswhere people stay for longer periods of time so we can actually check, you know, after30 seconds or whatever, are you still here? for example, youtube or gmail, we use javascriptto make multiple measurements in one session so we can actually group these measurementsfor a single session so we know who--what a user was doing and that also allow us todo multiple measurements like add mtu checks or checks with for host with v6 only glueand so on. and we have the sentinel again after a given amount of time saying, "areyou still there?" and this is useful because if--in an a measurement, if you connect over--forexample, say, you asked to connect to dual-stack first and then use disconnect and then would'vecome in over before but you're just disconnected,
you ignore that. you can ignore that measurement,other than--instead of interpreting and it's broken. we also use one time host names becauseit sort of dynamically generated new host names because you can associate measurements,you can find out if browsers asked for aaaas and as; hopefully, you can find out if ittook them 30 seconds to resolve the aaaa if they asked in sequence and so on. and we--preventscache. we have about 10 million samples per day at the moment. it all depends on whichfrequency you want to run this experiment. only web request--wee our analysis is in theinitial phase still. before it also has non-zero failure rates, we see the 30--we see a requestafter--that's scheduled off for 30 seconds show up before the request that was scheduledimmediately. so, i just run this number, i
don't even know exactly which date it's on.this number is--but again, the number is clearly high, right, that's really still is not acceptable.it's one over out of a thousand years. and this is the whole of the internet and there'salso stuff that--before it is broken as well, so we need to factor that out but this isthe raw number. what is the affect on networks, so there's a large isp, sample large isp 0.064,this is residential isp with sort of whatever home gateway they have. 0.064% that's, youknow, if it's 10 million people that's, you know, 6,000 users, you know, that's kind ofnot acceptable still. whitelisted isp, given our current measurement models, we can't really--wedon't have a really good handle on that, we need to be able measure on one of the whitelistedwebsite. but in this case the spread with
v4 is less significant than the above. it'smuch closer to v4 and that's because whitelisting masks the brokenness, so we still have somewhatto do that. different os have different numbers for the large isp above. if you take out macwhich is a smaller but certainly not the majority of the access from this isp, you see a dramaticdrop in the level of brokenness. so, maybe this can be address in the implementations,and that's why--it's probably because mac prefers 6to4. so, how do we fix this? youcan't fix the home gateway. well, you could. in theory, you can upgrade it. users don'tupgrade it, they don't what to do, they don't know it's broken and the firmware upgradesaren't available anyway. so, that's a non starter really from my point of view. youcan't wait for them to be fixed because we
don't have time. the shelf like of these things--thelife of these things in is multiple years. so, to me that's a non-starter and this problemis not going to go away and so we need to find a fix. one thing what we can do is shipall these users to new tps, maybe that would work. we'd have to know who they were andso on. host problems; we can work around applications, for example, we could put, you know, fixesin chrome which is open source, it fixes the firefox. only microsoft can fix internet explorer.only apple can fix safari so this is a set of limited scope solution. to fix all theapplications you need on os upgrade and that will also fix your router problems. so, whatdo we do on the host side? there's dance draft of happy eyeballs. that's a general and perhapsa little more complex than we need to fix
a specific problem and it also needs to beimplemented or as shed library or inter-library application. os x from mac os x, i think appleis plan to record is to do parallel connects. that won't fix mtu holes unless it also recoversbut it'll get most of the way there. and one thing that actually igor and i were discussingat the--where was it--the itf was to have implementations probe, the networking on attachwhen you do the http, i think windows already do it. it does check for captive portals andtakes an http request, sees if it gets what it expected to get. and if it doesn't it says,"you may be behind the captive portal. click here to find out or log in to your internetand do something." so, you could do this and you could pop up--play up a little bubblethat the user is saying, "your v6 is broken.
please fix or please hold your isp or pleasedisable." because given the numbers that we have disabling v6 is a perfect solution forme. if 0.05% of users disabled v6, sure, the native users will get there, that's not aproblem. so--yeah this is one thing that i definitely see but at this--all these solutionsrequire os vendor buying in, and unfortunately they are not in this room even though we didtry to contact them. and--yeah, that's it. so, any questions?>> i have one. i think it would be highly useful if you could actually track these numbers,the brokenness number overtime. and it would be even more useful if you can publish them.>> colliti: we know. >> i know you know.>> colliti: so, first things first. we haven't
really even got off the ground. these arepreliminary numbers. i fully appreciate the value of these numbers and i think that itwould do--that it would be useful for isps to do this. it, of course, depends on, youknow, what level of application you want to publish the data for, how do you allow onlyisps to see their own numbers. you know, you certainly don't want to publish individualuser numbers for privacy so that it needs to be a balance there. but, i agree and there'salso certain of infrastructural work that needs to be done to actually get this datapublish in a reliable way and it sort of--it takes time.>> i think that we completely agree. the scary part of it is that i have seen a couple ofpresentations in the last two-two and a half
years and all of them mentioned a single numberthat you presented like three years ago in berlin or something. and--then i asked the[indistinct] and they said, "this is the amount of brokenness and we don't want to loose theseguys." and then i had the questions like, "so what's that number?" "oh, what, that'sthe number from lorenzo" "okay." >> colliti: and this is our network, right?we, you know... >> so, i completely agree that, you know,you have a big network you know your numbers but it is scary that those numbers are quotedand used and business decisions are made based on those numbers and people don't know whatthe numbers mean, they just know the numbers, that's a problem.>> colitti: well--yes. so, and--so the reason--so
we have published a paper on v6 adoption asyou may know; the reason why we didn't include these numbers and not these actual numbers,the numbers that we had earlier is because we didn't we have--we didn't have space inthe paper and we also didn't have a sort of complete faith in--no, no, sorry--so we alsodidn't have complete faith in the quality of these numbers and these builders and themethodology that we have at that time. i personally think and others may disagree that these numbersare more solid than the ones we had and we could think about publishing these. it wouldbe more useful to publish them on the web than to write them in a paper. huh? but they're--butthe point is also that there are no the numbers, right. there's thor anderson who publishesa monthly news letter of brokenness and what
he sees there. so, did i answer all your questions?of course, i mean, every--it's only fair to expect that, you know, every isp makes theirown business decisions based on their own numbers if they have them, right?>> all right. i have a two part question. number one, with the brokenness, do you haveany feeling as to what to percentages effectively inside the home versus brokenness outsidethe home? the reason is, is obviously as an isp, i'm trying to do native connectivity.what i'm just--what i was thinking about was if it's outside the home, it's possible toeffectively build your own 6to4 gateway and 3-door gateway and put a captive portal behindit. and in fact, suck in all those requests and effectively be able to tell your customershow you got broken connectivity. but if it's
inside the home, there's nothing i can doabout it. so is there--i'm just trying it like that's an interesting thing for me. cani fix it for people and tell them because i'm not content so i don't get them connectingto me so i can't see as an isp because people hate it when i look at their packets.>> colitti: yeah. so i can't--i don't have an answer for that because from our perspective,right, we're at the very end, right, it's hard to tell. if you--i mean, if you wereable to connect anonymized packets of ipv4--i'm sorry, of 6to4 coming from private sourceaddresses which will never work, right, then that would be one way.>> it occurred to me that you can do that in a sort of an almost, you know, like a voicesbc kind of way where because we know that
the--it's probably come through a nat andthe outside is being translated. you can actually guess where to send it back, too. so i'm justtrying to think is like--this is why i'm asking. is there some way of effectively, as an isp,being out to tell people they're broken? >> colitti: i don't know.>> okay. >> [indistinct]. i had like--question numberone of your slides. >> colitti: yeah.>> it looked--correct me if i'm wrong, but it looked like you're endorsing the os x solutionof actually doing kind of [indistinct], right? i would have thought like you would like really[indistinct] as google but is that your opinion or...>> colitti: so to us,i mean, if--i mean, if a user can't get to
us, that's a bigger problem than if a usersensors us and we then close the connection. i think we can work with that. so i mean,one of these is a scaling issue. the other one is an impassable problem, right? becausewe, you know, we might not like it if we get double the numbers. in fact, i haven't runany math because we can do whatever it takes, right, to, you know, to get--it's not reallyimposing any sort of either front-end server load or backend server load. really, it'sall load balance a load. we can scale to that. what we can't scale to is fixing people'shome routers because we have no access to that.>> right, but, like, does mac os--like, the last time i saw, like, mac os is actuallynot completing the connection. just kind of
like letting you like just hang there on yourside, right? >> colitti: no, i didn't think--i think itdoes--i think it resets the connection once it's done.>> okay. >> colitti: well, i would hope so. otherwise,they have to maintain state as well, right? >> last time, i saw it didn't, so.>> colitti: and would--don't they leave file descriptors? i mean...>> [indistinct] >> colitti: yeah. okay, well, yeah, that soundslike a bug. >> well, there are no bugs.>> colitti: so just curious. who else is like trying to--conducting measurement stuff likethis? any one? wow. nobody cares? see, i'll
buy each of you guys, beer.>> what are you going to do? >> colitti: i will gladly buy you guys, beerlater. great. fantastic. cheap, it'll be a cheap night for me. but, i mean, so seriously,i mean, like, anybody who runs a network here? i mean, we've talked about this in awhile.we're going to do the same--trying to do same stuff and, you know, having data availableis really important, right? i mean, this is--this is a pretty big problem. i'm kind of wonderingwhy nobody is else's. i mean, i was kind of hoping like half the room would raise theirhand. >> there are people right in this room thathave done that as well. i think nathan wood has a script that's publicly available thatyou can use to do this. you put it on your
website. and then there's tor anderson, right?>> yeah. >> colitti: there are two more people.>> there are two more people. >> [indistinct]>> colitti: yeah, but i guess that was my answer.>> tony: so, but, you know, if our network somehow, you know, turns one in--in the thousandpackets into smoke on the backbone then, you know, you're trusting our numbers [indistinct].you know, we'll trust our own numbers but, you know, your mileage may vary.>> yeah, but tony, the thing is i mean like this gentleman over here, i mean, they'relorenzo's numbers. so they're not, you know, insert company names here. i mean, you figuredthat you care enough about it, [indistinct]
generate your own information. naive i am?>> colitti: it depends where you are on the long tail of it.>> tony: you know, in fact, that was my point yesterday was that we need a common set oftools for how these measurements get made so that we don't have--you're doing a setof measurements and your numbers don't correlate with what he's doing because if you all gooff and build your own tool set to do this monitoring the numbers won't match and peopleget confused. if everybody's got a common tool suite--that was where i got up yesterday,it's like, you know, we need to think about how we come up with a common metric for howwe do this measurement and what it means because, you know, i was saying earlier. anybody thatdirectly peers with lorenzo and has control
over the endpoints, mobile carriers, right,will not see any of this brokenness. they will have absolutely zero.>> yeah? >> tony: because they're not going to be doing,you know, any of these things behind that. >> thanks, tony. now, i can sit down. thatwas my only point. >> tony: no, that in fact, that was [indistinct].it's like if he's got complete control over the endpoint and he's directly peered, he'snot going to see the brokenness that you're going to see because you don't have controlover the entire system. and so where the measurement gets made gives you completely different answersand we need consistent measurement process, not...>> this is all based on assumptions. you're
basing it on assumptions that host stackswork fine that everything in the chain works fine. just a sort of end-to-end data, whichit could be affected by--if you install--if you're a tethered machine--if you tether andyou got a firewall in your laptop that doesn't do v6, your shop is broken, so.>> tony: let's make that a goal then. >> let's make a what?>> tony: let's make ipv6 end-to-end a goal. >> it is the goal. but we have to get theresomehow. >> [indistinct]>> colitti: there's a new idea. >> we have to keep the line, so last coupleof questions, last couple of quick statements. >> colitti: okay, i'll be quick. here, here.but it's also true that we don't need 10,000
sets of measurements, right? i mean, if wehave 10 sets of measurements and they all point in the same way then perhaps there isa problem and we need to fix it, right? >> i'm not sure to i agree with that. i thinkit's valuable to have sets of measurements because the body of users hitting a givenwebsite can be different and the level of capability, the level of brokenness may bedifferent for different types of applications. i think the question [indistinct] to you,two things. first, with regards to the measurements that you detailed here, is it proprietaryenough to google that you wouldn't be willing to share that and make it publicly availableso a few more people could use it because it looks like you kind of...>> colitti: share what? the methodology or
the implementation?>> the actual implementation that this code is for something not specific to your implementationbut more specific to something that people could put on their website and use it as...>> colitti: the code is--the code is the implementation. it's--by definition specific, it's the implementation.we can share the methodology probably and i'm not the person who would need to approvesuch a thing. but we did share the methodology for measuring adoption so i don't think, youknow, personally, i don't think that would be controversial, but...>> okay. >> colitti: the--you wouldn't be able to domuch for the code i can tell you. >> well, and that's kind of where i was goingwith this. is that it may be--it may ends
up having to be an off-shoot where you havethe methodology getting implemented in a more generic code form that people--that the communitycould use. i mean you can kind of publish that as, "look, this is out on google code.go download it, go put it on your websites so you can get that information.">> i think such thing already exist, right? nathan woods took it already.>> yeah, [indistinct] and also it's the javascript where you could get it and like, you know...>> right, great, so... >> so the problem is that this is a measurementbetween two endpoints, right? and nothing in the middle can really snoop and know that,"oh, this is a measurement and i should be watching it and that's an example of brokenness.">> right.
>> we know that we didn't see this or, youknow, so... >> right. so it's sort of a web content specificthing at the moment but it's still something that could be valuable.>> sure it's definitely application specific. we're not measuring what happens with smtpor anything like that. >> the other thing i was going to bring upwas just a curiosity about your methodology. if you're looking at this on a day by dayslice, you're going to have some n number of users that are going to be broken basedon your review. are you doing anything to try and correlate between one day and another,you know, if we got the same set of broken users and they're hitting your website thesame amount of time as multiple days, you
basically have--it's a sort of skews yourpercentage because it's not actually multiple discrete broken users; it's a single discretebroken user that hits the same website every day to check his gmail and therefore, youknow, your... >> colitti: the question is then, you know,if there's a user or an ip address, right, that hits you a hundred times a day and onethat hits you one time a day, which one do you care about the most? do you care--youmight care differently or you might care the same?>> yeah, i'm not trying to necessarily say that it's one's more important than the other.i'm saying that it's a valuable point of data to have when you're looking at how brokenit actually is.
>> you're into a fuzzy area where you're talkingabout identifying users. >> yes.>> yeah, he--exactly. >> and i fully understand the ground i'm treading;i'm just making the point. >> yeah.>> okay. >> yeah. i'll be quick. i have one quick questionabout the broken dns server, is about aaaa user's record. some years ago we've seen dnsservers [indistinct] an x domain or adjust beside and doing quite bit, and have you seenthese kind of servers in your experience today? >> colitti: we don't measure for that, weonly count, we're only looking at people that trying to get to us who are asking our dnsservers.
>> yeah, i understand that.>> colitti: i've seen that, and i totally--yes, there are certain domains that do that. iremember implementing in 2000 something that [indistinct] domains preference in firefoxthat... >> right, right, yeah.>> colitti: i think you've trade was mentioned and...>> so i'm wondering with that, do you have any evidence about the improvement in thisarea but that you don't know that. >> colitti: i think it's getting better buti have no data. >> kline: my name is erick kline. i, obviously,do some ipv6 stuff for google. i was just going to talk briefly about some whitelist,potentially some--the idea i was talking about
whitelist automation but they're--or the discussionthat i'm trying to have around it except that there's not a lot of operational experiencewith it outside of our own experience per se and anyway, i'd like some feedback. andalso just to discuss sort of whitelisting practice in general and what it is, and seewhere this discussion goes. so there is sort of, you know, a fundamental difficulty. the,you know, dns resolution of aaaa is the one and only control knob, right, for v6 traffic.we add a aaaaa for youtube, v6 traffic you turn it off, it goes away, that's it. therereally, you know, for hdp there aren't any other control knobs. and, you know, rfc 3596says that, you know, the dns database has to be consistent whatever protocol you'reasking for, you have to get the answer. and
that make sense, i think, it's obviously fundamentallyrequired especially for a transition but it, you know, it does break the sort of fate-sharingthing where you can have someone asking for a aaaa who has absolutely no guarantee ofactually having v6 at all. so there's been some discussion about how to restore somesemblance of fate-sharing and there's igor bryskin's work and some other stuff aboutdisabled aaaa on v4 transported bind which you can do. the concept being to turn thaton at the first level of resolver so that, near the client so that if they don't ask,if they ask for a aaaa over v4, you just don't even resolve, you just going to pass thatup. our own wilmer van der gaast and carlo contavalli have been--and some others havebeen working on an edns extension to pass
the client ip as well so you can pass thatup through all the resolvers so that geographic load balance edns servers can receive thisinformation from resolvers that if you go through several chains of resolvers, you canstill know where the client is and try to route them to the right datacenter and thenthere's also the sort of whitelisting concept. so why whitelist when you can still get thisother fate-sharing signal because fate-sharing isn't really enough, right. that just sortof proves that you can get a 512-byte packet through and that's really a low bar for networkoperations, right. and, sadly it's this bar that some networks don't meet but it's stillnot quite good enough especially, you know, forget about not even reaching the site, whatabout people who have, you know, seconds,
minutes, worth of latency. and not all--ipv6connectivity is equal, right? with the default preference to prefer, ipv6 means that if wesee, if we're, for example, peered with so many [indistinct], we have 10 exchange pointswith them and then they don't--they dual stack one of their pairing links, well all of asudden all of the v6 traffic is going to slip over onto that one link that's not redundant.and clearly, we would rather serve them over the redundant links, right, for basic operationalnecessity. and, sometimes we've contacted to some network saying, "hey, would you liketo be whitelisted?" and they say, "no, please god, don't." and, then some sort of discussionissues but, you know, they don't necessarily want the surprise. they want to--or they'reworking on v6 and it's very tender. it's almost
like some sort of egg that needs to be saton some more before it hatches, right? if we turned on v6, [indistinct] v6 traffic.their operation staff would just be very upset and then they would turn off v6 and so, wecould actually potentially damage some network, some ipv6 deployments that are in progressby attempting to serve them v6. so if we have the idea of being that we have, to be ableto whitelist, we can, you know, we can take all of this into account more than we cando an any sort of application sense. this is, you know, from google.com/v6, you cansee sort of roughly how it is basically, you know, with one, when our dns server receivesa request, we just, i think, it's for a aaaa, we just check a whitelist. if there are resolversin the whitelist then we return aaaas, if
we actually have them. and if not, we justpretend like they're actually thinking in return no error and no results. this is sortof the process that we go through and the reason that it takes so long and all thesethings just pile up for a million bucks and i don't get to it. we receive a list of resolversor prefixes, we then have to like try to verify that, oh, this person, you know, they probablyknow who they're saying is, maybe that's somebody's work. i then take that stuff, i look at, iconvert all that to asn(s), i get all their v4 and v6 prefixes, i look at all of our routesbetween them like, you know, for example the situation where we only have--we only seethem v6 over through one connection. we'd really rather not do that. then this maybe,you know, some pmtud testing and now we have
the ability to do some more sort of per asper prefix brokenness analysis. i have to get, you know, a record in writing an email,you know, do you commit to whatever your sport and you have to exchange a lot of contactsand all that kind of stuff. and then some people really request, can we get like a reallyspecific go-live time--it's 7 a.m. in some bizarre time zone that is not specific sothat, you know, we have to be up, where we have to, you know, or something like this.and then you have to deal with an emergency rollback or revert if there's a problem. ithink we've only had one actual revert and it lasted like a day or two but, everyone.and then you have sort of, you know, iterate on all of these, right. and it's a long time,this takes a long time and there's just not
a lot of, this is obviously, doesn't scale.it was a huge amount of human effort involved here. i was thinking about how we can getaround this, and i couldn't really think of a whole lot to elevate some of the stuff becauseyou still need to perform some of this checks, but i thought, well, rather than having everybodysend in the email, why don't they just signals their readiness somehow and i'll just scrapemy logs. they can just put a magic text record on their reverse for their resolvers and,you know, for, obviously, works for v6. i'll scrape these every once in a while by lookingthrough the resolver logs and doing an offline lookups. and, actually, i have to describethis process every--anyway, so, without this, i would pick this up, it would go into thewhitelist possibly and then you could actively
monitor, we would actually do monitor as wellfor traffic dips, trouble reports and continue monitor our brokenness metrics so we can sortof debug and iterate. but, specifically, what the--like i said, [indistinct], the whitelist,there a lot of people like what it is, right, it's really just--this proposal anyway isa method to signal your readiness to receive aaaas, that's really all it is. we use reversedns for sort of some loose verification of operational ownership, if you can modify yourip6.arpa, your in-addr.arpa, we assume that probably you own it. we could use the ttlsto express desired lifetimes, operational reality may trump this, right, because therecould be millions of resolvers a day that we need to go and perform what this querieson, so now there's [indistinct] dns qps trying
to like figure out who has this text recordsand so on, or would this could be a bad idea. it's fairly simple and it involves lower communicationbut--so what is a whitelist not, by the way, just because there's a lot of stuff that youwere publishing some disposition statements. it's not a membership restricted club, youknow, this whole--this proposal is not 100% automated, it's not maintenance-free, it notnecessarily guaranteed to be handled by all providers and certainly not perfect and certainlynot a long-term solution, right. nobody really wants a deal with this sort of, for the long-term.in a long-term, we do expect to have a list with the dns server must consult. we wouldlike it to be a blacklist, right. serve aaaa to the world except for the following knownnetworks that are just really, just never
going to work. they're just bad, whateverit is. and that includes like don't ask me, answer aaaas if you receive a query over 2002/16or 2001/32, as i'm not going to answer aaaas for that, but that would be like a long-termsolution. here's sort of like the syntax, sort of that came with the expression, i couldgo over this. if it's interesting, there's a whole proposal. it's documented of ipv6whitelist.org. on the content, provider side, i log all of the resolver ips. i do this reverselookups. i process, this sort of format. there's a slightly more expressive syntaxes documented,but i didn't necessarily want to go into it, maybe operationally infeasible. i then stillhave to do some automated testing and sort of merge all this stuff into whitelist andblacklist, and so on and so forth. and i just
repeat this on a daily or weekly basis. nowthere's clearly a lot of limitations with this. it does reduce some communication inthe common case were everything is working. thank you. but, for other people to do thesame thing, implementation, stuff or process is not--it's a non-triple effort, there'sdefinitely some development here. it's possible that timeliness is not necessarily going tobe respected. if you try to use ttls and you said, "i want this only whitelisted for oneday", that would mean i have to sort of expire in the day and then re-crawl it. that mightbe more than i want to do for crawling, hundreds of thousands, or millions of resolvers. andif i do impact analysis and you aren't automatically added to the whitelist, you still have tohave some sort of personal communication to
figure out what's wrong and privacy requirementsactually hamper helping, right? if i could – if i could say please use these ip addresses,if i was even allowed to do that analysis, i certainly, probably, couldn't share that,right? so this is difficult. and there's a sort of a syntax attempt for a pair-wise opt-in,opt-out but that, again, may not be operationally feasible. that was really, really fast andpossibly incoherent. >> so can you comment, erik. is this [indistinct]proposal or is it operationally already implemented? >> kline: oh, it's a proposal. i have somecode that does this and there's one or two friends out there who've--we've put this up.actually, i think jason has done it as well. i have some code to run [indistinct] stuff.but i'm not actually running against any of
our resolver logs. that would be quite a lot.>> who, besides google's, currently doing the whitelist approach?>> kline: well, this is indeed the problem, right? this is what i said when there's nooperational experience besides ours. >> okay. so there's nobody that's joined wouldother than articles about maybe at the happening? >> kline: well, yeah. so, several of us havebeen together at various meetings. we've had discussions about it and people are interestedin it as a method to get around the brokenness, right, because you can't necessarily expressthe quality of someone's ipv6 connection through a regular dns, right? you might be able toexpress fate-sharing but you can't necessary express the quality.>> actually, wikipedia actually has a very
small whitelist for a few hosts.>> kline: who? >> wikipedia.>> kline: oh, wikipedia. >> so i'm just curious on the content providershere. who would be interested in following this type of approach? anybody? what abouton the access side? would you actually put rivers pointers in for this?>> kline: well, you don't need to worry, [indistinct]. >> oh, really?>> [indistinct] >> kline: thanks, [indistinct].>> follow up question for the room. would you do this, nobody raises their hands, wouldyou not do this, nobody raises their hands. if you wouldn't do this, if you didn't--wouldn'twant to do this, what would you do? do you
expect us to, you know, to expect to be ableto email us and have us do it? do you think that'll scale? do you have any other suggestions?i think it's clear that this problem is not going to go away, right? and it's also clearthat if we want to make progress, we have to find a compromise. so what would you liketo do? >> well, let me strengthen that a bit. soi'm the nat guy. and i wear my flame retardant suit all the time and...>> kline: i get the prefix though... >> yeah.>> kline: i get it. i get it. as long as it preserves the intent for--anyway, go ahead.>> this is--we have a choice to lesser of two evils. do we want no v6? do we want everyoneto have to beg the content providers that
i'm good enough to get a aaaa really? i'vedone my homework and we're going to lose a couple of users but, you know, i'm tryingmy best, or would something like this be okay? there's still going to be a blacklist behindsomething like this. but this may be and seems, from what i've seen, the best proposal yet.>> kline: but also, you know, to the emotional argument, it's not necessarily by whetheror not even an isp has done their homework, right? we can have fully redundant links.they're monitoring drop queues for various qs levels like ipv6 and v4, and if they'reall the same, and so and so forth, you could just be--they have a bunch of users who haveall of--broken gear, right? they have crappy--this is...>> they have their users. absolutely.
>> kline: and it's nothing they can necessarilydo about that unless they want to go and find them and replace them and fix them. so youkind of held hostage by your customer base. >> sure. sure.>> [indistinct], t-mobile. so just answer the question. i think it's easy. i think it'sa good idea. i support it. number two, for folks that don't release aaaas, the dns64,which we'll talk about in the next presentation, will produce a aaaa record for your domain.you probably want to produce the aaaa record yourself and host the traffic yourself ratherthan have the dns64 and nat64 do it for you. >> [indistinct]. i'm concerned about the whitelistapproach. the approach talking about an--folks opting in by setting a reverse ptr. that'sbecause--well, we already have a behavior
that's default and the clients out there whichis asking for the aaaas to begin with, and that's a problem. now, it's going to be thisnew behavior. people are going to throw that into their products. there's something thatis done by default. they'll update this new thing in the reverse as part of installingthe product. >> kline: but this is the access network signalingto the content network, we're ready to move forward with it.>> right. and so access ... >> kline: we're going to take the call...>> ...that perform this. we'll say, "oh, [indistinct] ready. we'll set this for you. and you'regoing to have--you're off hands of this. if not on that, then later on where the accessnetworks--you know, it changes over time.
maybe their ipv6 breaks. maybe that guy quitand nobody knows about it. and that's still in the [indistinct]. there's going to be aproblem maintaining the... >> kline: nothing [indistinct] the impactanalysis that you have to do. >> i think as a strategy, you're a littlebetter off doing something a little more passive, something a lot more like a stability--whatdo you call it? we do it for spam. i'm blanking on the word now.>> reputation. >> kline: reputation.>> reputation. yes. an ipv6 to build a reputation trend.>> kline: so we could just automatically do it, right, because you look at resolvers andsay, "oh, yeah. this is pretty clean. well,
just turn it on," except that we're in a situationwhere i could be harming someone's ipv6 deployment that may be very fragile at the moment. well,yeah, maybe the connectivity is good enough but maybe their operational staff is dead,they haven't done operational procedures, they're not taking a pager for this stuff,it's not monitored. all that kind of stuff. >> okay. that's an issue.>> kline: okay. i should sit down. >> last thing before i sit down, i'm kindof capitalizing the lecture is if you do go further to the ptr idea, i'd suggest you prependand underscore ipv6optin.reverse. just--so that when people are seeing these queriesand wondering what they are, they'll know first of all and second because of some sillyrequirements about ptr being kind of like
[indistinct] but not and it's just--it wouldwork out better that way for me. >> kline: thank you.>> [indistinct]. you put up in these slides on statistics about how much book and theirsingle stats like many places but i've not seen really a detailed dive into what is reallybroken. and i think that until we see what is really broken, nobody is going to fix it.>> kline: well, lorenzo had a presentation about a variety of brokenness types. i mean,it's not like broken out with statistics like this percentage is 64 and that percentageis broken ie6 and--or whatever. actually, ie6 is fine for ipv6 but because i've nevereven tried it and so... >> my larger point is this is just like thebags in implementation. they will be [indistinct]
when the code will be exercised, not before.so this is something as--essentially this has correcting problem and i'm really concernedbut almost subtype of approach essentially taking a big gun to kill a little fight.>> kline: possible. possible. >> i just want to response, mr. hankins. thereverse point around, that would be a signal, it won't be a complete boolean release. inmy case, i would take it as advisement. it would be coupled with our own actual metricsfrom testing users. what resolvers they're coming through, what percentage are good orbad. if they're--you know, if they're borderline [indistinct] yes, let's go do it. if they'rereally bad, maybe i still hold back. >> kline: can we just--can we get to the nextpresentation or comment?
>> yes.>> kline: sorry, we have--we're like way behind time. we have like lunch in like 25 minutesand i have to get like two presentations. and here's marc, please talk about--do youwant this? >> blanchet: let's befriend with it.>> kline: all right. thank you. marc blanchet. >> blanchet: okay. thanks, erik. i've beenworking trying to [indistinct] ipv6 end-to-end nice. many of you probably know i've beenin the business of selling some products that tried to v6-to-v6 over the current v4. well,now we're--i'm in the thing of doing the ugliest thing i thought was dns and nat64. anyway,we've been doing experiments over the itf and other conferences. if you want to tryit right now, it's--that's the information
which is essentially turn off v4 and thenput your dns server address as in this address. we try to coordinate with erik to try to havea better set up here but there was some issues so this kind of an ugly act right now thati installed this morning. so it might not work or it might be slow, might be relatedto either the set up or your os implementations which, you know, as you have seen, have someissues. it actually includes a really ugly act for mac os, so to help mac os machinesthat are pretty popular. so having said that, try it out if it's, you know, send me emailand we'll see if it works or not. it usually pretty works in real, you know, environmentswhere we had time to set it up correctly. we ran it over the last itf the whole week.okay, presentation. use case, why nat64 and
dns64, basic architecture, the components,implementation, some words about our experiments, and real networks improvements. so here'stoday. we have lot of v4, a few dual-stacks, and a very few ipv6-only networks or devices.and that's the problem we have, which is many operating systems and applications do notnecessarily behave right in ipv6-only environments. when you feel a bug or you talk to the vendors,they say, you know, that's because no--not enough money, right? not enough users. however,tomorrow, because of the ipv4 address going out, then we will have ipv6 single stack usersand they will need to come access the content of the v4 internet. so that's roughly thebiggest use case for dns64 or nat64. so it's to connect the v6-only to v4-only together.however, when you talk about that as was well-described
in the behave work, is you have the locationof the initiator and the direction, and the number of servers on each side have an importanceon the solution and deployment scenario. so what i wrote here is that nat64/dns64 is mostlyfor--from v6-only to v4-only, and where most servers are on the v4-only side. you can addthings, you know, mostly is most is important which is, you know, where the use case fornat64/dns64 is the right thing. so i'll take two cases. access network. so provider provisionsonly v6 addresses to end-users on its access network for different reasons. ipv6 only end-usersneed to access content and services on the ipv4-only internet or on their provider, youknow, specific services that are only v4 or an esp or something as you've seen since thelast two years--last two days a few examples
of these. ipv6-only end-users are clientsfor connections. they don't advertise the service so it's a typical nat environment.so here's the drawing where the computer is on ipv6-only access network, you know, connectto v6 content. no problem and--but cannot access the v4 internet and obviously, theanswer is the nat64 to fill out that problem. content network use case. we've been talkingto a few content providers for using ours--the software we wrote. so this is an example where--essentially,who is doing the--who is helping the other. on the previous slide or the use case, it'sthe provider that, you know, helps these end-users to connect to v4. on the other side is thecontent provider that has v4-only content because their service is not converted yetto v6 or they will never be converted to v6.
so therefore, they want to offer that contentto the v6 internet and so that's the use case. so you see the difference is the nat64 isthen on the other side. so the architecture, there's two components. dns64 is a dns serverthat inserts a aaaa request from ipv6-only client. and it does that by synthesizing aaaaa reply using the a answer received from the ipv4 site. the nat64 translates ip packetsbetween ipv4 and ipv6. the two components do not share state or need synchronization.they can be on different and you will on the slides that they're in different, you know,places. they could be at the same device or just completely separate but they need tobe configured with the same special prefix. the ipv6-only client is unaware of nat64/dns64,so unchanged. the ipv4-only server is unaware.
so this is an example, you know, very basiccomponents where the client do dns queries to the dns64, get an answer. and that answercontains a special prefix which is synthesize and then add some part which is from the arecord on the internet. then, essentially sends the packet to the request or the tcpsent to the nat64 which actually translate the packet. there is an example with the flowdiagram so you'll see a bit more. so this is the--v6 network is 2001: db8 and nat64is 1, 2--you'll, get the thing. the key here is that you--the special prefix that you usefor those, you know, aaaa synthesis are actually either a special--actually, there's a typohere but it's actually either a special prefix or your own--part of your own provider prefixboth case work. so here's the flow example
where the ipv6 client request the dns queryfor example.com at aaaa record goes--it has to go through the dns64. the dns64, you know,ask that same question, just pass through. if it gets a aaaa answer, then it just passback to the ipv6 clients, same thing, no problem. if it doesn't get any response, then it triesthe a record. it could be done in parallel. then receive the a run answer and then synthesizedns response. and then the client connect and then connect through the nat64. so ourproject, open-source implementations. funded by nlnet and ourselves. ecdysis refers tothe moulting of the cuticula in arthropods which is an analogy of ipv4 moulting to ipv6.so after moulting, the arthropod is fresh and ready to grow. we did actually many implementations,dns64 in perl, a patch against a bind and
a patch against unbound. nat64 was done ona user space. linux module netfilter and then pf patch. so you have your traces. prettysimple for unbound because unbound is modular, so you just write another module and thenyou see the configuration would be on--you just need to add the special prefix for dns64.bind, well, it's a patch. it's not a module and we added a configuration variable dns64and then their prefix. that's pretty straightforward. nat64 in linux, it's kernel-space. you know,there's a module. what is good with the integration with netfilter and then pf is the fact thatyou can apply security policies as you want this all integrated. nat64 in openbsd's pf,you know another configuration command. we don't do our redirection right now. networkexperiments, we did anaheim ietf the whole
week was with a specific ssid. we presentedsome slides at behave working group about this. and now today--and we plan for maastrichttoo. and what we found, surprisingly work well for typical end-user traffic, becauseessentially, internet is over http as we all know. however, as you have seen, there's manythings that work and doesn't work. but roughly speaking, i was pretty surprise at, you know,we've been running it in our network and, you know, for the typical end-user connectingto a few typical website, it works fine. network managers think you're offline. ipv4-only appsdon't work, obviously but--and ip address literals are not good. and we do have oneos that is really picky about ipv6-only networks, which affects nat64 deployments. i'll leavethis, because time is over and we will have
more work to do and we'll be obviously open-source.conclusion, it's a solution for connecting v6-only to v4-only, useful for access network,content network providers as source code is available. please try it. and thank you verymuch for your attention. you did a great job explaining how dns64/nat64works, but i think it's also important to explain how it doesn't work. it's not neededfor the cases where there's ipv6. and so, if you live in like the mobile provider world,like i do, where there's lots and lots of... >> blanchet: yeah. please do not use it ifyou don't need it. please. >> so if you live in a world where a lot ofnat and people throw around the words like cgn a lot, there's no light at the end ofthe tunnel, you know, in ipv4. it's very scary.
it's very daunting. you see your expensesgo up and up every year. you see state go up and up. every year, there's new alg issues.dns64/nat64 is beautiful in the sense that it goes away over time. as an architecture,it's very elegant, and that it drops out of the network as the ipv6 content comes online.that's why i really want to see a lot of ipv6 content so it doesn't have to go through thiseven though this works pretty good. >> thank you. [indistinct] our user.>> thank you, marc >> blanchet: thank you very much.>> arkko: all right. so talking about experiences around ipv6-only and nat64. basically, meand frederick and a few other people going to the bleeding edge and then coming backhere to report what we found, what we learned.
so, what did we do and why? so, for background,our sites had been in dual stack for ages, basically. the office had been in dual stackfor like over 10 years. and it all worked very well, so clearly, we had to try somethingelse. and, you know, of course, eventually, people will have to go to ipv6-only or gobeyond dual stack. it's just a question of time in--i'm choosing a suitable network wherethis can be done. and as you heard during these two days, there are some of these mobileplayers that are considering this very seriously. so we wanted to know what does this mean andwe wanted to find out what it means for the end-user, report back to the community onwhat will actually happen. we're also building a nat64 device of our own, you know, at ericsson,so we wanted to obviously test an early version
of that. and a little bit more internally,we wanted to build an understanding of when can we recommend this mode of operation asopposed to regular dual stack. so, what did we do? you know, it's a really--i mean, ican boast, you know, hundreds or millions of users. it's just a handful of people, really,but it's our research lab in my home. it's a small group of users that will all opt in--there'sprobably like 10 people who had been in the network and maybe five of them are there ina permanent sense. and we built an ultimate network alongside the existing one that hasits own wireless, has its nat64 for access to the ipv4 internet, has routing...routing,you know, whitelisting, all kinds of things like that were already in place, so we didn'thave to deal with that, so that was already
working quite well. and experiences, it ispossible, i mean, just speaking from a personal experience, i don't need to go back, i ampermanently in ipv6-only. i've said goodbye to the ipv4 internet. but some pain is involved.so i don't necessarily recommend this to everyone, just yet. in more detail, many things do break,there's mostly about lack of ipv6 support in applications and some types of devices.there's lot of bugs that, you know, people just haven't tested this in a network thatdoesn't have v4 as well. and some of our users went back because of these issues becausewe couldn't really ask them to, you know, be without whatever they needed. and overall,i felt that the key issue or that the one thing that we need to address is this ipv6support rather than some things in the nat64
part which generally seemed to be workingrelatively okay. so what does actually work and what does break? so many things work well,obviously browsing works. yesterday, we talked about the ipv4 literals. i've only seen twoinstances of that in my personal browsing the last two months. so it's not a huge issue.well, of course, it depends on where you go and so forth. email software updates, manychat systems, streaming, lots of things do work, and then some interesting thing if youcompare those other general purpose computing environment and the mobile environment. ifyou get to choose the terminals that you use then you can actually get everything workingin v6-only and you don't lose anything. but that's not necessarily true in the channelcomputing environment. and then there's issues
there. there's a host operating system issues.the lack of testing. some applications fail. many appliances support--do not support ipv6.there are some issues with firewalls particularly with the fragmentation support on v6. andwe actually had to change our nat64 code a little to do this. example issues with operatingsystems, ra info is not aged or removed as you move from one network to the other withoutgoing through the sleep state in the ubuntu for instance. you have to tell several operatingsystems that you shall not expect v4, that's like a manual action that is needed. dns discoverycontinues to be an issue. and there are several types of manual things you have to do forthat. example issues with applications. in our particular user group, the biggest problem,the skype. and i actually send the message
to jonathan rosenberg about that and he saidthat they do have a plan to fix this but not a specific timeline when that actually happens.so, it's, you know, maybe if all of us call him tonight, he'll change his mind and doit quickly. some chat accounts fail, msn, aim/icq, but some other stuff works. secondlifedoesn't work. and that's a problem for me because the ist has decided to have some ofits meetings in secondlife. many games fail in pair network or lan version. messaging,this is the--i won't to go through the details but these are the things that we tested. anythingon the web works, anything over xmpp works, that's great. some other stuff doesn't work.then i also enrolled my kids in this exercise and, you know, move their computers to ipv6-onlyand ask them to test the games that they had
on their table. and it's not pretty, it doesn'twork. even some things that are supposed to work like on the stuff on the web, it doesn'twork. there are some ipv4 [indistinct] or something like that. nat64 generally workedrelatively well, some issues perhaps, we--i'll leave that to the lack of time. we did runthrough some experiments actually, we compared like, looked at the alexa top website listsand try to compare what happens in a regular ipv4-only network and an ipv6-only, and thenipv6 only plus nat64. obviously, with ipv6-only, lots of things fail because it's like googleand few others on the list that are v6 so nothing else works. but with the nat64, it'sbasically the same error rate, as with the regular v4 but, then you loose the sites tohave ipv4 literals and that's pretty much
the issue. there aren't too many, but some.and if you look at that, that's 0.2% on the first thousand and if you go to the first10,000 then that's 2%. we haven't [indistinct] on that we will continue this test. but it'sreally hard to tell whether this is an issue or not but it wasn't an issue for me personally,but it could be--and just having an error it could mean some advertisement that wasnot displayed and, you know, big deal, for me at least. so, conclusions, recommendations,i think this confirms that dual stacks would still be our preferred mode of operation forthe general public or networks in general, maybe possible to do ipv6 only in specialenvironments, such as mobile networks, particularly if you have a control of the terminals, that'sreally a key and, you know, enthusiast networks
and special things like that. and with effort,i mean, this will, of course, change in time. maybe in two years, this will be possiblefor everyone and we actually do have to work. i have a list of things here that we needto do in order to make things better. we have to improve the dns discovery. we're doingsome things about that in the itf. some implementation things also have to be done about it. we haveto fix bugs. we have to have ipv6 support to skype, messaging, gaming. we need to domore measurements that'll actually do understand what's going on about breaks. and we actuallydidn't turned on any algs in this particular test or proxies so there are things you cando manually or operationally to remove some of this breakage that we saw by which we wantit to be pure in our test here. so, that's
it. i am--my plan is to report in more detailbut we intend to draft about this, so hopefully we'll have, you know, more information foryou in the future. thank you. >> real quick question. so, as a sophisticateduser, have you noticed your user habits changing? i mean, you take around with the network,you type in ipv4 addresses, you type in ipv6 addresses, i'm just wondering, as a sophisticateduser, do you find yourself typing in an ipv6 addresses and avoid it because they're longand hard to read or do you just use the same expert mode that you've always have?>> well, mostly i used dns, obviously, but now i do remember my ipv6 address, so that'sa change. >> but you forgot your social security number?>> so have you noticed any difference about
the--you're like experiencing time [indistinct],for example, the response time or the download time or something like that.>> that's an excellent question and i don't have any data about that. that's like anecdotalevidence that, you know, one of our users felt that this was slower but it can reallybe quantified and we didn't really see it in ping times. but this is definitely somethingthat needs to be measured. not just for this nat64 stuff but also for the general dualstack usage in the global internet. >> i can answer from our experience. it reallydepends on the operating system you're using. very different, if, you know, some operatingsystem, you know, time outs and problems but some are better for the same, you know, connectingto the same sites, exactly the same sites.
>> i think you're list of games might be sortof a tad bit too negative. if you add--at least if you want to go to like older games,if you want to see [indistinct], that's open source, it's been supported for, like, tenyears. or if you'd like to play command & conquer type of [indistinct], i have a binarypatch for that. >> that's good. we really need to fix thegames. my selection of games was, however, very random. it was exactly the games thatwere on the table, on the top of the table at the time that i'm asked this to be done.and, you know, i removed the ones that don't do network mode, so.>> quick response to the max comment. i understand that the aspect of this experience would be--woulddepend on the operating system implementation
but i also think that would depend on thereachability or the network status or stability or something like that. so, my question isabout the overall experience taken into account or...>> yeah, and i think we need to separate the error cases where things fail or timeout andthen the usual case when it works but it takes a little bit or millisecond longer, and that'sthe one that i really want to measure but i haven't done it yet.>> thank you, gary. thank you very much.
At the end this articel Ipv6 Connectivity No Network Access
Now you have reading Ipv6 Connectivity No Network Access with link addresshttps://networkrealtionforbussiness.blogspot.com/2017/05/ipv6-connectivity-no-network-access.html
0 Response to "Ipv6 Connectivity No Network Access"
Posting Komentar