Google IPv6 Implementors Conference: Application Readiness Session & Panel Discussion

>>
GUNDERSON: So I'm going to talk a bit about the experiences of the Google IPv6 internal
software porting effort which I've been part of for the last two years or so, more or less
not enough. So to give a bit of overview, Google has a pretty large code base. It's
not humongous by any standards, but it's pretty large. Tens of millions of lines of code is
C++. I'm going to talk most about C++ because that's where the interesting parts lie for
us. For others, this will obviously be different. When I say Google's code base, we actually
mostly have one single tree. And this has advantages and disadvantages. It's great because
it can fix things once instead of a hundred times. It's not so great when it breaks up
in central and you have a couple [INDISTINCT] that are mad at you. At that point, it's good
being a jerk. This is not count if you external things, like Android is not part of this,
Chrome is not part of this, but you can get sort of the idea. This is the bottom up effort.
It's not, like, management that comes up from low--sorry, top management that comes down
from above and says, "Do IPv6." This is something people started doing by themselves because
they thought it was a good idea. So at that point, you want to prioritize. You want to
take the most important part first, and the most important part is definitely the one
that shows, "Hey, we can do this." So let's look at the obvious differences. I mean, I'm
sure most people know this, but for others, it's not as obvious. IPv4 and IPv6 are really
much the same thing. I don't know who first said, "No magic, just 96 per bits." I think
I picked that up from presentation here a couple of years ago, but it's definitely true.
There are all these sorts of minor differences like flow labels. If anyone can tell me what
a flow label is good for, please tell me. But mostly, you don't only have to care about
that. The single biggest difference, at least, when you're writing something service side
is that the other happened to be larger. And if you can fix that, you're, like, 95% down
the way. There are a few exceptions from that, which we'll be talking about near the end.
But in general, if you can make your application understand that an address is more than 32
bits, you're good. So let's look at the different ways of representing addresses in your space.
These are few things you should avoid. I've seen--I mean, one thing is obvious like sockaddr_in,
which is my IPv4 address in addr, which is, like, four address we don't port. Int is unfortunately
very common. Inside Google Apps, you've seen lots of hideous variations on this, like type
dots to this, like strips containing them, like people using 64 bit ints. I don't think
I've seen anyone represent an IP address in floating point number yet, but I wouldn't
be surprised. >> Java.
>> Java [INDISTINCT], okay, thank you. And worse still, you can't grep for an int. So
it's really hard to know sort of when you have tens of millions classic code, where
is sort of the devil. But let's look at a few strategies anyway. The one--first one
is the obvious one. If you're writing things from scratch, you can pretend that IPv4 and
IPv6 is the same thing. And this is basically what your operating system probably already
does. If you open an IPv6 socket and set it as dual stack and people connected over IPv4,
you will get this special kind of IPv4 map into the v6 base, which is good because we
have lots and lots and lots of v6 base, so we can put all the v4 base within it somewhere.
This gives you this--we're looking ffff addresses, which you might when you're displaying them,
show us something else. But in general, you can just pretend that, well, it's, oh, IPv6,
let's find [INDISTINCT], and we can go from there. The problem is, of course, if you don't
have IPv6 on the machine, if you're writing client software, this doesn't work. And the
other really much bigger problem is if you have the interface with code that is not ready,
this doesn't work, right? If I have sockaddr in six, I cannot pass, it's off to a function
that has--just takes in sockaddr_in. Yes, question?
>> [INDISTINCT] and you don't have the little big-endian problem like [INDISTINCT].
>> Okay. The question is if you store it as an IPv6 address, you don't have a little big-endian
problem? I can tell you, you actually have little big-endian problems anyway, but they're
much more obvious. So, yes, you're right. So the big problem here, it's a viable strategy
but it requires you to take everything at once. And as we already see, I mean, I cannot
go and fix a big program in one night. It's just impossible. So the other part, which
is probably what most people is going to be doing is building some sort of address abstraction.
Now, obviously this depends again on what language am I using. I'm talking about C++
here. For people using, for instance, Python or PHP, this is going to be probably a different
game. But an address abstraction is simply some sort of object that represents an IP
address. It maybe an IPv4 address, it maybe an IPv6 address, but mostly you can sort of
deal with them the same thing. They have the same kinds of operations. For instance, I
can get the port. What type of port? I can perhaps match against them. I can see it does
this list. This is address [INDISTINCT] this list of addresses. So depending on language,
there are different things. Unfortunately, C has the problem after we don't have a good
address abstraction. We do have sockaddr in storage, which is huge. It takes up, like,
256 bytes of memory. There is--but there's nothing that actually has [INDISTINCT] an
IPv6 or IPv4 address without a port. People will often use strings. This is actually not
as bad as it might sound. Java typically does this. It's not too uncommon in, say, PHP.
If--at least, if you're in a dynamically typed language, this is just fine. We made our own
classes. IPAddress which is an IPv4 and IPv6 address, SocketAddress, which is the same
thing in a port, and IPRange, which we would have called IP subnet if that name weren't
taken. Actually, the name IPAddress were taken, so we moved, like, 4,000 entries of that over
to old IP address and made our new class. These types are not magic. They are not hard
to make, they are pretty much obvious. You can look at Squid, for instance. It has something
that look like--if I didn't know better, I think they're just like stellar code. But
you must sort of decide to what level do you want things to be abstracted. For instance,
we got kicked back at some point because we didn't support UNIX domain sockets. You might--if
you're adventurous. you might want to pull DNS into this. I wouldn't recommend sort of
mixing a host name and an IP address, although I tried to do that. It's--it has [INDISTINCT]
problems. So you decide what do I want to abstract away, what do I want to do and what
do I not want to do, and build something simple? This will usually serve you pretty well. So
we've been doing this for a while, like a couple of months. We saw that most code actually
does not need to care about what an address is. You got an address object from somewhere,
you pass around, you might store it somewhere, you might ask some function to do it in a
string, but you don't actually need to care what it is. The structure of an IP address
is--unless, of course, you're writing a router, which I'm not doing, thankfully. You don't
need to care about what it is. You can just, like, send them out. And that leads us the
strategy, IPv6 address coercion, which basically in our case to [INDISTINCT] to doing this
but we take the first 64 bits of an address, hash it, and squeeze it into unused IPv4 space.
>> Is that huge? >> GUNDERSON: That's--what did you say?
>> Is that huge? >> GUNDERSON: Yeah, well, okay, so the question
is if that's huge. And, yes, that is multicast base. But you can also take like E space,
right? And if you really want to care, you can use local host space, for instance. So,
yes, it's an ugliest and hideous hack, but it actually works really well.
>> [INDISTINCT] >> GUNDERSON: So this has been used all over
the place. And--okay, thanks. The good thing is it allows you to take all your IPv4 code
and send them IPv4 addresses. You can--of course there are some things you cannot do.
You cannot geolocate them. You cannot use them in ACLs. There is some risk collision
but, of course, there is risk of collision in that anyway. And we course all the time.
I mean, the very, very first Google over IPv6 implementation was a reverse proxy setting
the address to 2325666. And, of course, we're moving on to there. Most of our software now
understands IPv6 addresses, but you can still actually--I mean, you need to be a bit careful,
like at some point this lead to the users. So Gmail would say, "Your last login address
was 239.55" whatever. So that's obvious [INDISTINCT]. But you can do it everywhere. I mean, we even
do it automatically in production. If at some point you try to convert an IPv6 address to
an IPv4 address, instead of crashing with the search failure, we actually just convert
it and log in warning and column gets paged. I don't think this actually happened yet in
production, but it's good to be sure. So the obvious battle plan, this--mostly there is
a few problems left, right? There's multihoming, which is not an IPv6 problem, but now almost
everyone will have an IPv4 and IPv6 address anyway, [INDISTINCT] only to deal with. This
is not the simple case, right? The other case is that the address space is a lot larger.
This means that you're typical despammer will have a lot of other space. And your, typically
DoS attacker will have lots of address space. It means you can no longer store 1 bit for
[INDISTINCT] /24. So, you'll need some sort of structure that doesn't deal with--doesn't
try to slice up the IPv4 space into thick slices anymore. So, you will need to do some
work here. I'm saying, generally, this IPv6 porting is easy but it's not achievable. And
especially multihoming and security are going to be your difficult parts. So, the obvious
way of doing it is test it, start sending IPv6 traffic to your service; watch it break.
And when that gets fixed, you try it and try again until you're happy. If you are using
statically typed language like [INDISTINCT], you can simply go out and grep for the types.
Grep for in_addr. Well, you can't grep for int, but you can't grep--can perhaps grep
for all IP address or whatever. We've been doing experiments with static analysis, which
actually looks like if your function is dealing with an IPv4 specific type and not dealing
with an IPv6 specific type, perhaps, this is should be a warning. If your function is
calling another IPv4 and, say, function, perhaps, that is also bad, but in general [INDISTINCT]
works. So simply just start in one end, start in the obvious end, so you user can get your
queries and then you're going to take it and then they can sort of go back and fix back
ends afterwards. Questions? >> You listed free structs that were kind
of messing up stuff and I say that it wasn't the previous speaker I'm talking about Java
on Window, that's the reason. >> GUNDERSON: Yeah, I don't actually know
how this works in the windows' world, right. They have BSD API and then some sort of parallel
API. So I don't know how this looks, but in general, I mean, convert in_addr 6 and it
will be most defined. >> So as a fellow programmer, what I struggle
with, with IPv6 is, CLI formatting because you don't have 17--17 [INDISTINCT] is usually
good for IPv4 address. So, I mean, you guys have all this cool GUI stuff that can compress
addresses, but how do you deal with that when you need to put--do print ups and that sort
of stuff? >> GUNDERSON: Well, thankfully...
>> How to make it look pretty? >> GUNDERSON: Thankfully, we don't, right.
Most users don't use GWT anymore. I would--I mean, I cannot help you compress 128 byte,
which down to like 15 characters unless, of course, you do the hashing coercing, but I
don't think your admiral would be happy about that.
>> Right. Yeah, what we tend to do when we need to have summarized table is that we put
high order two bytes, dot, dot, dot; low order two bytes and try to fit it in 17 so we could
have v4 and v6 manipulated. And, you know, the higher the bits aren't always that useful
unless you're looking at prefixes. And the lower order ones are kind of Mac address opaque
issue. >> GUNDERSON: Yeah. And this depends a lot
of who you are, right? We care--I mean, we don't even care about lower 64 bits.
>> Right. >> GUNDERSON: And the admin will probably
only care about lower 64 bits. So, they have this sort of know your audience. But please
allow me to make it wider because my screen is wide screen and my router had that than
other ways of showing it. >> I have a more basic question. I didn't
understand the, what they called the hashing, so could you go back to the slide and can
I see that? >> GUNDERSON: This part?
>> Yeah. >> GUNDERSON: This hash could be anything,
by the way. You might want to actually do encryption or whatever in case you're worried
that an attacker might be controlling your bits.
>> So, what is the purpose of discussing? What are you doing with this?
>> GUNDERSON: What I'm doing with the address? I'm taking the IPv6 address.
>> Uh-huh. >> GUNDERSON: I'm picking out the first 64
bits. >> Uh-huh.
>> GUNDERSON: Which because the lower 64 bits are, for me, they are noise anyway. And I'm
hashing them down and putting them into an IPv4 address. So, whenever I now need to give
this IPv6 address to some piece of code or some log or whatever that doesn't understand
v6, I will give that [INDISTINCT] at any part instead. Now, this address doesn't mean anything.
>> So name one measure application over this is logging that only understands IPv4, for
example, is that correct? >> No, no.
>> GUNDERSON: Can you please repeat it? >> Routing.
>> GUNDERSON: Oh, sure, well, you cannot use this to route them. You, definitely cannot
use route them at all. This is just some sort of identifier that I'm giving to my application
software. >> Yeah, but this is hashing it's--it's many
to one mapping, right? >> GUNDERSON: So, it's definitely many to
one mapping, and I think, and you will get collisions. Of course, you could in theory
make--record all the coercion you're making and make a reverse table like start at 224.0.0.1.2.3.4.5.
>> Okay. >> GUNDERSON: That might be viable. I've actually
seen software, which does this. >> Well, let me give you an example. For example,
if you're running a telecommunications company and every time you make a phone call or a
data connection and it logs that connection as what's known a Call Detail Record, you
will get a 39 character IPv6 string. Your billing system is very expensive and difficult
to upgrade, this is a good solution. >> You have a program that doesn't understand
IPv6. You want to use it anyway. You have millions of lines of code that doesn't understand
IPv6. You want to use them anyway. You have a tiny percentage of your users that's coming
in over v6. Give it a v4 address, that's what it wants and then you can fix it on its own
time. That's the purpose of this. >> GUNDERSON: It's definitely a temporary
measure, right? You don't want to have this lying around ten years.
>> So, you plan doing it on the Gmail log, which you have your sessions on because this
has undefined if you're using IPv6? >> GUNDERSON: Yes?
>> Would you like that or would you like the Gmail?
>> I like it's kind of undefined, it's like more secret and cool.
>> But no, it says, yeah, go ahead. >> GUNDERSON: Well, also the [INDISTINCT]
now says, undefined is that previously it wouldn't say, 224 or whatever, blah, blah.
>> So, you say, yeah, yeah? >> GUNDERSON: Yeah.
>> I'm not sure if everyone goes brilliant when I announced to this preliminary and there's
this results yesterday, but in terms of subnet branching, the IPv6 address has--have a two
regions between bytes--bits of 12 and 48 and bits 64 and [INDISTINCT], which makes it 52
bits together. Yeah, so this is very essentially information this, in the IPv6 address.
>> GUNDERSON: Okay. It's good to know. So, you might wanted it to be more selective?
This is sort of the quick [INDISTINCT] solution. >> All right.
>> Last comment? >> Has anyone considered static code analysis
if you have millions of lines of codes? >> GUNDERSON: Yes. This is...
>> It's something like [INDISTINCT] could found out that this is ever--this came out
of the [INDISTINCT] wouldn't mind to connect or it's going to be used in there. You should
be able to find it then. >> GUNDERSON: Like I said, we did this with
the Hydra, which is a JCC plugin. You can probably also do it with Clang. And, yes,
it gives you good results, but grep is for our purpose is actually good enough. I mean,
you can be really high tech. >> [INDISTINCT] to be use int of course, [INDISTINCT]
32 has [INDISTINCT] minimum [INDISTINCT] >> GUNDERSON: Sure. And then you go and sort
of beat the developer. So, let's say, you doesn't do that again and then you added Unit
test and you probably just like copy your IPv4 unit test, it doesn't do it again.
>> That sounds good to me. >> [INDISTINCT]
>> Thanks. Thank you. >> Public service announcement, if you are
in the v4-only Wi-Fi, please get off it. Embarrassingly, we have run out of private v4 space. I swear,
I'm not making this up. It happened today. DACP is now failing across campus for the
guests that work. So, please get off it, leave that as...
>> Yeah. >> The v6 network has a separate pool. This
is not by design, but it will keep us safe for now.
>> It drives IPv4 deployment. >> GARNEIJ: So, hi, my name is Fredrik Garneij.
I work at Ericsson back in Sweden. And I'm going to talk about what's up with the applications
and IPv6 in cellular networks, so some do's and don'ts consideration, so. But first, some
corporate PR quickly. So, if Carlsberg did Mobile Packet Core, it would probably claim
it to be the best packet core in the world, so we do. And of course, we can claim probably
the best mobile packet core in the world. So that's a part. Okay, let's move on. Is
there a mic or do we have to stand here? >> The mic is I think they're working around
[INDISTINCT] >> Okay, good.
>> GARNEIJ: Because I can't [INDISTINCT] it. So, we've seen some cellular network explanations
how it's actually done. I think we need to go down to the seven-year-old way because
to understand this stuff really good. So this is really what we are doing. We are kind of
packing stuff on top of other stuff, IP on an IP, and we are doing encapsulation. So
just to make it a bit more clear, I brought my--since I don't have a baby here, I went
to Wal-Mart. So this is the--let's have a look here. Oh, it's a basic packet, I could
tell. So it's like--if the gates were here--is here, this is where you enter the mobile network.
So this is Internet and that's the mobile packet core. And over there, there's the cellular,
the radio there and that'll be the terminals. So the packet comes in here and then the gateway
encapsulates it like this and then, okay, where am I to go? And then, there are several
nodes here that you could ask to where was this at last time. So, okay, it's over at
that cell station. So it's getting transported through the network here. So this is actually
encapsulation and this is very important to understand that we already do tunneling in
mobile networks. So and then, there's a radio here, so then, you'll just go over to the
air, oh, oh, packet drop. Resend please, resend please, okay. So now the new packets go to
the same station here and hopefully I'll catch you this time. So now it's going on the radio,
so now, it's leaving the encapsulation going on by a dome and then the terminal takes it
and that's it; this is what we do. So did you understand this one or do you want to
[INDISTINCT] the specs again? I don't think so. So some considerations when working with
this environment. So let's look at the buzzword IP Agnostic. I would like you to understand
that IP Agnostic is not being IP version Arrogant neither IP version Ignorant. So this is a
bit of a problem. I'll continue and explain why. So damn those keep-alives. I used to
be using my Push email on my phone. For Ericsson, we have the very expensive piece of software
that you could only load on Sony Ericsson but it killed my battery all the time because
of the keep-alives. So what do I [INDISTINCT] to E6? So having the heard NATs are gone or
are they? I've got confused by all the discussions here, but still there are some maybe some
firewalls which stay for long stuff like that, so you might need it, but let's consider that
they are gone. So we're not the NAT44-land anymore. So why don't we want keep-alives?
So if a cellular network, an application there, sends keep-alives and that could be plenty
of applications that are actually online, then what happens--this looks [INDISTINCT],
okay, there's a packet going on there but what happens in the network? This happens
and this is on a good day. This is when the mobile is not moved, it's not the same station
as we see it's all here. And you see the packet is actually in the blue part here that's where
we send packet that you--a lot of conversation over radio before that. And then, after a
while you do this, so a lot of signaling just for one stupid keep-alive that doesn't--you
needn't have to send for [INDISTINCT]. So if a packet core node could talk, they would
probably say, "Are you happy now? You are on an end-to-end connection, dumbass. Stop
it." Well, unfortunately, they cannot kind of communicate in that level, but. So if you
want to speak, speak wisely. And we're talking about IPv6 being gold and silence is golden,
so let's try to be quiet if we don't have anything useful to say. So next consideration,
to be able to have connectivity in mobile networks, you have to be able to provision
for it. So I'll try to do a little demo here just to prove my point. Okay, this is Android
2.1 running IPv6 on a cellular. So if I go into the--to the settings here, there it is,
and I go to one wireless networks and mobile networks and excess point names, I had to
put the six in front of the APM because there's no way of actually saying that, "I want IPv6
or IPv4," and this has been in this time since 1907, so there's nothing new. Okay, let's
go out of that, just to prove that this is actually working. Let's--and that it's actually
a phone what I'm using here. This is Google and it chose the mobile pages. So, it's actually
an Android phone here. And we can do--we can do the IPv6 test wherever the looks screen
is there it is to watch the--or goes with the, oh, it was Google again. I missed it,
but there's the banner of the date, so. I think we're kind of done with that last, just
to prove which network and make Cameron happy or fire away the tricorder. And look, no Wi-Fi,
only cellular and then some T-mobile. So it's working.
>> How would you write [INDISTINCT]? >> Okay, I can do that since the demo is over.
So wouldn't it be cool to have a phone like this to... Well, I put you on the coffee table,
but there were no ladies coming forward to me because I have this phone. And so, it's
not a babe magnet. I'm sorry. But like Picard says, "Make it so." Let's make all the other
Google phone use after this whole cellular. So provisioning--two minutes left? Okay, provisioning--I
will do this. Of course, you will be able to--you can't have these kind of boxes. That's
just not IPv6, even if you hatch it. So we can't do those and we have packets in packets.
So if you'll like to somebody like dual set lights, you have more packets in packets.
So you don't want pack and pack more packets in the packets that are already packed in
packets, right? Okay so, and last, it's a bit crowded in the IPv6 pool right now, but
it will go away because of the efforts that we have been doing here and there will soon
be a bit more room there. And if you want to see some more videos of me doing IPv6 over
cellular there's the address, okay. Thank you. Crystal clear; thanks. I did a good job,
then. >> Sorry, I have a comment.
>> Okay. >> My company is a user of [INDISTINCT] and
products, so I have a lot of claim but anyway, yeah, as you've said, Push application has
very huge impact to their concurrent usage of IP address. Before Push application, number
of concurrent--number of concurrent IP address usage is very few compared with the actual
number. But now, it is becoming a--what's that, I'm sorry, that after Push application,
this number grows very rapidly so it has a very big impact. So I totally agree with you
that mobile application--mobile industry should--also should move forward to IPv6. That--it is my
comment. >> Yeah, I agree and not just for that reason,
but for two reasons that actually you could get more devices and you could get back to
better lifetime, so that's it. >> Thank you very much.
>> You're welcome. >> [INDISTINCT], thank you.
>> So probably I can deduct this from taxes since I've used it in work.
>> Right now I get set up for a panel and run these panel of presenters and you get
some sides up. Can you help us set up for the chairs please? Thanks. Three, on the same
side, on this side, on this side. >> Okay, do whatever you do. I'll break these
chairs. >> [INDISTINCT]
>> Watch the mic wires, there. >> Exactly.
>>[INDISTINCT] >> Oh, that's fine.
>> So all the things are labeled the PNL panel down here.
>> Tell the people that all the things are labeled PNL down here?
>> Yeah, doesn't it? >> Yeah.
>> We have presentation you could find the panel at the sides of the bottom. We have
only one mobile mic that's working, I think, at the moment, unfortunately. So you have
the stage. >> BUSH: It's okay. We've only got one guy
who's doing mobility. >> You want to introduce your panel?
>> BUSH: I was thinking of that. >> Yeah, okay. It's a good idea.
>> BUSH: Hi, I'm Randy Bush at IIJ. We kind of put together a panel at the end to talk
about Speed-bumps, you know. If we have a number of different people from a number of
different areas, Thomas talked about the ITF and Lorenzo to talk about content providers
and Ron to talk about large things at the other end of the pipe and Miles to talk about
backbone. I'm not going to talk about anything much. I think Jary will be a good example
of the Pollyanna. Everything is wonderful and if everything was wonderful, why the hell
are we having this meeting? So... >> [INDISTINCT]
>> BUSH: No account for taste. There's--so there are real problems. We are engineers;
denying problems doesn't get them fixed. So we need to figure out what we can do to make
it easy for the world to deploy IPv6 for they become motivated to do so. And who'd like
to go first? Thomas, thanks for volunteering. You were holding the mic, I saw that. This
is--go for it. >> NARTEN: All right, thanks, Randy.
>> BUSH: Present the slide, it's panel. >> NARTEN: Why would you want my name in it?
>> BUSH: Yeah, that's believable. >> NARTEN: And if I have to do a full screen
somewhere? >> BUSH: I don't know. This is IBM.
>> NARTEN: [INDISTINCT] >> BUSH: Just get someone IBM to work on it.
>> NARTEN: Okay, I'm going to go through this fairly briefly because some of this is kind
of boring, I guess a little bit boring. But the general theme here is what work do we
still need to do here on the IETF side to get IPv6 ready for deployment and make it
more deployable? And the summary that I have is you're at the high level. I think, overall,
the main work has been done. You know, with people keep running around saying, "We need
to do more. What about this? What about this gap?" But when you sort of look at it in more
detail, it looks like the main--the major items that are out there on the table are
being worked on now or are, you know, are either close to being done or are done. I'll
go over some of those in detail, you know. But that said, it's always going to be work
on v6, just like there's work on v4, there's always more stuff to be done in terms of revising
documents or as we actually deploy this stuff and run into real problems or real situations,
we can presumably fix them and deal with them. With that said, there are also lose ends that
should definitely be dealt with one way or the other. And I'm--right before this panel,
I had a conversation with Randy where he asked me, "What about the status of this, what about
the status of that?" and I'm like, "Well, I thought we've dealt with that, or I thought
that was an issue that we were going to move forward." And there's still, I guess in some
sense, lack of clarity about whether something needs to move forward when there's a problem
or whether we really have decided not to do something and I think that would be good to
do. So main work areas are, you know, 6rd, there's some work been done. There's some
documents out or I mean, in a queue. Softwires is a fair amount of work, Behave where all
the NAT64 kind of work is being done. There's some work in DACP, in 6man, v6ops and so forth.
And other things there's pretty quickly but I think we've covered a lot of this. This
6rd work, there's a document that was published earlier, that was for the informational. There's
a standard track document in the queue that allocates also some DSCP code points such
done in Behave. There's obviously a lot of work going on with the NAT64, the DNS64 work.
The thing to notice that I think five documents we went to IETF last call like two weeks ago.
So now is a great time to go look at those more carefully, do careful reviews and get
this work done and out the door. Softwire, likewise, they have a number of Softwire WG
in working on dual-stack lite is obviously progressing and there's something that there's
a lot of interest in. If you go to a 6man, they are doing a number of items. I think
most of those are relatively minor and not that interesting. You just need to be done,
just sort of, you know, dot in the eyes, you know, and cost of Ts sort of thing. Probably,
the most interesting one is the RA, the Router Advertisement option for DNS. There's an experimental
RFC that do this already. It's being put on the Standards Track to give it more wider
visibility and more of a green light to implement. And as a part of doing that, they've also
now added the DNS search path to that document. So you can throw an RA, get all the information
you need to, you know, contact the DNS server and do work. And more major items that's still
out there is address selection, RFC 3484. And there's been a fair amount of discussion
today and yesterday about problems with, you know, actually using v6 and having a long
timeout. A lot of that is tied intimately with address selection. If you pick the right
address, everything works beautifully. The trouble is it's very hard to pick the right
address in all situations. And so, there's clearly a revision needed for the--for 3484
just to clean up some lose ends that we know about in the sense that this is a relatively
old RFC. We deprecated site local addresses, there's ULAs in the meantime and there's some
tweaking that we should do just to bring it up to speed with the current documents that
are out there and in a way that is not breaking the current implementations that are already
out there. A longer-term work item is--well, do we actually make--make some fairly substantial
changes to address selection because what we're doing is simply not workable. And so,
one example I give there is what Apple has done is they aren't really doing 3484, they've
done it completely differently and they send out parallel queries, okay? You know, it's
that something that's really needed to be done and if so, how are you going back getting
that done? You know, there's also--observe, there is no--you might take on the 3484 work
is when we did it, you know, we understood that other selections are hard problems. And
fundamentally, the problem is is that you need a lot of information in one place because
you'll have to make an optimal decision and that information is not in one place; it's
scattered around the system. We have no way of getting it into one place. And then, furthermore,
if you look at where the decisions are made, they're not made in a centralized place, you
know, by the application, they're spread in different pieces of the APIs and it's hard
to bring them all together because they're in different components of the system. So
I'm relatively skeptical that we're going to find sort of a magic bullet that's going
to fix these problems we're seeing here with the address selection. With that said, we
have to make it better than what it is already. DHCP, one of the things that's been missing
for a long time is there is no way to bootstrapper, you do network boot over the IPv6 because
the options were never defined. We have PXE in v4 that's heavily used but that work is
now mostly done. It's gone through the ISG and there's in other revision, you needed
to take care to discuss it and comments. There's been some discussions about the multiple interfaces
working group. This again is--were tied to multihoming and what happens if you have multiple
addresses. And there's different places you can go out and different routers you can use,
and use the wrong one and may be black hold or suboptimal and so forth. There's a working
group that's chartered to document the issues and also to sort of evaluate what are the
current practices that are done and how helpful they are. They aren't chartered about opening
new solutions yet. Again, I think, that's an important area to look at if you're concern
about this. My own view is this again is a very hard problem and it's not clear that
it's going to be--well, it's clear to me that's not going to be an easy straightforward solution
that works the way we'd like to in an ideal world, but the question is what can we practically
do with anything here to make the situation better than it already is. And we found some
lose ends, these were individual things. And there's a--one of the questions that keeps
popping up again is our /127's legal on pt-to-pt links. And, you know, there's some people
that say, "Yes, the specs say they are." There's some people say, "Well, no, or it's not clear."
And so, obviously, we either need to clarify this or agree that it is an issue that needs
to be fixed up. DHCP default router option, that's a document that route [INDISTINCT],
put out for, you know, over a year ago. And at the time we brought it up, there was some
support for it, but there's also a lot of opposition for it and we sort of dropped it
for lack of interest and lack of consensus. And again, you know, this week I'm hearing,
"We need to do that." There is still this need to have the same feature in v6 that you
have in v4 so if somebody has already gotten any infrastructure built using this kind of
an option they can just can do so without having to re-architect something even if isn't
all that hard to do. Why do you want to impose variants when they're not really needed? Another
tough question that comes up is unique local addresses. There's a centralized version and
there is a probabilistically unique version. The probabilistically unique one is out there,
you know, if people can use those and there's continues to be questions and request for
a centralized place to get one so that I can get one, I can be guaranteed it's mine forever
and nobody is going to be able to take it away from me and that sort of thing. Well,
we've been around and around on that one. The IETF is disgusted in essentially table
for lack consensus. But in the last few months, it came up again on the air and so I, you
know, AppML where they wanted to have this pushed through again. So, you know, do we
need to do this or not? Can we just sort of, you know, close this in some sense for good
so we don't keep having the same conversations over and over again. And that's it. Thanks.
>> I just want to note, that I think it's about two years ago that I went ballistic
and said, you know, NAT-PT got deprecated that ta-da, ta-da, and it's taking the IETF
two years to turn around and redo it correctly and I think that's pretty good. I think it
actually is. It's much better than we normally think of the IETF. It hasn't taken five years,
it's not bad. >> We do better work when it's under the gun
and we're under the gun. >> Yeah. So, all in all, what the heck. You
all right, little sunshine? >>
All right. So, trying to approach this issue from a wireless or a cellular prospective,
what do we have to do to make IPv6 happened in cellular networks? You know after all these
discussions that we've had. You know, we've had plenty of works of over the last year
about this, and you know, even more in the last 10 years we have lots of technology.
But still not much, if any, commercial deployment, why is that? What can we do about it? And
I have a series of answers and the first one that it's, it's really there, it's up for
you to turn it on. That's the only thing you need to do. And some justification for this
answer, the standards have been in place since '98, basically. The cellular networks channel
has all supported this since 2005. You can buy a phones without IPv6 support. We, at
Ericsson, have been doing this since 2003, you can do it too. There are issues, many
issues, but they are practical. They are not fundamental or standard related just get on
solving them. And please stop developing theories about, you know, alternative designs or "optimizations"
that you think you need or other things that just delayed deployment. You know, you just
need to go and do it and that's it. Well, moving away from the sunshine, I guess. There
are other answers. So there are obviously some enhancements that would still be useful.
So we keep inventing new ways to use IPv6 or new ways to basically use our networks
or the Internet. We add home routers and I mean it's not just mobile phones anymore,
it's routers. We're replacing our DSL connections with 50-megabit wireless connections, and
suddenly you need something. You need NAT64 and you need prefix delegations in v6. IPv6
only networking, you'll need Nat64. Or you gain some additional operational experience
and you realize, "Oh, we didn't actually do all the standards yet that that we should
have done right," the thing is the case with DNS discovery. And there is ongoing efforts
around this, you know, IETF, 3GPP and so forth, which just had a few months of joint meeting
with the 3GPP and IETF that basically concluded that the components are there or the technology
is there. You can just switch it on, some networks are already running it. But there
are few things that we could add and one of them was this translation technology from
[INDISTINCT]. And the third answer that I want to give to this question, what can we
do or why is this like this? There's multiple goals the one could have. So we tend, or end-users
tend to think of this IPv6 problem assets enable v6 for me, but there's actually multiple
possible things that we can do to v6 in mobile network. So, the mobility or the mobile networks
are nice in the sense that they separate the use of traffic from underlying core network
by this mobility tunnels. And then so there's also this APN concept that separates different
types of traffic like an operator on services and the internal purpose Internet access.
And all of these things mean that the IPv6 can actually be independently deployed on
the underlying network, you know, between the nodes that do all the signaling that you
need to move or allow the mobiles to move around. The users' traffic to the Internet,
you know, that is, of course, depending on what is the servers on the Internet doing.
Are they on the v6 or v4 or what? And then operates its own services, voice, [INDISTINCT]
and so forth. And then, finally, the fourth answer what do you really need to do? I mean,
I want to end in, sort of, positive note that most, if not all, big operators have very
serious efforts underway. I mean, you've some of it, [INDISTINCT] two days that they really
are looking at this. They're doing their preparations there. They are deploying and some of it will
really publicly visible. So, things are happening and what these operators actually need to
do? They need to have the right network planning, goals and motives for the different cases
that I talked about in the answer number three. We need to turn on v6 because much of this
code, I mean, it's been tested and it runs but when you actually run it in production
you'll end up the same problems. So we need to mature the code base but turning it on
and actually getting that experience. And the big stuff is actually not just transporting
the packet but it's turning on that billing system that enables that roaming to work,
having procedures for v6, having personal trained upstream connectivity, dealing with
white lists, you know, all kinds of practical things like it. That's where the efforts is,
that's where the problems are. And, of course, we don't have all devices today supporting
v6, it's a small fraction. So that's another thing that needs to improve. It might, you
know, it might be Frederick's efforts and Google can help there and, you know, we can
make at least Android to do v6 and multi-wise it in the future. And we need to do that for
other product as well but, one by one. That's all I have.
>> Thanks, Yuri. From an ISPs prospective, by the way, I'd note that the back-end stuff
and the billing system, et cetera, et cetera, are the main good thing. We're pressed. We
have a half an hour left, so, just be conscious of that. And they do have a clock stuck over
there. Maz? Oops. I got to figure out how to get out of this. Thank you.
>> Thank you. >> Five what?
>> Oh, okay, this is Maz for IIJ. >> YOSHINOBU: So I direct to share needs from
backbone fast. I'd like to know I want all network so we need measurement. And the people
would suggest to deployed dual stack network but the traffic flow different between IPv4
and IPv6. So, somehow, we'd like to know the volume or statistics. So there are standards
already, so I'd like to asked vendors to support these MIB or Netflow. And another point, we
need variable length support so 128 or 127 or whatever. These actually works on existing
routers, but the vendors said, it's not guaranteed, but it works. And the program will support
a few routers. Actually, I heard only one case that have restriction, that they can't
install this longer prefixes into its FIB. So you can check on LIB but the router can't
flow in, it's interesting. And, so far, from backbone that that's all. So, it's working.
We are ready to transmit IPv6. Good. >> I should be honest, you've been moving
IPv6 since when? '98? >> Like that.
>> Yeah. Ready for 12 years. Ron? >> Let's see if I could figure how to do this
here. You're probably better at it than I am, right? Oops, there's two of them.
>> Yeah. >> You can figure it out.
>> [INDISTINCT] >> Yes, right. Get the right one here. Set
the PowerPoint. >> All right. Do you want to borrow my glasses?
>> Yeah. No, it is PowerPoint, is it? >> Yeah, I'll just, yeah.
>> Right here, with the B and E. we go to--what was the trick?
>> No, I don't believe that control+L. Stop, that's for PDFs.
>> Yeah, yeah, yeah. >> And some little icon right here that you
click in it, it makes it show. >> Oh, yeah. I was just doing this one, too.
Here we go, okay. >> Want a portable?
>> BROERSMA: No, I can use this one. But thank you. Okay, so I'm gong to cover the IP in
the enterprise, IPv6 in the enterprise, what still needed. And it's just kind of based
on my experience and my environments and so forth, your environment maybe a little bit
different. But a lot of it, it falls into this general categories which I covered in
my talk yesterday. A big one being featured parity in all the mainstream vendor products.
V6 needs just to be as good as v4 so that it doesn't feel like we're going backwards
or that you keep running into these places where--in your infrastructure you think you're
fully v6 capable, and there's some feature that's missing that you think should, just
should have been there and it's because the vendor hasn't gotten around to implementing
it yet. And it's not only the functionality but it's the performance. We need it in hardware
at line rate just like in v4. So you know, take ASICs and that's why it takes, you know,
new product versions, hardware versions, to get that performance often. Also we've notice
a lot of problems in just a vendor QA of products. And this is because vendors are not "eating
their own dog food," they won't live own their stuff. And we found too that we--some of the
bugs we've seen is just, it's very basic. It's like, "Haven't you tested this in your
environment at all?" And it's because the QA suites are not mature. And I think if the
vendors had to live on their own stuff and feel the pain, stuff will get fixed a lot
quicker. So this is just kind of a general things across the board would get out, getting
into a bunch of specifics. Some other pieces, I'd like to be able to do DHCPv6. It's what
I wanted to do, you know, just eight, ten years ago almost but it requires broad client
support which is just not there. I mean, in our environment, mostly we have Windows XP,
Mac OS X, neither of those have DHCPv6 clients and so that was sort of a non-starter and
it remains that way. Because of all the Windows machines that once in a while get ICS turned
on and various other things that cause rogue RA announcements, we need something like RA
guard. And I know it's--there an Internet draft for that. We want to see that implemented
in the suite product that's fairly high priority for us. And for now we have to come up with
a workaround and operationally that's an impact. We really need to unify IP-MIB implement it
across product lines. That's the RFC 4293, I think Maz mentioned that as well. It's implemented.
It's kind of spotty. I mean it's CISCO. It's sort of in some versions but it's a huge challenge
to figure out what products it's implemented in. Juniper, you know, some products, it's
implemented, for example, the net screen product, it's just not even there at all. And so there's
no way to do some of the network management that you need with the common MIB that works
both v4 and v6. Also the things like all of the flow protocols. We need the flow information
to include both v4 and v6 for management reasons as well. IPv6 on public facing services, we
found that this has just been a problem not only for us but a lot of the other enterprise
we deal with. And it's, there's a number of showstoppers there. One of them, a big one
is Akamai. As a breakthrough who's behind the Akamai there's just no way to get v6 support,
that's the initial showstopper. Or the Co-Lo or hosting facility they're on, their network
just doesn't support v6. Or the load balancers don't support v6. Or the network engineers
that really want to do v6 have no influence on the local ITs or marketing staff that runs
the web server; this we run into over and over again. And they won't consider simple
alternatives to get started like a simple v6-v4 proxy just to even front in, just to
get going. So, usually, for a lot of companies it just stops right there. OS vendors. For
Microsoft, if I had enough money and I was king for a day, I just, outlaw XP because
I get everybody on Window7 because of IPv6 not on by default so you have to convince
somebody to turn it on. There's no DHCPv6. There's no DNS over Ipv6. Easy to become a
rogue router with ICS turned on. And so, we'd love to see the world get up to a later version.
If--what I really love is to find a way to turn off the privacy randomize to address
centrally. Some people are saying we'll just do it in an active directory, but in my own
environment, you know, I got thousands of customers that are all independent autonomous,
not part of AD, that's why I need a bit or a knob somewhere in the network. Like, you
know, like we have the MNO bits and other bits in the router advertisements. I'd like
another bit that just says, "Please don't do a privacy or randomize addresses," because
in an enterprise there's many, many reasons why that's a killer. And so, I need to have
that turned off without visiting every machine. For Apple, Mac OS X has just been getting
worse over the years, and especially with 10.6 and the mDNSResponder brokenness, also
the 6to4 preferences we've been hearing about, really need to get Apple to fix those bugs.
We need to get DHCPv6 support. I'd love to have ISOTAP support for some of our transitions
scenarios that would really, really help. I think Apple internally, it'd be good if
they dual-stack their own network, ate their own dog food, have their people living on
it and then, and then whitelist them and so that they feel the pain. Also, I'm sure hoping
that v6 works well in ISO4 as promised and we shall see. There's, the just do it, which
I think that really, in order to get into an enterprise, you need a corporate culture.
It's got to permeate the entire IT culture and organization. You can't just have the
engineering staff make progress. You need to get buy end from the CIO and the CEO on
down. You need a local champion or an evangelist. And, in every IT initiative in the organization
it has to have an IPv6 story and especially when you're doing tech refresh. This doesn't
have to be expensive. It takes time if you do it with tech refresh but every time you're
buying something new or doing an upgrade, make sure it's done the v6 way. For training,
we got it simplify it. We can't send people with this many multiple-day classes because
by the time they come home and actually get a round to it a month later, it seems overwhelming.
They would have forgotten everything. They don't know where to start. It's better to
just give some simple easy steps and force a lot of people. I think we can tell them
what are some of the easiest steps like, you know, do a triage. Do the simple things first,
the low hanging fruit. And so do things like worry about addressing then your connectivity
via the ISP, then do a testbed, then do some training, then enable your public facing services,
then worry about your security parameter, and then your internal networks, then your
systems and apps and sort of build out from there and that certainly works a lot better.
So that's the enterprise story. >> Thanks, Ron. I'd like to just make one
comment which is, when all these nice folks and vendors stand up here and blows smoke
up my skirt is that when you say that you want line rate in A6, when the vendors, yes,
you, Mark, talk about backbone et cetera, et cetera, they think "Oh, there's two percent
on the backbone, nobody's going to really notice that this thing won't go for the work
for five years." When you deploy in enterprise and you deploy v6, your LAN starts screaming
v6, and the thing better run line rate. Lorenzo, you're going to play it on your own?
>> Yes, I mean. >> You know what you're doing?
>> I've been talking too much anyway, I think I met somebody and she said, so I didn't know
who you are because you never introduced yourself to me but you talk all the time, so obviously--I
knew you. So just briefly, thing is at least for us, I mean we in the content provider
has, you know, they do a lot right, they--we run at least, you know, here we run a network,
you know, looks like about we're a network at least someone it does, so we need hardware
forwarding, we need Netflow, we need filtering on extensions [INDISTINCT] said thank you
very much they're not just the first one because otherwise if something comes in with the routing
header, our only recourse is to drop it. So hardware support there and feature parity
then you know, load balances, yes. Load balance server with --first of all load balances with
IPv6 support, you know, just to get started and then it would be nice if you could use
v6 to tuck your packings as well, so if you don't want to terminate SSL on your front
end load balances then you can do that too. So and then, how's the load balance going
to talk to this network, well, I mean, do we have VRP? Well maybe we don't have that
yet or maybe we can't do with global addresses, so VRP but this is what we've been saying
for a day and a half now which is feature parity because unless you have feature parity
you don't know which feature are you going to need tomorrow. The only way that to know
that your design --what you design tomorrow is going to work with the gear you have is
if the gear you have supports everything in the same level. And I understand that might
be difficult but really that's the only way out of this. So and finally, and this is,
to some extent can be worked around in. This our own engineering and something that we
really can't work around by ourselves is broken that is out there in the field, so broken
CPUs out there, they'll never be replaced and there's nothing we can do about that,
right because they're in home networks and the ISP doesn't own them and we don't own
them and the users run them and the users doesn't know what the problem is, so we need
to fix that and I think US manufacturers need to help there. Although we haven't really
had a lot of success there yet, so basically give us feature parity and networking if you
do MB five passwords do them for v6 as well, don't just implement them in one place and
then oh yes, or if when you fix bugs, oh, this is race condition, we fixed it for v4
but we didn't think it might have for v6 and so on. So it boils down of two things the
feature parity in networking hardware and let's find a way to fix those broken users.
Oh, that's it for me. >> [INDISTINCT] do we have time for questions?
>> Yes, we do. >> Woh! Okay, we have time --room for 15 questions.
Or some answers. >> Cameron Burn for T-Mobile.
>> Can we get to a Flag Day? Can we revisit it and not think it's laughable? At least.
>> By Flag Day you mean, what happened at the non-organ what happen to the couple of
things... >> Not turn off IPv4, we're not going to turn
it off that's not realistic but can we get to a Flag Day where we earnestly turn IPv6
on. >> Ernest.
>> No, I'm not going to answer that, [INDISTINCT]. >> Well, [INDISTINCT] has answer for it.
>> We did it in 98, next. >> I just remembered in January 1, 1983 when
we turned off NCP worked great, there were stragglers, things broke but it got fixed
really fast that's why I think, you know. Don't be afraid to break some glass is kind
of my motto. At some point you really have to make that decision. I think for me on my
mind, you know, the day that Google feels safe enough to really just not to do white
list anymore is that to do blacklist that's kind of a Flag Day in one sense. What would
we have to do to fix all the backbones, the transport the brokenness out in the operating
systems and in all the home networks and so forth to where the brokenness is small enough
or at least equivalent to v4 that we could, you know, Google or others could feel safe
to do that, that would, you know. In a way be a Flag Day.
>> I think that if we fix the OS is and so one of the problems with the Flag Day is that
when do you call the day, right? Do you want to wait for Yahoo to have their stuff done?
And their red map was supposed to be here yesterday and it's next year right, so do
you want to wait that year? Do you want to start or do you want to start now gradually
and as regards to Google right if we can get working packets to users that's the main thing
that's missing, right. It's not that we have issues on our site.
>> Matthew from [INDISTINCT]. I agree with Cameron, I think we should stop fearing fear
itself and actually get on with it because if we don't we are going to continue to sit
in fear of turning it on and that appears to be the problem at the moment. We are deadlocked
with fear, there is a tiny percentage of people who may not work and we kind of need to do
it because if we don't stop to move forward now we are going to be just as much to a problem
as running out of IPv4. >> May I say something? Ron you almost said
it, I walked up here to say, why don't we put if we're going to talk about a Flag Day.
Define what Ernest means, and I think it's AAAA flag day. That's what we really talking
about, right? So the day that all the content provider say, okay, there you go and it's
advertised and there you know, you know that there might be brokenness out there everybody's
waiting, everybody's-- the service providers are expecting problems, it's even in the press
whatever, the AAAA flag day. Decides amongst yourselves when that is.
>> How about the SMTP received header flag day that when I get email from inside a vendor,
I look and I see the actual vendor's desktop machine came from an IPv6 address, so that
I know you were eating your own dog food and maybe your products would work.
Time and time again we heard the vendors aren't eating the dog food. And that means that,
you know, the consequences are pretty obvious and you Lorenzo, we're trying to get Google
internally. You hit a speed bump and you're coming back off it but, you know, and we're
doing it inside. When I first moved to Tokyo I found out part of IIJ and slipped back from
v6 and must I had to push, okay. Yet, it rolled out internally, so you're eating your own
dog food whether you're an ISP, whether you're a vendor, whether you're a content copywriter,
or whether you're Dino. All I can say is we lead by example. You know I can't--don't buy
from a vendor whose email headers aren't v6. >> But then you might say don't buy a vendor
whose going to v6 routing table and that's our network worked out, so I mean, you have
to go some... >> You have to say I will buy this many --buy
this amount of equipment and that gets the VPs to listen, it really does. That's the
lever you have. Now I'm feeling uncomfortable at saying that because I don't want to be
just greedy prostitute but that's the real world.
>> We've known you for many years you are a greedy prostitute. The point is, don't buy
the kit unless they're for real. It's not just go to the VPs and say I will buy ten
more billion dollars worth of your rubbish if it will use v6--it's I will not buy.
>> Negative doesn't work, you have to be positive. It's not fear that the vendors care about,
its greed, and look at the greed side of it. >> When I stopped orders, John Chambers moved.
>>
I have to say it wouldn't have worked for us. That would have been a non-starter. Yes,
we spent--approximately zero on hardware. >> We got an Ernie so that maybe that's why
it work for us but that wouldn't have work for us, I mean, saying, saying a bit of "hey,
here's this big carrot". There's internal buying as well, right? You don't --you're
not hundred percent committed you just have to beat your vendors on this submission that's
not the way it works. Because everyone is saying well, I don't want to take the steps
so wait for someone... >> Now Loren, Lorenzo is still talking I'm
not going to stop. I'm not going to talk while Lorenzo's still talking.
>> Ralph, okay, Ralph Wallace Command-Control. WALLACE: QUICK, just a quick question. How
many solution providers are in here? A solution provider is somebody who goes out to help
people transition the IPv6. They provide a service to people to help them transition
IPv6, who else is in here? John, you're but you're kind of--I understand John. Way to
say, so I'm--who else? What, a new, you okay. So there's two, in this entire place you got
two, my company our company and this company over here you got people here who are listening
in so that we can go to enterprises, public or private and help them transition IPv6 and
so I'm hearing you guys talk back and forth, you know, Flag Day things like that. I know
by NCP, right. So we go to places trying to help people transition IPv6 and give them
the reason for that and I'm hearing you guys argue, all right and so here I am trying to
help people see the transition IPv6. I just want to make sure that you guys got a perspective
from us because we went out and we trained DARPA, remember the ARPANET? We trained DARPA
on implementing IPv6 to their IT staff and how to secure IPv6 based on all the RFCs,
right. There's Cisco on the Microsoft shop, their choice not ours, right. When we don't
want to train their IT staff we trained them for two weeks and they came out off the training
and they went, "holy crap how come somebody hadn't told us this before? ". This is the
IT enterprise infrastructure staff for DARPA. My point, here we are here talking about certain
things, you know what, there's a lot more education that we need to do out there folks,
so if that's a wake up call I hope it is. >> I think we forgot the training, Scott did
we do any training, is he there? >> I, yes, simply forgot the training part.
>> [INDISTINCT] >> No internally I mean, I can't remember
us. Yes, we didn't do any training. Yes, okay. >> How about on the job training?
>> Yes, we--yes we [INDISTINCT] oh we have the same.
>>[INDISTINCT] >> And we can deliver okay. Well, nicely put...
>> [INDISTINCT] my point, training for transition process you don't' give them the wake up call;
if you don't have the people they're going to be transition common language, add talk,
what is the ULA? Right, Why is IPV6 important? >> Yes, not us.
>> Yes, thinking about the Flag Day thing, what we ought to do as a community is think
about where we would like to be a year from now? And a date that's close to that is June
6 of 2011 which is five years after the Cisco was turned off. You know there's a good date
that could be in people's mind if you want to start socializing. So what could be accomplished
by then making a media event, it will be right after the INO runs out. I mean there could
be a lot opportunities there, so there's the date but what do you want to have done by
then I mean, I think we've been thinking about that. Set a line in the same maybe we turn
something off on that day or maybe that's something where, you know, if you don't have
[INDISTINCT] features okay. >> The line's closed. We got three minutes
left. >> Okay, turn it over.
>> You loss Martin. >> Five!
>> So I'll be quick, Bob ended. So to the company I work for the thing that really got
us motivated to put v6 on the product was, well, I would like to think it was me giving
presentations but what it really was, was the potential for losing sales or losing business.
You know our customers saying I will not--I'm going to switch to another vendor unless you
do this, so that worked quite well. >> But in your case it was a check mark and
in many of the vendors' cases it's weak implementation not--they got the check mark.
>> Yes, but we have some customers who have real plans that are going to need us.
>> Oh, I understand. John. >> So we've done what Dino suggested that
actually works, you know, I personally withheld payment on things until it worked. I've also
taken--we've also taken our business elsewhere not me personally but somebody else in the
company take--lay down business elsewhere, that also works. You know, I also think that
some, you know, we, you know, to somebody's point here we talk a lot I think I actually
doing it actually helps and for whatever it's worth I mean, we're ready when you are, all
right. >> Dude, where's my cable modem?
>> It's in my hotel. >> Talk is cheap, talk is cheap.
>> It's in my hotel room. >> It's still there, where is it? How about
you? >> It's still there. It's in my new hotel
room at the Westin Saint Francis, so. >> Talk is cheap.
>> So, so I mean, yeah, and I'm not being cheap, I don't think. So, I mean like I said,
I'm ready when you are, right. I mean, I welcome AAAAs, right? We know that these problems
are out there, we all do, right? And part of what we were, you know, we've been thinking
this is, you know, and we've heard this year as, you know, sometimes you got a, somebody
keeps saying you got to break a little, you go to break some eggs or whatever. I think,
there's something to that. >> Okay, just to end on a positive note, how
many people here think things are better in Japan? Good, we solved that one. Pardon? The
food is much better. My wife says that's why we live there.
>> [INDISTINCT] >> Yup, okay good. That education got done
finally, it took a while. That's about it. Erick, do you want to wrap?
>> Well, yeah. Thank you, Eddie. Thank you, guys. I got it. Thank you. So, this is very
interesting in different conference from the last year. Some things have been definitely
changing. There's definitely seems to be more of a--awareness is clearly shifting, right?
There's focus is shifting and especially it has to point when it comes to [INDISTINCT],
there's issues about education, and previous talks about education was about, you know,
awareness education and now it's about operational education and that's definitely different.
I felt more focusing on real details like last mile issues and some of new Apps, that
kind of stuff. And there are several people to thank. I'd like to thank the external folks
who helped us plan, helped us choose talks and get things together and provide contacts,
and all that kind of stuff, that's Randy, Edward, John, [INDISTINCT], and others. And,
[INDISTINCT] and I have to thank our event staff, Cassandra, who is not here today, and
Sabrina who's coordinating your t-shirts which are outside in the lobby. I would like to
thank all of the speakers, everyone who came with enlightening talks, and then presented,
and so on and so forth, and panel for this defense, this talk isn't anything without
you guys. So, thank you so much and thank you all for coming. One of the things that
I never thought about starting v6 because I thought it was just kind of cool technology
but, it turns out there's a lot of cool people that you need doing that to. So, that's been
fantastic, thank you all for coming.