IANA IPv6:  Workshop, Part 2

 28 October 2007

 ICANN Los Angeles

 

 >>LEO VEGODA:   

 >>LEO VEGODA:  Hello, everyone, Leo Vegoda.  

 We're going to bring the session to a start in just a couple of 
minutes.

 So if you -- I'll start off just by saying that, again, this session 
is being webcast and there are remote participation options through the 
public.ICANN.org web site or the LosAngeles2007.ICANN.org Web sites.  
You can ask questions in the chat room and also post comments and make 
blog entries.

 If you are not a native English-speaker and would prefer to listen to 
this session in Spanish, French, or Russian, there is translation into 
Spanish, French, and Russian.  And you can get a translation headset at 
the back of the room.

 If I could ask our translators to come to the microphone at the front 
and make sure that people know which channels they're translating on, 
that would be great.

    (Translation).

 >> I'm going to make an announcement for the Spanish speakers in the 
room.

    (Translation).

 >>LEO VEGODA:   Thank you very much.

    If you want to come to the microphone and ask a question in one of 
the translated languages, if you could pause slightly after you start 
asking your question, that would allow our stenographers to select the 
right channel on their headsets, and also everyone else, if they're 
listening.

    I think that's all the introduction we need.  So I'll move to 
introducing the panel for this second session in the IANA workshop on 
IPv6.

    To my right, we have Takashi Uematsu.  Takashi Uematsu is from NTT 
and is going to talk about the FLET's premium service, which is a 
service delivered over IPv6 and to my far left, Jay Daley from Nominet, 
who is going to talk about the issues involved in introducing IPv6 into 
Nominet's network.  And to my direct left, Dave Piscitello from the 
ICANN SSAC, who is going to talk about a survey that he's done for SSAC 
on IPv6 support in commercial firewall products.

    I think we can move straight on to Takashi Uematsu's presentation.

    So if you are ready to go.

 >>TAKASHI UEMATSU:   Yep.

    Thank you for inviting me, Leo.  And I'm so happy to share.

    I hope my presentation can be practical for you.  So what is FLET's 
Hikari premium.

 I built some feature, especially may be technical for you, but let's 
start with, it's fiber access.  We take out the GE-PON and also give 
Internet access and spread into VDS with 100VDSL for apartments.  
That's IPv6-based.  And also, it's broadband network service.  And we 
provide native IPv6 routing network.  But it's closed circuit, closed 
network.

    And next, we have -- FLET's Hikari premium services is access line 
services.  It's the latest, we started this March 2005.  And our 
service area is 30 prefectures, which means the coverage of NTT-west 
business areas.  Now we have over 2 million subscribers and over 1,000 
buildings we installed IPv6 routers.

    So here our history of service.  We started with ISP access service 
in December 1999.  It was started as the ISDN flat-rate service for the 
user dialup.  So we put the PPP frame into I.P. network and aggregated, 
so we made it as a broad service.  Since then, we put the VPN services 
and also CUG services, and the communication tools.  I mentioned a 
little bit later.

    Service -- we have ADSL and media converter basis, and PON, VDSL 
for apartments, Wi-Fi for public.  Basically, started with the IPv4 
core network.  This is before premium.  So what's new in Hikari premium 
compared to the -- to the -- what FLET's used to be.  Hikari premium 
has much more broadband ability and always-on feature, and has native 
IPv6 services.

    And then talk about the IPv6, we have multicast support on it, and 
QoS feature, and addresses, we have /48 assigned subscribers.  And we 
have CTUs -- this is a kind of CPE which serves /64 with NDP protocol, 
and also /52 prefix via DHCPV6 VoD protocol to the customer and 
terminals.  So let me describe a little bit about the architectural 
change.  Before premium, we had the tunnel gateway, top of the network, 
which connected to the ISPs or the enterprise network, which terminates 
the tunnels.  So the terminal has to go -- the packet has to go out the 
terminal gateway and down, back to inside.

    So we had the bandwidth bottleneck in architectural features.

    So we changed this to the user I.P. routable network basis, this 
premium, maybe most fundamental features.

    So now with IPv6 protocol, people can send packet directly end-to-
end.

    So let me continue about the what's new in Hikari premium.  CTU is 
acronym of customer terminal unit.  And it's a kind of CPE, as I 
mentioned.  It's IPv6 router in the home.  And also handles IPv4, which 
-- IPv4 tunnels over IPv6 network.  They also have the NAT, filtering, 
SPI, DHCP features.

    So we put the security suite software for PCs, which means the user 
may -- you may know it's a kind of OEM version of the commercial 
product that we put the package with the line subscription.

    And also, we provide high-quality video phone clients, both 
software and -- this client software, only for Windows, XP and Vista.  
TV channels, VoD services provided by ASPs, which are not carried 
directly by us.

    So this is a big picture of what we are doing through the FLET's 
services, especially according to the IPv6 context.

    The right side yellow area shows the IPv6 basis.  So FLET's Hikari 
premium has three services.  One is kind of FTTH, one is FTTH, but it's 
video server or other Internet services attached, and the right-most 
side one is enterprise, which provides just the Internet to the 
customer site, which is mainly aimed for the business customers.

    So part of the services are combined from the IPv4 basis and the 
IPv6 basis, especially service available from both IPv4 basis and the 
IPv6 basis architecture.

    So this slide shows a lot of technical figures to what's going on 
in our architecture.  The same as the yellow area shows, the IPv6 
network, and the blue one is IPv4.

    So the -- when we had only IPv4 network, people have to go up to 
gateway and down back to the client site.  But now we have the direct 
line, end-to-end communications.  But also, we have the gateway 
services to create the legacy services, such as ISP connections and CUZ 
and VPN.  And the right upper side, we have the content server.  It's 
called V6 cast interfaces, which can be subscribed by business 
customers.  They can put their own servers on the interface link.  Then 
they can provide their services to our customers, which are using 
multicast and also anycast.

    So here is the application example.  We had video phone software 
client, as I mentioned, which was a purely IPv6-based.  So we created 
it as no IPv4 required version.  So we put the SIP running only on SIP 
version 6.  And those we take up the MPEG-4.  So this version, people 
can make some conference call among four sites.  And also this software 
comes with some file transfer and also video messaging services and 
session recording done locally.

    So this is the customer cases of using V6cast interfaces.  So now, 
currently, three providers carry IPTV services.  Video only or maybe 
channel service, which is done by multicast mixed.

    And we have very few enterprise customers who use V6cast.  And one 
customer uses multicast ability to make data delivery network, which a 
famous convenience store chain to deliver contents to their stores.

    And last one is grid computing services called HIKARI grid.  This 
is HIKARI by NTT-west, ourselves.  And it's kind of a trial service to 
prove the concept to use peer-to-peer network through our IPv6 network.

    So that's all for today.  So I'm happy to answer my questions as 
much as I can.

    Thank you.

 >>LEO VEGODA:   Thank you very much.

    I actually do have one question for you myself before I open 
questions to the floor.  And that's that when you started off, you 
mentioned that it's a closed network.

 >>TAKASHI UEMATSU:   Yes.

 >>LEO VEGODA:   And, of course, with increasing IPv6 deployment 
elsewhere, is there the possibility that at some point you will open it 
up so that you will be providing an IPv6 Internet service as well as 
the closed network service?

 >>TAKASHI UEMATSU:   Yeah, I think technically, we can do that.  But 
I'm not quite sure to enable the features right now.  So we may have 
the -- another tunneling situation to put to another IPv6 prefix to the 
customers.  But it may close the multi prefix issues.  So just cautious 
to limit -- enable that feature.  So we have to -- personally, I think 
we have to discuss about this -- what can be done with our network.

 >>LEO VEGODA:   Fair enough.

    Are there any questions?  Yeah.

 >>DAVE PISCITELLO:   This is Dave Piscitello.

    You mentioned that you have a SIPv6 video phone service.  Is that 
only within the closed network?

 >>TAKASHI UEMATSU:   I'm sorry.  It's only within the closed, yeah.

 >>DAVE PISCITELLO:   And how popular is that, since it's just within 
the closed network?

 >>TAKASHI UEMATSU:   It's -- since it's just closed network, but it's 
-- provide every customer.  So basically we have 2 million subscribers 
who can use that video phone.

 >>DAVE PISCITELLO:   So you already have 2 million subscribers on the 
premium network.  So it is a very significant population already.  Very 
good.  Yeah.

 >>TAKASHI UEMATSU:   It's kind of packages, you know.  It's kind of 
software license-based and we put the license, one license per line, so 
they can be able to use that.

 >>DAVE PISCITELLO:   Thank you.

 >>LEO VEGODA:   Question from the floor.

 >> OLIVIER MURON:  Yes, I'm Olivier Muroni, from France Telecom.  

    I have a question about the marketing.  Are you using V6 as a 
marketing argument to sell this new network?

 >>TAKASHI UEMATSU:   Oh, --

 >> OLIVIER MURON:  And if yes, why?  How are you using it?

 >>TAKASHI UEMATSU:   The major reason why we take up IPv6 is 
multicast.

    When we think about to make a context-stable network with our 
network, we concluded to take up IPv6.  So besides the CTN features, we 
have to reason to take up IPv6, frankly.

 >>LEO VEGODA:   You've got to turn on the button before it works.

    Okay.  Thank you very much.  And if I can ask -- Jay Daley from 
Nominet is now going to present on Nominet's experience with IPv6 
deployment.

    Nominet is the organization running dot U.K.  So away you go.

 >>JAY DALEY:  So I'm aiming for the shortest talk today.

 We started taking IPv6 seriously about three years, and we started off 
with an inventory of all of our hardware and all of the applications 
that we used to see how well they would support IPv6.

 The hardware was very straightforward.  I don't think we found -- 
well, we found two or three old boxes that didn't support IPv6 and 
threw them away.  But everything else supported IPv6, normally dual-
stacked, straight away.  That was very helpful for us.

 The applications, though, were much more complicated.  None of those 
supported IPv6.  And a lot of work was later needed to deal with those.

 We then amended our registry process to accept IPv6 glue and started 
publishing IPv6 glue in name servers.  Even though all of our name 
servers were still IPv4 compatible, we thought that was useful to get 
other IPv6 adopters up and running.

 The big problem we found with doing that was what format to accept the 
addresses in.

 Particularly when it comes to dotted quad notation embedded inside 
IPv6 addresses.

 We had a number of people write to us quoting relevant RFCs asking us 
could they specify their addresses in a particular format.  And we 
couldn't decide, so we wrote to the authors of RFCs and they couldn't 
decide either.  So we invented some rules of our own that were as 
liberal as possible to enable people to do things the way they wanted 
to.

 But once that was done, that was pretty straightforward.

 And we had five or six registrars who wanted to start using that 
straight away, which out of our population of 3,000 is very small.  And 
not that many domains, but they were relatively vocal people and they 
wanted to make sure that they were early adopters.

 So then two years ago, we did the hard stuff.  We re-wrote all of our 
applications that stored I.P. addresses to enable them to store IPv6 
addresses.

 So our WHOIS uses I.P. addresses as a means of controlling access.  
And that needed an entire rewrite for various other reasons, so we 
incorporated an IPv6 module into that.

 We also changed our registration systems.  Just basic things like 
logging or formats of where queries come from, of the fields and the 
database had been set to assume IPv4.  The fields in some of the output 
files had been set to assume IPv4 and that all needed to be changed.  
And we also had an availability checker, similar to WHOIS, and they all 
needed to be rewritten to sure they could use IPv6.  That was the most 
difficult part.  And we are relatively lucky because we didn't have any 
off-the-shelf packages that stored IPv6 addresses and if we had then 
that would have made life much more difficult.

 We then installed IPv6 support in some name servers, dual stacked 
them, and we found those that were the easiest to do and did those ones 
rather than to make our life difficult.

 So we were up and running some years ago with IPv6 support on our name 
servers.  For us that was pretty major that we got so far.  But then 
what we wanted to do next all went very badly wrong.  Our plan then was 
to give people Native IPv6 access to our registry systems.  But the 
RIPE NCC policy at the time meant we couldn't get an IPv6 address 
allocation.

 We manage our own autonomous system, our own I.P. address space, and 
we have multiple transit and peering connections.  And so we needed 
provider independent space.  But the policy at the time, still is now, 
is that you needed to have 200 customers you were going to allocate the 
customers to.  We are an enterprise user of it.  We don't allocate the 
addresses to anybody so we couldn't get any further with that.

 We also wanted to put IPv6 on almost all of our name servers.  In 
fact, we wanted to leave just one that was only IPv4, in case there was 
some horrible problem with dual stacking that nobody had noticed.

 But we then found that a number of our third-party hosting sites 
didn't support IPv6.  These are sites where we just have a set of 
equipment in a rack and we play for electricity, the rack, and P.A. 
space and they weren't able to provide us with IPv6 either.

 So our IPv6 deployment plan stopped for a year.

 So what we're intending to do now, hopefully over the next year, is 
get an IPv6 P.I. allocation.  A RIPE policy change is imminent on that.  
We are going to change the hosting providers who couldn't give us IPv6 
and get some who could.  It would all be important for uys to do, but I 
think it's important that we do do that.

 Then we are going to go native IPv6 so people can access our registry 
systems over IPv6.

 I suspect that will probably be four or five people, but it's 
worthwhile us doing it.

 And that's going to be dual-stacked and stay dual-stacked for the 
foreseeable future.

 Then the fun starts really which is when we start to work through the 
security issues.  We don't use NAT.  That makes life a lot easier.  But 
we are not 100 percent certain how it is going to work with firewalls 
or intrusion detection systems or any of the other devices we have 
there.

 We know they will support IPv6, but that's a very different matter 
from understanding how to use them.  And I think that may stir up some 
very interesting issues.

 We also need to understand traceability of people and computers by the 
way that IPv6 uses the last 64 bits.

 I'm not sure this is going to be that much different from static 
addresses on IPv4, but it may turn out to be different.  So we, indeed, 
to understand that.

 And we also need to deal with people who harvest data from our 
systems, people who attack our WHOIS.  How they are going to now spread 
their abuse across both IPv4 and IPv6.

 Currently, if they spread it across IPv4 using contiguous ranges of 
I.P. addresses, we can spot them.  But if they are going to be 
switching backwards and forwards between IPv4 and IPv6, that's going to 
be slightly more complicated.

 So we, indeed, to look at how that has to go.

 So I think for us, it's actually turned out to be relatively simple to 
do IPv4.  The big surprise was how easy it was to get the hardware 
working that way.  I know in the earlier session, somebody was 
complaining that there might be a very large cost to switching over the 
hardware to IPv6 compatibility.  But we certainly didn't find one.  We 
found that everything, just about, supported it.

 The application layer is the much more complex layer.  And once the 
policies are in place and we can get the addresses, I think we are 
going to have some fun in getting it up and running.  It's certainly 
not been the disaster or the real difficulty that many people thought 
it would be.

 That's it.

 Any questions?

 >>WILFRIED WOEBER:  Wilfried Woeber from (saying name) University in 
Austria.  Just out of technical curiosity, what is the real issue with 
traceability?  Sort of what do you really want to trace and why?

 >>JAY DALEY:  I don't -- good question.  I think that's something we 
are going to find out.

 If you have the last 64 bits representing the Mac address of a 
computer and somebody is changing the first 64 bits through DHCP at 
regular intervals, they are going to be traceable in a way that they 
weren't with IPv4.  I don't know if that's going to be a problem with 
us within our organization.  I suspect it's much more likely to be a 
problem for customers of ISPs.  But for us it might not be.  But it's 
still something that we need to keep an eye on.

 >>WILFRIED WOEBER:  I was understanding sort of your point the other 
way around, that you were interested in tracing something to the 
source.  That was the reason for asking.

 >>JAY DALEY:  I hadn't thought about that, yes.  Yes, we can trace the 
people who do some forms of abuse against us that way back.  Yes, thank 
you.

 >>WILFRIED WOEBER:  Thanks for the explanation.  And just another 
minor issue with regard to the various formats of IPv6 addresses.  Did 
you find sort of any -- or did you see any concerns that these 
different formats would be ambiguous in the end?

 >>JAY DALEY:  No.  We didn't.

 And we made the decision that we would accept multiple formats from 
people but we would then normalize them ourselves and store them in our 
own representation internally and publish them, anything we did, in our 
own format, not the format they were given to us in.  And I think that 
made life a lot easier.

 >>WILFRIED WOEBER:  Thank you.

 >>JIM REID:  Jim Reid.

 Jay, just a question on your plans for IPv6 hosting for DNS servers 
and stuff like that.

 Are you going to write this up into some kind of form of procurement 
process and with the specifications you are going to require for your 
IPv6-based providers, are they going to be openly available?  Because I 
think this is the kind of thing that may be useful for anybody else who 
is thinking of going through some kind of IPv6 provisioning for Web 
servers or something like that.

 >>JAY DALEY:  The answer is no.

 We are only interested in hosting of -- so just a cable coming in, a 
rack and power cable coming in.  We are not interested in the level of 
services they do.

 So we wouldn't be tendering for anything that required something 
special that a registry could do in that way there.

 >>JIM REID:  Sorry, what I was meaning is so you plan to use your own 
IPv6 addresses at these hosting locations or you are going --

 >>JAY DALEY:  I.P. space provided by the hosting location.

 >>JIM REID:  Right.  But is there anything specific in terms of your 
requirement that you may want to formalize there?

 >>JAY DALEY:  No, I don't think so.  It's much the same as currently 
we expect to /24 of IPv4 space and globally route them when we do some 
test to check that, and it takes ten minutes to do.  And I think we 
will just pick a prefix length that we require of IPv6 and some tests 
and leave it at that.

 >>JIM REID:  Okay.

 >>LEO VEGODA:  Jay, I have a question about your slide, one or two 
slides back, about when you are detecting abuse.  Is this something 
that you are working together with other registries, like other ccTLDs 
or the RIRs so that there is some sort of best current practice 
document, best current practice that you can share?

 Because I assume there probably isn't a great deal of IPv6 traffic at 
the moment to WHOIS servers and registration systems.  And everyone is 
learning together.

 >>JAY DALEY:  Yes, we are working with other ccTLDs, but I think a 
best practice document is some way off.

 There was a CENTR technical workshop last week where a number of 
registries presented their mechanisms for detecting and controlling 
abuse of WHOIS servers.  And it varied enormously.

 One country has turned their WHOIS server off and other countries 
control it by bandwidth, others like us control it by source address 
and nearness to other addresses.

 And I think that we need to wait to see how we begin to incorporate 
other people's ideas first to see if we end up with a multi-layered 
strategy of different people's ideas, and then produce a best practices 
document.  Otherwise, a current best practices document basically would 
be ten different best practices all in one rather than one set of best 
practices.

 And so if we haven't even done that for IPv4, doing it for v6 will 
take some much longer time.

 >>LEO VEGODA:  Okay.

 But you are working with the other --

 >>JAY DALEY:  Yes.

 >>LEO VEGODA:  -- registries.  So there is experience being shared.  
And that's a good thing to hear.

 I think that leads us nicely to Dave Piscitello presentation on IPv6 
support in firewalls, in commercial firewalls.  And follows on nicely 
from the end point of Jay's presentation there.

 >>DAVE PISCITELLO:  Some preliminary discussion before I begin the 
presentation proper.  In the June ICANN meeting, ray Plzak of ARIN 
spoke at one of the open mike sessions and talked about the accelerated 
depletion of IPv4 addresses and the need for organizations to move to 
I.P. version 6.

 I was sitting in the back of the room and started mulling over how 
many firewalls I had actually touched in the last three or four years 
that were IPv6 capable.  And having touched many firewalls and many 
vendors and done a fair amount of product evaluation for both firewall 
products as well as IPsec products I became a little concerned that I 
couldn't remember any.

 So I went home and I started a small skunk works project and I pulled 
out the five brands of firewalls I have in my house, and I cranked them 
all up and couldn't find but one that actually had any form of IPv6 
support, and that was rather minimum.

 And I appreciated that I might have old version software, so I started 
thinking about the possibility of doing something a little more formal.  
And the idea of that, thinking of that and turning this into a formal 
SSAC product is what I am about to prepare and present.

 Okay.  Is this better?

 So the purpose and scope of this study was, first, to determine IPv6 
transport support and security service availability among commercial 
firewall products.

 We conducted a survey only.  We did not do any formal product testing.  
That's well outside our scope and would require considerably more time 
than any of the members of the committee might have.

 We included commercial firewall appliances, self-standing devices or 
devices than ran commercial firewall software.  We explicitly did not 
include personal firewall software, and open-source firewall projects.

 We also were unable to get a sufficient amount of information out of 
the broadband access devices that are essentially commodity or sub $100 
products that truly only support things like blocking ports and doing 
very, very coarse level filtering so they are not in this survey.

 We had four main objectives.  The first was to determine how broadly 
IPv6 transport is supported by commercial firewalls.

 The second is to determine the level of support of security services 
across all market segments.

 I'll speak to that in a moment.

 The third was to determine whether the security services commonly used 
today in firewalls to provide security policy enforcement in IPv4 
networks were also available in IPv6 networks.

 And finally, from that information, we wanted to see if we could 
conclude that an organization could use IPv6 today and enforce a 
commensurate security policy to one they were already enforcing using 
IPv4.

 Obviously, the place to begin was to compile a list of commercial 
firewall products.  We used a number of sources to actually acquire the 
list.  We -- Having spent a lot of time in the firewall community, I 
used firewall mailing lists, I used known firewall product evaluation 
Web sites, I contacted ICSA laboratories for the list of firewalls that 
they include in their firewall certification program.

 And that enumeration or information gathering yielded approximately 60 
products.

 We also decided it would be useful not only to survey the products but 
to survey the market that product was intended to serve so we 
determined we would have three categories, small office/home office 
which is distinct from residential.  Small and medium business, and 
large enterprise/service provider.  These are fairly commonly 
recognized segments in the firewall community.  And in our survey we 
actually allowed the vendor to identify whether they were a small 
office/home office, SMB, and LE/SP.

 And we didn't try to tell them how many clients or how many servers or 
how many devices behind a firewall represented any of these particular 
markets because that is a very, very soft definition in the 
marketplace.

 Now that we had a list of firewalls, we wanted to try to come up with 
a baseline of security services that we thought would be appropriate 
for a firewall and commonly available across firewall segments.

 And again we went out and looked at the kinds of features that were 
available among all these products in the IPv4 transport 
implementations and then built a list of products we would survey for 
IPv6 capability.

 We conducted a survey by essentially contacting vendors by electronic 
mail.  We acquired the electronic mail addresses either by using the 
technical support, sales, marketing, and general inquiry e-mail 
addresses at the vendor's Web site.  Often, because of my familiarity 
with the community, I was able to contact additional technical staff 
who were colleagues or who were recommended by ICSA labs.

 I wasn't just satisfied with getting the information from the vendor 
e-mail responses, and often those responses were incomplete.  
Especially when I had to rely on a sales and marketing team as opposed 
to a technical contact.

 So when I was uncertain that I had sufficient and accurate 
information, I would contact someone who was a third party.  Firewall 
administrators who were -- who claimed to be operating those firewalls 
and had access to more information about the firewall, or were familiar 
with them.

 Also, just beginning discussions on firewall mailing lists and asking 
people.

 So these were very useful.

 In some cases, even further corroboration was required, and I 
essentially went back to the vendor Web sites or contacted technical 
support and was directed to a product specification or a product user 
manual or user or administrative guide and I used that to corroborate 
any information they had or fill in blanks.

 Ultimately out of the 60 products I identified, I ended up with 42 
viable results to use in the survey.

 So what I would like to do is just present some of the data.  I'm not 
going to belabor all the statistics.  You can read the report.  It's 
available at the SSAC Web pages on the ICANN Web site.

 But just to give you a taste of these, we looked at IPv6 transport, 
transport meaning the ability to take native IPv6 packets off an 
internal interface and route them or forward them through a firewall to 
an external interface and vice versa.

 And of the firewalls surveyed, we were able to conclude that 
approximately one in three, or just less, 31%, supported IPv6 
transport.

 The breakdowns on each of these slides simply illustrate the market 
segment results as opposed to the aggregate results.

 You will notice that the sum of the breakdowns is actually in excess 
of 42, and that is because many products were identified by the vendor 
as serving more than one market.

 So in many cases, a firewall might serve a SO/HO and SMB market, or 
more commonly, an SMB and large enterprise server market.  In some 
markets this is a soft upgrade or license upgrade but it's the exact 
same hardware and software.  You are simply increasing numbers of 
clients or increasing the capacity of the device.

 In many cases, firewalls break routing, and administrators don't want 
routing completely broken, want some sort of visibility or some sort of 
ability to route through a firewall.  And so one of the other questions 
we thought would be useful in looking at IPv6 transport was can the 
firewall participate in a peer routing protocol or in a neighbor 
discovery protocol.

 60% of the firewalls surveyed participate as peers in iPv4 routing but 
only 24% in IPv6 routing.  And while SO/HO firewalls lag in this 
particular survey result, they are not so far behind the SMB and LE/SP 
markets.

 There are basically three fundamental ways that firewalls enforce the 
security policy.  The most basic and the one that has been around the 
longest is static traffic filtering, where a firewall examines every 
packet that comes in individually and applies an allow or deny policy 
based on the rule set for processing that packet.

 In the survey, 95% of the firewalls provided static filtering when 
IPv4 was used.

 I was somewhat amazed that it wasn't 42, and I couldn't get a response 
back from the vendors because I couldn't imagine a firewall that didn't 
support static filtering.

 I then discovered that two of the firewall vendors actually do not 
allow you to do a static filter because they can only configure their 
stateful inspection engine.

 29% provide static filtering when IPv6 is used.  And the breakdown is 
a little bit low here -- or, I'm sorry, a little bit consistent across 
the markets.

 Stateful traffic inspection is a more sophisticated method of applying 
security policy enforcement.  What you are able to do with stateful 
traffic inspection is apply or attempt to enforce a policy across a 
flow of associated packets or across multiple packets that represent a 
stream.

 And 90% of the firewalls are able to do this when IPv4 is used, but 
only 24% when IPv6 is used.

 Again, we see still consistent breakdown across the product markets, 
although there's a slight bias or a slightly more popular ability among 
the large enterprise and service provider.

 The third and most sophisticated way of providing security policy 
enforcement in firewalls is application level inspection.  In this 
case, firewalls go beyond looking at simply the network layer protocol 
and are able to look into the TCP or UDP protocol, the payload or an 
application header and payload, and do fairly granular policy 
enforcement based on the kind of application that's being used.  For 
example, HTTP or instant messaging or mail SMTP pop.

 And they do so in a couple of different ways.  There are application 
level proxies, there are companies that take their stateful packet 
inspection engines and make them do what's called deep packet 
inspection or examination of application layer header and payload.

 81% of the products provide one form or another of application level 
inspection, but only 17% when IPv6 is used.

 This is a little bit biased by how few of these -- few SO/HO products 
provide some sort of application level inspection.

 One of the things that I found when I was doing this study was that we 
probably asked this question slightly wrong in that the SO/HO market 
looks at, more often than not, the client end of what application level 
inspection is.  And so the SO/HO interpretation of this question was 
can I do things like block -- black list URLs or provide some sort of 
content filtering when people to browsing.  Whereas the large 
enterprise service provider market looks more towards the server side, 
protecting Web applications and other applications from attack, such as 
input forms, modification or cross-site scripting or some other higher 
level and more server-specific kinds of attacks.

 Many firewalls have intrusion detection and prevention features.  This 
is becoming increasingly popular, even in the small office, home office 
marketplace in the form of what are called unified threat management 
devices.

 76% of the firewalls provide IDS/IPS when IPv4 is used but only 14% 
when IPv6 is used.

 This result is slightly skewed when you consider the fact that only 
one out of 19 SO/HO products actually responded positively here.

 Denial of service is an increasingly worrisome threat for almost every 
organization, and even if you are on a broadband access circuit and you 
have a relatively small office operation, you can be the target of a 
denial of service attack.

 So typically, you will find that three out of four commercial 
firewalls will be able to support some form of DDOS protection, at the 
minimum for IP and ICMP traffic when IPv4 is used.  But only 21% or 
about one in five can do so when IPv6 is used.

 As everyone has spoken today about the longevity or the legacy of IPv4 
being something that will be measured long before all our lifetimes 
have expired, and this means we are still going to need some tunneling 
capabilities.  We are going to need to put IPv4 traffic into IPv6 
tunnels to go across certain islands of support and we're going to need 
to support IPv6 in IPv4 tunnels as well.

 This was a very disappointing result, in my mind, because only 14% of 
the overall products were able to tunnel IPv4 and IPv6 transport.  And 
29% of products were able to encapsulate IPv6 traffic in IPv4 tunnels.

 If you are familiar with the firewall market, you probably recognize 
that or understand that a very small number of firewall vendors 
actually hold a very, very large part of the marketplace.  In fact, we 
estimate that the top six or seven firewall vendors hold approximately 
95% of the commercial market.

 That being said, I went back and took a look at the products that the 
top six or seven firewall vendors offered, and surveyed or limited the 
survey to just that set.  So the market leaders slides and the market 
leader sections in the report talk specifically to the top holders in 
the market share.

 Even when you go and you take out everyone but the market share 
leaders, you still only improve the support of IPv6 transport and 
sophisticated traffic inspection marginally.

 In addition to support being relatively in the one-in-three range 
among products, I received a lot of anecdotal information by continuing 
exchanges when I managed to speak with, you know, technical contacts in 
the companies.  And one of the things I discovered was that the IPv6 
support is not always as uniformly robust as IPv4 support.  For 
example, in IPv6, the IPSec support may not necessarily support as many 
types of Internet key exchange or it may only support manual keying.  
The user interfaces may not be as robust.

 In many cases, vendors said, "We can support IPv6 but only through our 
command-line interface and not through our GUI," or graphical user 
interface.

 If you're getting an IPv6 firewall that supports IDS or DDOS, in many 
cases, the signature set that's available when you're running IPv6 is 
not as large as the signature set for IPv4.  Almost uniformly, when I 
ask why you didn't have support, the answer was, "No one is asking for 
it."

 So what are my conclusions from this and what were SSAC's conclusions?  
It is true that there is support for IPv6 transport and security 
services.  It is available for, you know, all market segments.  
Firewalls that support IPv6 transport generally provide some form of 
traffic inspection, one of the three that we mentioned earlier, event 
logging, and I.P. security or IPSec V6.  Those were the positives.

 The negatives that the I.P. version 6 transport is not broadly 
supported among commercial firewalls.  One in three is not a very 
promising number.  Across all market segments, one in three products or 
fewer are able to support IPv6 transport and a significant number of 
security features.  If you only look at the market leaders, you do get 
a slightly different better figure than that's one in three.  You get 
approximately 45 to 50%.  What is disconcerting to me is that even when 
you have the market share leaders, the availability of advanced 
security features that many organizations desperately rely on to 
protect their networks is not available, and it's weakest in Soho and 
small to medium business segments, but strongest in the large 
enterprise and service provider segments.

 And that is it.  If you have some questions, I'd be happy to answer 
them.

 As I said, the report's available online.  It's -- it covers a lot 
more space.  There are some more -- more statistics that we've 
gathered.

 >>JOEL JAEGGLI:   Yeah, Joel Jaeggli.  Just another check point 
reseller, ultimately.

 But I saw this presentation at ARIN, and I think it's really good.  
And it should be a wake-up call for people who actually need this 
functionality.

 One of the things I would love to see in either your report or in the 
presentation would be actually a grid of the features that you perceive 
are and aren't supported on given platforms.  And, I mean, maybe naming 
and shaming isn't so nice, but I'd certainly like to know, not 
necessarily what my competitors do, but what I don't.  And I think 
that's -- in our case, I think we substantially anticipated the market, 
like IPv6 support started to go into the firewall in 2002, which means 
there's so much it out there that we've actually forgotten about it and 
it's rather dated now.  And, I mean, I think that's a serious issue, 
is, is it ready for the modern world.

 >>DAVE PISCITELLO:   A couple of points.

 After I presented to ARIN, I went to present to the ICSA labs firewall 
certification consortium.  And there were approximately 20 vendors 
there.  And one very comforting result was that at least two of the 
vendors came up to me during a break and indicated that the numbers 
that they saw in my presentation were consistent with what their 
internal marketing had come up with in terms of availability of 
support.

 However, both of them said they conducted their surveys about a year 
ago.  So nothing has changed very much in about a year.  And I think 
part of that is because very few people are offering vendors a reason 
to invest more research and development, more product development time 
in IPv6 and are urging them to do things like Voice over IP security.  
So I think that part of this is trying to decide whether you're going 
to push or pull the cart.  If you want Nokia and Checkpoint to offer 
more on IPv6, I think you've got to create the perception that there is 
a meaningful market for them to actually put some time and effort into 
improving products.

 The name-and-shame thing.  Many of the firewall vendors -- and you can 
imagine, you know, this is just an intensely competitive market -- were 
very reluctant to give me any information whatsoever unless I agreed, 
gentleman's agreement, that I wouldn't disclose the individual vendors.

 That's a matter of trust.  I'm a security, you know, practitioner.  I 
won't violate that trust.  I can go back to them and say, "A lot of 
people would like to know what's available.  If you are interested in 
having us host a site that shows who does support things, I'll put that 
up."

 But until I get, you know, some sort of indication that I'm not 
breaching a confidence, I'd rather not do that.

 So, yeah.  I hope you understand that.

 >>JOEL JAEGGLI:   Yeah.  I think that would be an excellent idea.  And 
I would be willing to advocate for it, with some firewall vendors who 
are not present in this room.

 >>DAVE PISCITELLO:   And I think ICSA Labs and SSAC are going to do 
more work together, because one of the things that we're hoping to be 
able to do is get the assistance of the labs in establishing, you know, 
good baseline criteria for V6 firewalls very quickly so that vendors 
can start to use that as a reason to do additional implementation.

 >> AXEL MAJIA:  Good afternoon.  Have you thought if you are going to 
apply new rules or new standards to -- for firewalls, if you're going 
to apply new rules?

 >>DAVE PISCITELLO:   Okay.  I think that we need a fair bit more 
experimentation with and practical experience with firewalls in the 
IPv6 world to know exactly how we're going to deal with a world that 
has plentiful addresses.

 As an example, you know, I.P. masquerading, the ability to essentially 
hide entire networks behind an entire V6 address or V4 address at the 
external interface of a firewall, isn't going to go away, but there may 
be very, very different reasons to want to make many, many more 
addresses available and routable through a firewall when you have them 
than you have today, especially in the VOIP world.  I think that the 
gentleman from Nokia had mentioned this.

 And that's going to change the way that I believe firewall vendors are 
going to have to developer their graphical user interfaces and their 
ability to create very fine or granular policy rules, because you're 
going to have larger policy sets that are going to be many times more 
individual addresses than subnets or than entire domains.  So that's 
one change.

 I think another change is that we have an opportunity with IPv6 to 
possibly ask vendors to do more.  I'd love to see vendors -- and I 
mentioned at ICSA Labs -- build in more antispoofing measures in the 
firewalls so that firewalls, by default, do not allow anything that is 
not configured as an address or a subnet to be passed through the 
firewall from the private network into the public -- you know, public 
realm.

 So I think that there's a lot of space here where we can learn and 
explore.

 The one thing that I still worry about is that we really have very 
little experience in working the code.  We've got 20 years of beating 
the hell out of IPv4 kernels in all the variants of Linux and BSD and 
Microsoft.  We have ten years of implementation experience and maybe, 
legitimately, three to five years of implementation experience with 
IPv6.  That doesn't give me a lot of comfort that we're not going to be 
seeing exploit lists that are, you know, considerably longer than what 
we already see.  And if anyone monitors exploit lists or bug track 
lists today, you know that they appear by the dozens per hour.

 So I think that we have a long way to go here, and I really wish we 
had more implementation, because I'm afraid that by the time we have 
this big upswing of adoption, that we won't really know how solid the 
code is.

 >> AXEL MAJIA:  Thank you.

 >> WILFRIED WOEBER:  Wilfried Woeber again.  I'm wondering about where 
you put up these slides, like so much support for a particular subset 
of facilities, even if you reduced that to this -- sort of through the 
market leaders, you still got the impression that there is a lot to be 
desired still.

 My question would be not in order to entice you to give away any 
vendor-specific information, because I respect sort of this 
confidentiality thing, but do you see some sort of clustering, like 
there is a smaller set of products which actually supports more of 
those essential functionalities in the same box?  Or is it sort of 
evenly distributed that all of those products do sort of have the same 
or approximately the same level of support for various things and then 
you have to do some mixing and matching, like what's more important for 
you?

 I don't know whether I was able to actually put my question into a 
proper way for you.

 >>DAVE PISCITELLO:   I think I understand what you're asking.

 If a product was in that one in three, it was a reasonably robust 
product.  So if your firewall -- if your firewall supported IPv6 
transport, it generally supported IPSec, it generally supported 
stateful packet inspection or application-layer proxies, it generally 
had good event logging.

 So I think that if you can find a firewall that supports IPv6 -- well, 
you can, obviously -- when you find a firewall that supports IPv6, it 
will do the 80% case, let's say.

 The problem is that that 80% is not satisfying to a large enterprise 
administrator.  And I think we are in a situation where we were with 
wireless LANs before WEP, where there's an enormous tendency for 
administrators to say, "I can't cure it, so I'm not going to deploy 
it."  So in addition to having to try to justify the expense in going 
out and acquiring the new technology, there's going to be the push-back 
that says, "Sure, we need to go to IPv6.  Do you want me to open our 
network up to -- you know, to all sorts of hideous attacks, because 
that's what's going to happen?"

 And this is just the regular push-back and reticence on the part of 
large administrators to keep all the new features and requirements at 
bay while they try to keep up with daily ops.  And, you know, I think 
that that's a danger, so....

 >> WILFRIED WOEBER:  Thank you.

 >>LEO VEGODA:   So, Dave, if I can ask you a question, which was 
actually phrased -- sorry -- quite nicely by Ron Broersma of DREN, he 
did a presentation on some work on the Abilene project, Internet2, and 
he was talking about no major incentives to do IPv6.  And there's push-
back, and there's people talking to vendors and saying, "I'd like IPv6, 
and I need SIP," or whatever.  So if no one is deploying it, there's 
nothing you're missing by not having it.  There's a lack of incentives 
that result in a lack of customer demand.  Loop back to the top of the 
page.

 So we've got all these firewall vendors, and they say, "Well, no one's 
deploying it and there's no customer demand," so are we actually going 
to see the 30% jump up to 60% or 80%?  Or are they all going to be 
working on something else?

 >>DAVE PISCITELLO:   I think everyone in the room could picture 
themselves as being the director of product development at a firewall 
company that is publicly held and has a shareholder meeting, and -- six 
months from now.  Now, picture two different scenarios:  One firewall 
vendor goes and implements a very application-aware firewall that 
provides better than state of the art Voice over IP security.  Another 
firewall vendor implements IPv6 and has the best IPv6 implementation.

 Who's going to have the -- have made the most significant impression 
on their shareholders after that six-month development cycle?

 This is the real problem that IPv6 has had for ten years.  There is no 
commercial incentive other than large addresses, because we fixed IPv4 
or we complemented or shimmed IPv4 to do everything that IPv6 was 
intended to do by 1999.  So for eight years, there really hasn't been 
an incentive to do IPv6 other than big addresses.  And I think this is 
a reason why many people say we should just leapfrog IPv6, because 
there's no point in only doing something with no innovation that simply 
yields us big addresses.  And I have some sympathies with that except 
for the fact that we're lemmings, we're right on the brink of the cliff 
and it's very hard to turn lemmings around.  There's no more addresses, 
there's no more space beyond the cliff.  And my suspicion is that we 
will implement IPv6 and there will be a lot of pain and suffering and 
gnashing of teeth.  But ten years from now, we may be revisiting IPv6 
and saying, damn, we don't have enough innovation to have actually 
merited th!

is effort and we're going to have to do it again.  And I think that's a 
very scary scenario.  But ten years from now, I should be retired and 
doing something else.

 >>JOEL JAEGGLI:   Joel Jaeggli again.  I would just comment on that 
question really quickly and say, I mean, I think our existing large 
customers have rather robust interests in IPv6 firewalls at this point, 
because it's a requirement for them to even think about rolling it out 
in their network.  And so they ask us a lot of questions, they're not 
buying anything at the moment.  But there is actually a real demand for 
this product.  Thank you.

 >>DAVE PISCITELLO:   And I agree, Joel.  And I think that the 
companies that are prepared are actually going to win again and that 
the companies that use this as an excuse to just try to keep up or, you 
know, get to EBITA positive faster than their customers are going to 
fall off the map.  I guess as a closing remark, one of the things that 
you ought to consider is that firewalls are arguably the most mature 
security service that we have in the Internet.  And if the firewall 
support of IPv6 is in the one in three range, what is the support for 
authentication systems, for intrusion detection systems, for log 
analysis, for other sophisticated anomaly detection systems?  We really 
have a lot of work to do.  It's not just addressing, it's not just 
routing.  We have a huge amount of work to do to put ourselves in the 
position to really argue that you can do IPv6 today and you can do it 
without loss of functionality or security.

 >>LEO VEGODA:   Maybe I can ask one more question before we start to 
bring things to a close, then.

 And I'll start by telling a small little anecdote.  A couple of weeks 
ago, I was at the AfriNIC meeting in Durbin.  And that morning, going 
through the abuse complaints that come to IANA each day, we get a lot 
of abuse complaints about people who received spam that appears to have 
come from private address space.  And I was looking at updating these 
messages that we sent out to explain about private address space.  And 
when I went and looked at the messages and I was about to update them, 
I realized we had no text about IPv6 at all.  And so I thought, well, 
maybe I should go and put in text about IPv6.  And went and did a 
search and found that we'd never actually had any complaints about 
IPv6.  No one has ever written to us about an IPv6 address that has 
attacked their system, which I was a little surprised about.  Either 
IPv6 users are very smart and understand that when they see odd traffic 
from IPv6 addresses, it's local to their network or it's some special 
address with!

 IPv6 and they shouldn't worry about it, or maybe there isn't as wide 
deployment as we thought with all the Apple hardware and Vista and 
everything else out there.

 So I'm wondering, we've got an IPv6 consumer service provided by NTT, 
and there is, I believe, in your presentation, Takashi, there was 
security software provided with that.

 Is the security for consumers already in place and it's smarter 
security than they have for their IPv4 software?

 >>TAKASHI UEMATSU:   Right now, it's the same with IPv4 basis.  So we 
asked certain vendors to create the IPv6 versions of the software.  So 
they made it.  So we take it.

 So our customers right now have the same ability to block out and 
filter out any packet from IPv4 Internet and also closed IPv6 network.

 So software -- PC software and the -- running SPI firewall with SPI 
running on CPE devices, also runs IPv4 and IPv6 also.  So we have the 
two implementation points to do the security issues.

 >>DAVE PISCITELLO:   Go ahead, Joel.

 >>JOEL JAEGGLI:   Joel Jaeggli.  I have several mail servers with quad 
A records and they receive spam.

 >>LEO VEGODA:   Well, you just don't complain to us, then.  And that's 
great.  Thank you.

 >>DAVE PISCITELLO:   I was curious, you do have some content servers 
that you manage.  What do you put in front of them?  Do you have 
application-layer firewalls?  Do you have, you know, packet filtering?  
Or what kind of firewall protection do you have for your own data 
centers?

 >>TAKASHI UEMATSU:   Data centers?

 >>DAVE PISCITELLO:   Data centers and your content centers.

 >>TAKASHI UEMATSU:   Actually, it was the 2003 and '04 when we go into 
the -- to testing networks.  So it was back in three to four years ago.  
So at that time, we see only two vendors had IPv6 firewall devices.  So 
we just picked one out of two and put one firewall product on our data 
centers because we had the security update servers for the PC software 
also, which had the IPv6 firewall equipped, and also the CP 
configuration server, which also equipped with firewalls.  So so far, 
it's okay to running, maybe -- or cross-network, there's less spam or 
DOS attacks inside.  And it's very clean, rather than the Internet.  So 
it's -- we are safe to do our business right now.

 >>LEO VEGODA:   Okay.  I think that's brought us to a natural close to 
this session.

 I'd like to thank all three of the presenters on this panel and the 
three presenters on the previous panel before the coffee break.  I'd 
also like to take the opportunity to thank our translators and our 
stenographers.  It's been a very interesting session, I think.  We've 
had some good discussion about policy environment and technical 
operations for IPv6.

 I thought it was quite enjoyable.  I hope you did, too.

 There's more interesting stuff going on throughout the rest of the 
week.  So enjoy yourselves at ICANN 30 in Los Angeles, and good 
afternoon.

 [ Applause ]