______________________________________________________________________

                          DRAFT TRANSCRIPT

                         IPv6 technical SIG
               
                    Wednesday 1 September 2004 
                              11.00am
______________________________________________________________________


KAZU YAMAMOTO:

We have been waiting for 15 minutes and I think it's time. So let's
get started. This is IPv6 technical SIG. I thank our spokespersons.
Today's meeting is sponsored by Softbank BB and Internet NZ. We have
today several information presentations from six people. The first one
is from APNIC.


GEORGE KUO:

Good morning, everyone. My name is George Kuo from APNIC. This morning
I am presenting the IPv6 status allocation report. Just briefly an
overview on my presentation. It will cover IPv6 statistics, allocation
and assignment made by APNIC and finally the IPv6 routing table and
Whois database registration. First of all you can see APNIC
received/23 allocation for IANA. You can see when it was made. The
last one that was made in June hasn't been used yet. The last one,
/32, is used for making IX assignments. In comparison with the other
IRs you can see the numbers of /23 allocations existing for IRs. APNIC 
has only made 164 allocations. By the way, if you have any questions,
just stop me any time. This one shows the total address
space that's been allocated by each of the IRs in a unit of /32. This
is the breakdown of allocation made by APNIC according to the year and
you can see the number and the different size of prefix that has been
allocated so far. 2004, you can see we made a /28 allocation and last
year in 2003 we made a /30 allocation. This one shows the allocation
made by economy. Japan has the highest number of IPv6 allocation,
which is 69, followed by KR and TW. 	 

Due to the policy change of the initial allocation size from /35 to
/32, APNIC secretariat has made a total of 60 allocations under the
/35 policy. Five have still not been upgraded but have not come back
with requests to be upgraded. This shows the Internet exchange 
assignment and critical infrastructure assignment. We haven't made 
any experimental allocation so far.

Further breakdown by economy the IXP assignment - two to Japan, Korea,
New Zealand - the rest of the economy one. This is the breakdown of
critical infrastructure assignment - Japan three, the rest of the
economy one. This shows the number of allocations made and whether
they are routing prefix. Ninety-two /32 have been announced. A lot of
upgrades have been made from /35 to /32. 57 have been not announced.

This shows the global IPv6 routing table - the ones in blue are
the prefix from 6bone and the rest from four existing RIRs.

Last slide, you can see the comparison of the APNIC database
registrations from February this year up to mid August, last month -
you can see a great increase in registration of /48s - that is a
different size of prefix in database back in February. These are some
useful URLs for reference and that is the end of my presentation. Any
questions? Thank you.


KAZU YAMAMOTO:

The next presentation is by Toshiyuki Hosaka.


TOSHIYUKI HOSAKA:

My name is Toshiyuki Hosaka from JPNIC. Today I will present you with
the number of /48s registered per country. The measurement method is
like this. The number is based on the APNIC Whois database and
assignments per country in terms of / 48s. this is the result of the
measurement. The red bar shows the number of /48s registered in APNIC
Whois database. The blue one is the number of /32 registered in the
Whois database. Japan has a large number, Korea not so many. What does
it mean? It could mean that only 7,000 or 8,000 assignments in the
APNIC region - so I can say this is a very small number, because one
single LIR needs at least 7,000 /48 assignments according to the APNIC
investigative policy document. 	Or it could mean that LIRs are not
registering /48 to APNIC Whois database for some reason. If this is
the case, may I suggest that you register your assignment record into
APNIC Whois database, because this is APNIC's policy and you need to
register your assignments to get your allocations. Thank you very
much. Any comments or questions? Thank you.


KAZU YAMAMOTO:

Thank you for your presentation. Our next presentation is provided by
Jordi Palet. He has two presentations. This is the first.


JORDI PALET:

This is a short presentation just that we have prepared in Europe
looking at the different documents for the label for the assignment of
IPv6 to the customers. So it is guidelines for ISPs on IPv6
assignments to customers.

So the first question is looking at what is an IPv6 address - it has
64 bits for the host and 64 bits for the network number. If we provide
/48 to every subscriber, in principle it seems that this doesn't
represent a waste of address space. If we look at the total number of
/48 prefixes we have in the global unicast prefix it's 2 to the power
of 45, so quite a big number. In principle, there is no shortage on
the number of /48 prefixes and enterprise and individual subscribers
expect to be able to connect to the network multiple always-on
devices, both fixed and mobile. So if we look at the need for
subnetting, this is a must. We should also separate different
networks, because, for example, in the same access network we can have
different departments or we can have, for example, a SOHO where you
have a person working from his home and it may have a network where
the children connect and he is also working. You want to make sure you
can separate both networks. So a /64 in that case obviously will not
work. 	That means that the subscriber requires a site prefix and
also an option could be renumbering, thinking, for example, you have
/64 but you want to do some netting and you need to renumber, but this
is probably something we are not interested in doing.

So the guidelines basically say considering that the full allocation
policy that this is suited to and also that bigger allocations, of
course, are possible, ISPs should keep the following allocation
practices. A /47 for very large subscribers, a /48 is the general case
except for very large subscribers, obviously. So this includes home
network subscribers, SOHO, smaller and large enterprises. A /64 when
it is known that one and only one subnet is needed and not regarding
the future. One example could be a cell phone, for example on network.
And a /128 when it is known that one and only one device is
connecting. This has been defined because we want to make a balance
between IPv6 address space conservation practices, network
administration, deployment/growth expectations, avoidance of
renumbering and scaling inefficiencies. So, of course, the /32 is the
allocation, but it's also possible to allocate bigger prefixes. The
point is why do we need to allocate bigger prefixes? We don't want to
increase the routing tables. Some people are asking for bigger
prefixes and I will show that in my next presentation. My last slide
is just a list of references to the different documents for making the
guidelines. Of course, I would like to get input from the community,
because the guidelines actually just take the existing documents. I am
not really taking my personal stance on that - just looking at what is
available there and it could be interesting also to see the opinion of
different people to see if we agree with these guidelines and
consequently we agree with today's policy on this.


KAZU YAMAMOTO:

I have one question. I think this is a very important thing. But IPv6
technical series, you know, you can present only informational. So are
you planning to bring this to policy?


JORDI PALET:

The document was purely informational.


KAZU YAMAMOTO:

If you want to change it to policy?


JORDI PALET:

It is not trying to change the policy - my document is a document
where the people deploying IPv6 can take a look and see quickly what
should I do with my customers, according to the different documents.
Most of the people who know will not read the complex policy document
- they should, but they are not doing so. I am just trying to make it
very, very short to show people what it is expected they do according
to the actual policy.


SPEAKER:

According to that overhead it indicates it should be policy.


MIWA:

My name is Miwa from APNIC. I have a question about BGP
recommendations for IPv6. In that recommendation they said /48 for
mobile terminals is recommended. I feel it's quite a large size for
the mobile terminal. Is there any discussion in IETF talking about
something between /48 and /64 assignment?


JORDI PALET:

Not that I am aware of. I am not sure of the recommendation from BGP
/48. That's quite confusing. I actually have read that in another
request, I think. Maybe I am confused. 3177 is clear that mobile notes
- it's expected to receive a /64. The point is that if the mobile note
will really need to have a network behind, because my understanding
also, I am not a BGP expert, but my understanding is in every BGP
context more or less is like a connection, almost, you have a single
one for every single device. Maybe Tony can provide more information
on that.


TONY:

You don't know that that device is not a router. Particularly if it's
a vehicle. It looks like a device to the BGL network but it's a
router. It needs to have the ability to have space behind it. The IETF
is not going to specify the policy. That becomes business practice as
to the distinction between a /48, /56, whatever. But from the IETF
perspective there needs to be subnets behind that device. There might
be a router behind the vehicle. It's using that particular radio
network. You have to get past business policy. That's a single device
versus it's a router.


JORDI PALET:

The point is does the mobile know it's just a node or is if acting as
a router.


TONY:

It could be an ISP.


KAZU YAMAMOTO:

Thank you. The next speaker is Bill Manning.


BILL MANNING:

I'm going to start out with a couple of slides that talk a bit about
the confection in which you put IPv6 enabled DNS servers. The idea
here is that there's going to be lots of different nodes. The DNS will
have to respond to a mixed environment. There will be a lot of IPv4,
some IPv6. Some systems will not migrate in our lifetime. They will
continue to talk IPv4. So the DNS has to talk to IPv4 systems as well
as IPv6. As far as the end systems are concerned we don't want to push
IPv6 into them. The transition to a IPv6 enabled environment needs to
be effectively transparent to users. There are a lot of different
types of transition mechanisms in place. One size does not necessarily
fit all. There are a lot of different ones. They fit different
applications, different service profiles.

There are tunnels and there are translation mechanisms. Some of them
are more efficient than others, but they will all exist. From a DNS
perspective, there are almost too many. If you're trying to
troubleshoot a DNS problem you need to know what types of mechanisms
are in place. If they're not exposed to network troubleshooting it
becomes problematic. If I was able to say the DNS is the preeminent
application and all applications need to be subordinate to that, I
would pick one transition mechanism. From a network operations
standpoint, having a single set of mechanisms in place makes your
operational job a lot easier. From the end user perspective, what this
really means is that they will impact the perception of end user on
how well the DNS works and by that how well IPv6 works. 	So if you
have a large mix of transition mechanisms in place, the performance
will suffer. The end users will blame that either on the DNS or upon
IPv6 and they will want to stay with what works best for them. So in
that context, we look at IPv6 data. IPv6 data is distinct from v6
transport. For many years some of us have known this. We can't publish
IPv6 data now in all of our v4 enabled servers. It's useful if you run
dual stacks to the end systems. It becomes a problem - I have a
resolver, something in the end system, that only understands IPv4. If
I add IPv6 resource records I make a query for that and the answer I
get back is a AAAA record. We have to help the end system no matter
what's going on. So in a mixed environment without coordination it is
possible that resolvers stop getting DNS answers. We have split the
DNS hierarchy. Just turning on IPv6 is not something you want to do
lightly. Part of this is fixed by augmentation by the BIND
implementation of DNS. They've done a couple of interesting things
which say if you ask a question on IPv6, we will attempt to answer on
IPv6. Then they say if you ask a question on IPv6 and we look at the
contents of the answer, if there's v6 AAAA information we'll give you
that information first then the v4 information. If you ask for v4, it
will give you the v4 information then v6. That means you have to be
running relatively current software. 	There was a testbed doing
native IPv6 stuff and some other things. Then there was work on the
resolver side done through the WIDE project then at ISI and finished
up at ISC. A number of people in this room were early adopters. Akira
Kato wrote this following draft - it would be worth you going to look
at that. It points out two key items. IPv6 does not fix the limit on
the message size. EDNS0 allows negotiation for larger capability but
there are not a lot of end systems with the capable resolver code. It
cannot be expected to meet every Internet resolver in the short or
medium term - two to five years. So for the next five years at least,
the 512 byte limit is going to be something we have to live with.
JPNIC, KRNIC, CNNIC, the Dutch NIC, DE, SE, the US military and INT
all played a role in this testbed. Some of them followed up with
official requests to ICANN - JP, FR and KR. Those are running
production servers. So if you want to skip to the end of the
presentation, it is now possible to get native IPv6 glue for your TLD.
We'll come back and look at some of these issues. There are protocol
specifications. Things from the DNS we've touched upon. It's a 512
byte limit. IPv6 - you can use fewer addresses. You also need to be
concerned or be aware of what the end systems and the intermediate
systems are doing with their operating systems. We're going to look at
a brief example of what ARIN, the original registry in North America
did, in trying to bring up IPv6. We'll look at some of the middle
boxes that impact what people perceive and then the end systems
themselves. It's a 512 byte limit. If it goes above 512 bytes UDP will
fragment and you'll get fragmented notices. This would be OK if we
lived in Jordi's ideal environment where there were no NATs, but we
don't live in that environment. Many NAT boxes or ALG boxes will throw
away fragmented UDP fragments. A query may be sent and the answer will
be coming back and be thrown away because it's too large or is
fragmented. This is not IPv6 friendly at all. So the question you have
to ask yourself is how many servers can I define in my authoritative
list before fragmentation occurs. This is really delegation dependent.
So we're going to look at this particular - we've got a delegation for
a thing called 'Lump'. It's served by six nameservers. Those six
nameservers have somewhere in the neighbourhood of 18 IPv4 addresses.
Will all of that fit into a 512 byte packet? No. Some of those IPv4
addresses will be truncated. Then the interesting thing comes up -
let's say it's going to add two AAAAs. Not only will we get truncation
but a lot of stuff truncated and probably the IPv6 stuff. So there
needs to be a calculator, some mechanism for people to run through the
processes as "Will I exceed 512 bytes? I want to add v4 and v6
support, but I have to truncate, I have to cut down the list, so that
I have a reasonable size that most people can use." That must exist or
that tool set exists in the graph that Koko San wrote. That was taken
through to RSSAC and it said to ICANN, "Based on empirical testing,
please proceed with TLD delegations" - if TLDs have IPv6 requests in
we don't see a problem with that as long as you follow the IETF
advice:

Mind the fragments. Things will fragment. 	So there was a
calculator. At the end of your draft you can put your information in
and it will tell you whether you'll exceed the limit. So the text of
the RSSAC recommendation went out in 2003, in December, and it took
approximately six months for the ICANN board to approve that. Within
24 hours after the ICANN board approved that, we started seeing the
first entries in the root zone. So the guidance here is not just v6 -
it's also if you're going to have excessive numbers of v4. So it's
exposing a moderate or high number of authoritative servers or glue
and looking at the response size limit. So if you look at this and
say, "Well, we would like to deploy IPv6 and we want to put it on our
nameserver and make it available", the question becomes - how do we do
this? The answer is it depends on what your current environment looks
like. Do the services and the transport match cleanly? Does your IPv4
bandwidth and IPv6 bandwidth and reachability for both overlap nicely,
or is there some sort of disconnect, do you have better v4
connectivity or better v6 connectivity. Is there a desire to minimise
the impact on your production services. Some have service agreements
that say they want them to be available 24/7 by 365. Turning on new
stuff, while relatively easy technologically, there are unanticipated
side effects. In ARIN's case, the IPv6 service did not match the IPv4
service. They had better IPv4 service. They outsourced some stuff. -
high connectivity. IPv6 didn't match that. This is perhaps an anomaly
in the US. They also looked at this and said the dual stack
recommendations coming out of the IETF aren't really practical because
we have these 365 7/24 production requirements. 	Our customers
cannot tolerate and do not expect us to have the level of downtime in
case there's a problem. So they put in the IPv6 capability as part of
the normal life cycle, retiring old equipment and bringing new
equipment on board. The technique here was that the IPv4 Colo -
collocation space out there offsite - but it only has IPv4
reachability. So they have a machine that has an A record -
69.25.34.195 and over the Internet they have another machine that has
v 4 and v 6 - this is in their offices with much lower bandwidth. They
have the same name but they put a AAAA up there. So the AAAA machine
slaves the data from the A machine - it's transparent then. The
customers then refer to the service by name, not by an address. The
name means the same so the customer can move between transport.
Running non-dual stack servers from the zone can be done in two ways.
Here they used one server name on two distinct machines. This has
interesting side effects. This has to do with application development.
If you remember what Jordi presented earlier today, some of the things
here is that the application developers do not treat v6 the same. BIND
seeks for A and AAAA for all NS names. They couldn't split it into two
different names because you wanted to look for one. The IPv6 user
should be presented with the same environment. We do not want to treat
IPv6 users as second-class citizens. Because we cannot predict what
the community wants - we've got some guy, Joe Abley, what he's going
to use from one minute to the next. He may use IPv4 10 minutes ago,
IPv6 now and IPv4 later. The consistency on the service delivery has
to be available. He needs to be able to continue to use the same
names. The other service is SSL. You type in #SSH tinnie.arin.net.
AAAA is preferred over A. If you wanted to reach tinnie A this would
fail. Ed Lewis once did a tail -f log. You have to be careful
operationally. It's acceptable, but suboptimal. The other thing here,
if you generalise this, if the A server is running any other services,
ftp, http,that may or may not be able to be brought up on IPv6 you
have to separate them on separate machines physically or separate the
services via domain names. They brought new hardware on line to do the
IPv6 stuff. As that's troubleshot they can bring those services
across. In summary, here, as Jordi pointed out, modern equipment is
generally IPv6 capable. When you buy new stuff, v6 generally works.

In ARIN's case, in the North American case, v6 transport from
commercial vendors is sporadic. Some people have reasonable IPv6 most
of the time. Some don't have it. Some have it but it's in engineering
or evaluation phase. They don't have the same level of support for v6
and commercial vendors. It's also true that IPv6 can be deployed
without impacting production services. This is particularly true when
you split them on to two different machines. In ARIN's case, the IPv6
users did not want to be perceived as marginalised. We didn't want to
put up services and say you v6 users don't get the same level of
service as the rest of the ARIN membership. Get the latest acceptable
versions of software, put it on, make it work, use the same physical
media - in this case Ethernet.

The recommendation is to get in relatively early. The actual query
rates for IPv6 are relatively low. The bandwidth requirements are
relatively low. If you start now you can track better the use of IPv6
and match the bandwidth and the hardware requirement to the IPv6
capability as opposed to trying to put in equipment that will meet
your IPv4 demand for IPv6. There's another implementation choice other
than one machine two names and this is dual stack. It makes a certain
set of presumptions. It presumes that all systems and services on that
particular machine have working v4 and v6 stacks and these are
consistent and that you have consistent homogeneous transport on all
the end systems for v4 ns v6, which is not necessarily true. More
difficult and problematic is the untested application interaction -
given the bug. SSH preferred one transport over the other and BIND
preferred the other. BIND preferred v4, SSH preferred v6. So you may
have problems with applications that use the wrong type of service.
There is an unwanted pressure on production systems. If I have service
level agreements that I cannot have systems or services down, that are
running on IPv4, turning on IPv6 and dual stack may trigger other
effects on those systems which may bring them down. You want to
separate the IPv4 and the IPv6 until you get really robust v6
capability in place. 	Stepping away from the ARIN example, we're
going to look at other things particularly with the roots and TLDs.
The US department of PAMA still has a role. There is an application
being made for the .EDU domain, to get them on IPv6. The department
sent this note back. They are interested in smooth operation and
stability. The real consideration is stability. They want to see
full-blown technical proposals that look at the steps to be taken to
maintain the smooth operation. 	Based on this, ICANN had the burden
of documenting the procedures about how v6 stuff would be added,
troubleshot, documented, and how they would deal with v6 requests.
They went ahead and did this. This was the recommendation in December.
ICANN started working on this in first quarter. There are the
procedures there - they went through the open comment process, which
is why it probably took six months and they were approved on 13 July
and are being implemented. Doug, are there any outstanding IPv6
requests for TLVs or have they all been processed. Doug we're busy
processing them at a pretty rapid pace. We're very excited about the
number of TLDs who have taken it up. I would like to point out we are
the first GTLD to have v6 glue. So that is correct?


DOUG BARTON:

Absolutely correct. Where everything is ready to go, we get them done
in three or four days. The ones that take longer are generally where
we have to contact other TLD managers or where there have been
problems with the nameservers as the requests are submitted.


BILL MANNING:

As Doug points out there is a backlog, there is a request coming in.
Most of the hurdles have been covered. Now that we have IPv6 glue for
TLDs, when are the nameservers going to get IPv6 support? It's a
slightly different problem and it has to do as touched on in the
beginning and I'll touch on in a few minutes - what happens in the end
systems? They are important, because they have to be able to
understand v6. To understand the scope of that problem, the advisory
committee is evaluating the threat matrix. That may take six to nine
months of work before a recommendation can happen. We believe in the
next six to nine months RSSAC will make recommendation. There is a
list of technical documents. If you look at servers in the overall
context of the DNS, this presumes a common name space across all the
useable transports. The DNS design presumes a single transport - IPv4.
They did not comprehend multiple transport. The service is a
cooperative engagement between servers and end systems. So services
cannot unilaterally make changes without worrying about the impact on
the end systems. We don't control the end systems. There's stuff in
the infrastructure that may impact on what happens which is a real
problem as well. The servers and end systems ability to comprehend and
adjust to a common name space in two distinct transport domains is in
jeopardy if we don't plan. There is also infrastructure stuff - middle
boxes, proxies and NATs. These are things, if you've been to a number
of hotels, and you plug into the hotel network, they will hijack your
DNS request and run it through the hotel proxy. They're trying to be
helpful, trying to give you a good service. If I've got IPv6 they're
maybe going to map it to IPv4 or give me IPv4 data back that I don't
want. I don't want them to be helpful. There's not a lot I can do
about it. The other thing looking at the end system is there's not
just one resolver. Applications come with their own DNS resolver,
particularly web browsers. Then there's OS capabilities. When you look
at your applications it's not enough necessarily to replace your
machine or upgrade your operating system, you may also have to upgrade
each of your applications to IPv6 or whatever. You look at the life
cycle - what is the replacement cycle in your environment for for your
customers - how often do they replace stuff. For the root servers,
this is mainly about name space fragmentation. How do we present a
consistent name space over multiple transport. So the domains are name
spaces. Everything below .com is in the com domain. Each of those
domains is an autonomous decision. Once you make that cut, the person
who has that makes a determination about what servers they want. A
couple of years ago Paul Vixie made this quote:

DNS is a distributed, autonomous, coherent, reliable database. He
forgot a couple of other things, like hostile. It defines the DNS name
space. When I make a delegation - if I make a delegation from int or
from ARPA to IPv6 ARPA and I hand that to Axel he has the decision to
make about what transports to make it available on. If he makes it
only on IPv4, the IPv6 community has a problem. So each of those
attributes is available at each delegation point. So you have to be
aware of what happens from everything downstream. You have to pick the
servers and they need to be visible to the Internet. You want the
answers to be the same. You don't want a IPv6 question to be answered
differently from a IPv4 question. The Internet can deal with a lot of
stuff. It can't deal with lying very well. You can solve the problems
with a single name space in a couple of different places. You can put
it close to the resolver, i.e. client.

You can put it close to the server. There are tens of thousands of
those. 	That's easy compared with the end system. We never want to
go through something called a bridging device, because bridging will
leave legacy stuff there forever. So the generic recommendation,
particularly for TLDs and below TLDs, is to have an authoritative
nameserver for every zone on every transport. This is to maintain a
single name space. We want coherency for the end user. Make the
intermediate resolvers virtually dual stack. Run current software on
servers. Accelerate the life cycle process to bring onboard new gear
that is IPv6 capable as quickly as possible. This eliminates
dependency on bridging and other things where you don't have control.
That's it. The roots looks to be eminent - now it's a question of
pushing it down. Thank you.


BILLY MH CHEON:

(Pause) (Setting up presentation)

Nice to meet you. My name is Billy with a KRNIC. I made a presentation
about our IPv6 DNS service deployment status in Korea at the last
APNIC meeting in Kuala Lumpur. So at this time this is an update.
First, this is my contents of my presentation. I will tell you about
the background of IPv6 DNS service in Korea and then I'll talk about
international trends, deployment, our strategy and status, and lastly
I'd like to close my presentation introducing our next year's plan.
First, let's take a look at the background of our KR DNS deployment
project. In 1980 through 1990 we did a development Internet. DNS
protocol was getting important and IPv4 DNS was getting developed. In
1994 we faced a problem of, we had a need for high speed Internet
services from our community. In 1999 to meet the - those needs for
stable IPv6 DNS, we have decided KR initiated IPv6 DNS project. This
slide shows, in development IP system, I split the first stage and we
are at the second stage. In developing IPv6 DNS we think that there is
two prerequisites. One is, from the network side, I think IPv4 and
IPv6 network has to be set. Then from the DNS delegation side IPv6
delegation and the root name server has to be done first. I will go
through international trends. This slide, as you know, there is 13
root servers and four out of the 13 are IPv6 ready servers. I captured
an article from the ICANN newsletter. In Korea and Japan, IP we got
IPv6 from ICANN observer. This slide shows this topology shows 13 root
DNS ccTLD delegation service. (Next slide) I also summarised
dual-stack status of ccTLD countries.

Japan has six DNS servers, from six servers four is IPv4 and IPv6 dual
DNS servers. France has 8 and one is IPv6 and IPv6 dual DNS servers.
We also researched what is going on in the ccTLD countries. According
to our research those countries minimise DNS server name because this
can - this is very - this minimise DNS, 512 bytes and this is also
very sensitive factor in construction of dual-stack network and IPv6
delegation to root the name server in the future. As for - as far as I
know, Japan has done this job from July of 2003 to almost - August
2003. They changed the 6.jp domain names to a-f.dns.jp. France is
doing this job. OK. Now, let's take a look at the - our strategy. To
adapt IPv6 DNS successfully, we went down two courses. First is to -
IPv6 DNS service, sharing technology and information. In IPv6
deployment, like I said, we - we are keeping stability of IPv-based 6
stack DNS service is most important. For this we add additional IPv6
stack, g.dns.kr. We are going to apply IPv6 to existing DNS Servers,
one by one. After deployment, trial service will be commenced. DNS
technology and information will be shared. from this we will cooperate
with other organisations, IPv6-related organisations in Korea, so -
and actually launched a web site for sharing DNS technology. This is
deployment status. From 2002, 2003, we constructed a tunneling IPv6
network and IPv 6 network - native. We also hold a - held a workshop
to raise awareness of IPv6 DNS. We published a DNS guidelines as well.
In 2004, this year is very important for us, because we constructed a
7th.kr dual-stack server and we had a delegation of IPv4, can are name
server. Registration of IPv6 papers of.can are name server to APNIC.
Launched DNS web page. This is only in Korea, though. That's -kr DNS
is IPv and IPv6 based local DNS Network. We expect - it is also IPv6
DNS preliminary, it is working as IPv6 DNS preliminary test network. I
think it can provide - it can be fully equipped environment for
technical analysis. I summarised what we have done from the
perspective of the system. We changed our DNS name consistently from A
to F and - we registered it to APNIC /32 and we also reversed a
delegation to root DNS server. This shows how our trial KR DNS service
is working. We have done this as of August this year. The next slide
shows our web service. Our web service consists of three parts. One is
statistics and another is traffic monitoring and it also provides zone
checking tools for users. You can see the - is increased dramatically,
as soon as we turned to IPv register. We adapt IPv6 DNS July 20th. It
increased from 45,000 to 100,000th. The next slide shows information,
information by KR type. This is MRTG. We also provided zone checking
tools, this is to prevent fragmentation.


KAZU YAMAMOTO:

Is this web site in Korean?


BILLY MH CHEON:

It is on now, yeah. We already launched the web site, but it's only in
Korean.


KAZU YAMAMOTO:

Can you try to translate into English?


BILLY MH CHEON:

Oh yeah, probably next year. We going to - I mean, we going to expand
our service and hopefully we can have a chance to cooperate with the
other countries, I mean, if they're interested, yeah. For that we will
translate the web site. This is our plan for the next year. Next year
we will - are going to expand our IPv6 DNS service and focus on
starting II anycast and UDF packet size limit and keep sharing IPv6
DNS technologies through our web site. (End of presentation)


KAZU YAMAMOTO:

Thank you, Billy. Any questions? Thank you very much.

(APPLAUSE)


KAZU YAMAMOTO:

The next speaker is Geoff Huston.


GEOFF HUSTON:

I realise I'm between you and lunch so I will be brief and I will be
as quick as I can and I'm sorry for the folk trying to transcribe.

This is an informational update on standards activity work around
multihoming. For those of you aware of it multihoming is common in v4.

The typical way you connect to two or more upstream service providers
is either to obtain your own independent address space and advertise
it to all your upstream providers then follow routing or take an
address fragment from one of your upstream providers and advertise
that fragment to all the other providers and follow routing. The
problem is routing is not an unbounded system it won't take an
infinite amount of load. If multihoming becomes prolific how can you
support this without imposing an amazing load on the routing system?
What you would like is a site to be able to use fragments of space
from all of its upstream providers, in this example two, but think of
two or more, without imposing any additional load on the routing
system. This diagram tries to explain what's going on here. You have a
host down at the bottom, dual connected to a red and blue ISP and some
remote hose trying to take a - have a conversation with you. There is
an RFC that enumerates some of the goals of this effort. In IETF goals
the only thing missing is a kitchen sink. Of course, when considering
a solution you'd like to think about everything including most parts
of the universe. The issue is that in trying to do this you're trying
to do a lot that is not IP as you know it. One of the major
simplifying assumptions in the IP architecture and certainly within
the IPv6 architecture is the who, when and how are embedded in one
address. If you want multihoming to work and keep your sessions up
then all of a sudden the who and the how have to be split. That's very
difficult. So, in other words, what we're talking about is an ID
locator split between your identity or your ID, and your locator,
which is how to get to you. The generic approach is being considered
here, is to put another element in the protocol stack itself. That
talks about identity.

Or you could modify either the transport or IP level of the protocol
stack to include locator agility or you can have a look at your site
exit routers and start mucking around with addresses at the edge of
your site depending on which way the packets want to flow. Um, the new
protocol element is effectively designed to present to the upper
layers an identity that present to the lower layers a locator so that
in theory the bottom bit, IP doesn't change.

But the session can recognise a number of IP addresses as belonging to
the one session, because they all share the same locator and in fact
the upper layers don't even know it's going on because they don't get
presented with an IP address, they simply get presented with an
identity.

The benefits of that kind of approach are as you see there, it's
trying to do indirection between identity and location and allow
identities to be persistent. Here's a quick protocol exchange of what
might happen in such a scenario. it's talking about an identity token,
some random thing, an identity protocol layer map that is identity
token into a real live locator and the IP protocol stack moves the
packet with the address on it in a conventional sense. There are a
number of ways of doing this, if any of you have looked at protocol
monitors, you put a standard thing when you put a protocol monitor
into the stack you add another one in the - you could also take an out
of band mechanism that has the identity protocol elements having their
own separate conversation from the data protocol itself. Or you could
have the identity protocol elements using a third party reference. I
realise I'm going really fast, certainly I'm trying to cover the
highlights. If you want to look at it in more detail the presentation
is on the web and you can study it at your leisure. If you don't put
in a new protocol element then the answer is you have to modify an
existing stack, one way is to modify transport. One of the ways that's
already happened is a STP which allows multiple locators to be bound
into the same session. SCTP doesn't allow you to flip locators within
live sessions but a lot of the other bit is already there. The other
way of doing this is to modify IP itself and if you have a look at
mobile IP - IPv6 you find this idea that I can move where I am and
still maintain some coherency of session by being mobile, that's
modifying the IP layer rather than transport. The difference? If I do
it in transport I don't have a persistent identity. I only have an
identity for the life of the transport protocol. If I do it in IP I
have a persistent identity but I have no idea when sessions come and
go. The third way of doing this is to do what was being talked about
many times - a thing called A plus A was to look at the boundary point
where your packets enter or leave your local site and rewrite the
locators there. Certainly, it's a lot trickier than it sounds and the
fact that some remote element is rewriting your packet header is
probably indistinguishable from a redirection attack which is a bit of
a problem. It appear that is we've always - the most of the proposals
coming through say the most viable place to put this is probably just
above routing but below IP fragmentation and IP SEG so the upper
layers are talking about identity, the bits below that are talking
about locators - upper layers. What's a locator?

An identity? A locator is an address. An identity - one of those
addresses is your identity.

So some 128-bit field is your identity and I can map from underaddress
to another through someone's specified mechanism. Or you can say the
DNS is your identity. I basically associate a set of locators with
that fully qualified dough plain name. When you try and use the DNS
For something lower in the stack you present the threat of
circularity. Also when ever you introduce something in the DNS it's
more weight for it to carry. The real question is how much weight can
you put on the DNS before it snaps? You could think of some other
token - I want to invent some new token space which is called identity
and the question is why would it be different from the DNS or
addresses? No-one's been able to answer that. You can say damn it,
it's only per session, there is no such thing as persistent identity,
that's the DNS's problem so I only need an identity per session - so I
might as well go and randomise some digits perhaps based on a
cryptographic hatch on some key and use that for the lifetime of the
session. If you're interested in that kind of approach there is a
protocol out there called hip, which has some trial implementations
now and is an interest implementation of the latter solution. The
issues involved in this are fundamental. Changing IPv6 to have this is
a very fundamental change in the architecture of the protocol. There
is some very basic questions going on is this identity locator binding
per TCP session? If so, what is UDP and how does it fight? There are
certainly parts of IP that don't have consistent persistent sessions.
Is this dynamic or static?

Configured in the DNS or a discovery problem? What about those systems
out today, 100% of them that have no idea about locator identity
splits. Is this a configuration issue or do you try and negotiate it?
The rest of the questions are also pretty obvious if you think about
them, that once you introduce identities and make them different from
locators a lot of what we assumed no long ever can be assumed and you
need specific answers to it. Lastly, some open questions just in case
you thought that wasn't enough - if the issue is multihoming why are
we introducing considering a massive change into the protocol
architecture itself? And is this really just a massive solution to
what may have well been a light weight problem, if the problem was
routing why didn't we solve routing? How serious a routing problem is
there anyway and is the solution the wrong way of approaching this? Is
routing scope a better approach? There have been some efforts in
routing scope, of the operator community is still grappling with what
do community mean, how do I make them leap over better hurdles and
will that scope better than fundamentally changing the IPv6 protocol.
Open question - interestingly enough. Then you get into this idea of
what's the practical compromise? Then you get even further down into
the fascinating question of - if you want it to do this is just simply
doing it per session enough? And you don't need the full baggage of
identities to carry with you. That was really fast, I know that
there's one more session before lunch so I have tried to be
astonishingly quick. Any questions? Or I'll pass it over straight away
to Jordi.

Thank you very much.

(APPLAUSE)


SPEAKER:

One minute for Jordi


KAZU YAMAMOTO:

Thank you for your presentation. The next speaker is Jordi again.
Because everybody is hungry.


JORDI PALET:

I will rush. You have the slides already there - let's go to lunch!
(Laughs)

(Pause)


KAZU YAMAMOTO:

If your presentation is not on web, please send your material to
sig@apnic.net.


JORDI PALET:

This presentation was prepared because several operators are already
asking for bigger locations than /32 so we started wondering what is
the rationale behind this location. So actually I tried to interview
all the people that is getting this big locations. I got inputs mainly
from Vodafone and TeliaSonera, I keep trying to get input from
everyone that is getting a location bigger than the /32, not just in
Europe but in the rest of the world. So basically Vodafone are a
global entity but have different organisations in every place of the
world for different reasons. I am not going necessarily to follow the
order of the slides, to go faster, but you have all the text there for
later taking a look. Basically, the location they got /31, who got
from Vodafone that location, is the entity Netherlands because they
are not just responsible for providing the service within the country
but also responsible for the global IP network that Vodafone has to
connect all the Vodafone operators. So this is a very simple case
because obviously they want to have a /32 suited to providing work -
and another /32 for the network connecting all the Vodafone networks
across the world. That's the basic idea behind this.

What I did also is I tried to, after getting the information from them
about why they are getting this big location, I figured out some
interesting questions and Vodafone replied to those questions that
obviously for competition reasons they can't answer openly. The first
one was when do you expect every Vodafone operator to request new
prefixes? They said everyone will do - already some of them are doing
it, depending on the plans they have to start their - start in their
own country. I - also asked if they believed /32 is enough for every
operator. They said in principle, yes. And they believe also for their
typical customer - remember they are basically mobile ISPs, a /64 is
also enough. What do you mean which IPv6 rollout over the IP back
bone? Currently the AP - IP back bone works with IPv4 only. In the
future it will work with IPv6.

Question number 4: They replied they will use both.

5: Have you already decided if required in some point in the network
to use any specific transition mechanism? Not yet, they have tested
NAT-PT but they believe dual stack proxies could be used in the
future.

Question 6: Any "Possible" or intended schedule for IPv6 usage in 3G
for user-traffic? Or it's only depending on the availability of the
different equipment. They didn't want to answer this question.

7: Do you feel IPv6 is important for 3G or do you do this only because
the standards mandate?

Answer: Whenever peer-2-peer communication is needed for broad public
IPv6 is necessary. Especially when IPv4 addresses are rare. Again,
this is their reply, not my own input.

Question 8:

What is your position about the usage of IPv4 with IMS? It makes sense
for you using private address space or it will break something and
make more difficult to provide new applications and services? Answer:

They - the main point here is Internetworking with other operators is
hard to do when using private address space. Last question is - are
you already considering any specific IPv6 application or services? And
at the moment they replied not yet as far as the person was relying
knows.


TeliaSonera:

They did actually an application for the group. They see a lot of
opinions on how they are going to help this single block for a group
of different companies. They see pros and cons to this approach. One
advantage is to have a more flexible allocation process and also to
have a more flat network all the way through. The TeliaSonera's major
concern right now was the vague rules when it comes to how to register
the addresses. They will like to see a change compared to the current
system for registering IPv4 since it otherwise would be, for example,
mean a lot of work for them to allocate /48 blocks using DHCP to
customers. Even they needed to request to rewrite the application form
since they didn't apply it for this big allocation request. Here are
the questions for TeliaSonera 1:

Can you tell me if you have already an idea and can be made public,
about how you will split the /20? Basically, which addressing plan you
have. They replied - it will probably be split to allow geographical
aggregation internally and at the same time make each unit a bit more
independent if wanted. 2:

Any specific plans for the length of the prefix that will be provided
to different type of customers? we want to follow the /48 rule. The
only real exception will be mobile phones, /64 but we are considering
mobile services that use /48 as well just to make it as easy as
possible for the user. 3:

Any specific consideration regarding 3G/UMTS deployment? Answer:

We see an IPv6-only IMS deployment will be the best technical
solution. They think it is a pity that most manufactures are
implementing IPv versions before IPv6 version even though it is stated
that it should be IPv6 only. 4:

What is your position about the usage of IPv4 in 3 G/IMS? It makes
sense? Answer:

No, I believe it creates more problems than it solves.

Interoperability with the entire Internet has to be possible which
means that there has to be mechanism for translating. Specific plans
for IPv6 user- traffic. Answer:

We are still looking into long-term solutions for IPv6 and have not
made all the final decisions so I don't think I have too much more to
share right now. Plans for dual stack or only IPv6? Dual stack. As an
operator we provide Internet access and that means providing both IPv4
and IPv6. Any plans for a specific transition mechanism? Answer:

We are offering 6 to 4 and considering deploying teredo relays for our
private customers and we are offering configured tunnels to corporate
customers. Why do you feel IPv6 is important? A:

Simplicity. I believe it will bring simplicity into the for the
ordinary customer and easier for implementors. As an operator those
things are important to help nourish our business. Last one - are you
already considering a specific application or services? A:

Connectivity and 3G is all they can mention at this time. DoD.
Basically, the plan. DoD is to get the big allocation with hopefully
some additional reserve to uniquely identify the DoD on the IPv6
Internet versus many parts of the DoD identifying themselves
independently. They are ready - they already confess there are good
and bad ramifications for this bill, but they balance that and they
believe it's better to have a single block. It is anticipated we will
give back our current IPv6 allocations when this happens. Future
combat systems demand ubiquity, IP centricity, mobility, operability -
security, quality of service, network operations. Our current networks
can not fit into anything like a /32. So the plan is for the next
three years to go with the /16. They make the comment that it's only
.00152% of the IPv6 address space. Something for the next ten years
and probably something much bigger later. They are even thinking in
some kind of geospatial addressing. The main motivation for them is
the soldier is a site - a network of networks.

They want to be able to attach the soldier to any new network, for
example, they - the situation a soldier that is connected to a tank
and the tank is broken and the soldier is automatically transferred to
a new tank and associated to that in a similar way. And that's it. I
will be interested if there is here some people that are already
requesting for big allocations or have some inputs into what they can
mean or any people that I know they have big allocations but they
haven't replied to my emails for information. I think this is
information that of course you don't want to give up everybody all the
company picture but,

so of the information could be helpful for sure. Thank you. (APPLAUSE)


KAZU YAMAMOTO:

Any questions? (Pause) Before lunch, I would like to announce
something. This announcement from APNIC. Of course, lunch is already
started. It is till 2.pm. Does everyone know where it is? Lunch? PAUL


WILSON:

At the Verandah restaurant.


SPEAKER:

Yes.


SPEAKER:

Lunch shall be served at the Verandah. If you are new, if you want to
participate in this IP policy lunch so that we'll talk about the -
explain the policies and how you can get involved, especially if
you're a newcomer, come to the IP policy lunch. That will be held in
the Port of Call room. Thanks.


KAZU YAMAMOTO:

About the social event - it is essential to bring your ticket with you
to get on the bus. We should meet at the lobby at 6.45. If you want to
get the meeting kit would you bring the coupon inside your name tag.
MyAPNIC demo is available all day and the help desk is available at
break times. The on-site notice board is available for any meeting
information. Randy. Do you want to... announce APOPS for this evening?
If you want.


RANDY BUSH:

This evening from 6 to 7 is the Asia Pacific operators forum, having
discussions of Internet and routing issues, - issues, Geoff, you're
doing some at APOPS tonight? No, OK, sorry. But anybody's welcome.
It's going to be here (Indicates this room) from 6 to 7, I think. I'm
pretty sure. Maybe 7.30? I can put on my eyeglasses but you can read
your program as well as I can.


KAZU YAMAMOTO:

So, I'd like to announce winners for the tea break draw. The winners
are Paul Rendek.

I don't know how to pronounce. So these two should go to collect the
prize from the Fiji girls outside this room. Sorry about that.
Finally, thank you each speaker and the audience for your attention.
Let's close this session with big hands. Thank you very much.

(APPLAUSE)

(lunch break)